Most hiring improvements start in the wrong place. A team feels that hiring is slow or messy, so it adds a new job board, another interview round or a new piece of software. Sometimes that helps. Often it adds work on top of the real problem.
A better starting point is smaller and more concrete: one real hire, traced from start to finish.
We have written before about drawing your hiring process before you choose tools. That article was about designing the process you want. This one is about examining what actually happened, so you know which part to fix first.
Choose one role
Pick one role your organisation filled recently, or one vacancy that is still open. A recent one is best, while people still remember the details and the emails still exist.
Do not pick the hire that went perfectly. Pick one that felt slow, frustrating or uncertain. That is where the lessons are.
Reconstruct the timeline
Gather what exists: the first message about the role, the job ad, the applications, interview notes, emails and the offer. Then put the steps in order and answer these questions for each one.
- The request. Where was the need for the role first recorded, and who approved it?
- The criteria. When did the team agree what it was looking for? Before or after applications started arriving?
- The applications. Where did they arrive, and who was responsible for reviewing them?
- The stages. Who owned each step, and how long did each one take?
- The notes. Where was interview feedback stored, and could you still find it today?
- The waiting. How long did candidates wait between each decision?
Write down dates where you can. Gaps between dates are often more revealing than anything else. A role that took nine weeks to fill may have spent five of them waiting on one person's feedback.
Large employers use the same idea. The US Office of Personnel Management offers federal agencies a Hiring Process Analysis Tool in which agencies enter how long each step actually takes and see which steps differ most from a model process. Your version can be a single page with dates on it.
Look at the system, not the people
The most important rule of the audit: do not begin by judging the people involved.
Engineering teams learned this the hard way. Google's guide to postmortem culture says that a truly blameless review must focus on identifying the contributing causes of a problem without indicting any individual or team. It assumes everyone involved had good intentions and acted on the information they had. The reason is practical: if people fear blame, they stop surfacing problems, and you can fix systems and processes in a way you cannot fix individual mistakes.
Hiring works the same way. A manager who took two weeks to give feedback was probably busy, with no deadline and no reminder. That is a system problem.
So look for points where the process made good work harder. Common examples:
- The same information was entered twice, once in email and again in a spreadsheet.
- Feedback had no deadline, so it arrived when someone remembered.
- A candidate was rejected without a recorded reason.
- Sourcing started before the role was agreed, so the criteria shifted halfway through.
The third point is not only an efficiency issue. The UK Information Commissioner's Office guidance on keeping recruitment records reminds employers that candidates may ask for the information held about them, and warns that destroying records too quickly can make it harder to show that a process was fair. A decision with no recorded reason is hard to explain later.
Circle one breakdown
By the end, you will probably have a list of five or ten problems. Do not try to fix them all.
Circle the one breakdown that created the most delay, rework or risk. Then fix that point, and only that point, before your next hire. If feedback had no deadline, set one and name who chases it. If candidates were rejected without reasons, add a single required line to your candidate record.
Resist the urge to add another sourcing channel or another interview stage first. More candidates moving through a broken step only makes the break more expensive.
A quick example
Here is what one audit might look like for a small team that recently hired an office manager.
The role took eleven weeks. Reconstructing the dates shows that applications were reviewed within a week, and interviews were booked quickly. But after the second interviews, the team waited sixteen days for feedback from one director who was travelling. Two strong candidates accepted other offers during that wait.
The team had been planning to advertise on a second job board for the next vacancy. The audit shows that more applicants would not have helped. The fix is smaller: feedback is due within two working days of an interview, and if a decision maker is away, a named deputy can make the call.
Repeat with the next hire
After the next role is filled, run the same audit again. Check whether the fix held and whether a different breakdown is now the biggest. Over a few hires, this builds a process that fits how your team actually works, one repair at a time.
The bottom line
One real process will teach you more than a generic best practice diagram. Take one recent hire, reconstruct what happened, look for points where the system made good work harder, and fix the single breakdown that caused the most delay, rework or risk. Then do it again.