The Hiring Plan: Staffing for the Req Load You're About to Get

Twelve reqs clear approval in a forty-minute planning meeting. Roles, levels, target start dates, an owner against each line. Everyone leaves satisfied, because on paper the plan is complete.

Six weeks later the same group is asking why three of those searches are stuck at the panel stage. Nothing went wrong with sourcing. The pipelines are fine. What happened is that twelve reqs opening in the same quarter needed roughly a hundred and fifty interview hours from a bench of interviewers who were never counted, never asked, and never in the plan.

That is the standard failure mode of a hiring plan. It plans the demand in detail and the supply not at all.

What is a hiring plan?

Most hiring plans are one of two documents wearing the same name.

The first is a finance artifact. It lists approved headcount by department, with a cost per role and a quarter attached. Its job is to control spend, and it does that well.

The second is a recruiting artifact. It sequences searches, assigns owners, and sets target dates. Its job is to make the hiring period executable.

The confusion comes from treating the first as if it were the second. An approved headcount number tells you what you are permitted to hire. It says nothing about whether the organization can run the interviews that turn permission into people.

Why doesn't a headcount spreadsheet cover it?

Twelve reqs is not twelve times the recruiter work. Recruiter load scales roughly with req count, and that part of the plan is usually right.

Interviewer load does not behave the same way. A panel is a scheduling problem with a fixed, finite bench behind it, and the same senior engineer appears on four of your twelve loops. Booked against each other, those four loops do not queue politely. They collide, and the collision surfaces as a reschedule.

The arithmetic underneath is unforgiving. Workday records applications up 32% globally against open roles down 13%, and Gartner finds 78% of recruiting leaders working with flat or shrinking budgets. More candidates, fewer people to move them, no new budget. There is no absorbed-quietly option left.

The structural reschedule rate across recruiting organizations sits at 14%. Roughly one interview in seven has to be rebuilt at least once, and a plan that assumed each loop books cleanly the first time has already underestimated the coordination it created.

What goes in a hiring plan that works?

Use this as the row structure. One row per req, and the fields in this order:

* Role and level. Mapped to your existing job architecture, so the panel requirement is predictable rather than invented per search.

* Hiring manager. Named. The loop is built around this person's calendar whether you plan for it or not.

* Recruiter owner. One person accountable for the search moving.

* Target open date. When the req clears approval, not when the need was raised. Those are different dates, and the gap between them is usually invisible. See what a job requisition actually is for why.

* Target start date. The date the business is planning against, which is the only one anyone outside recruiting remembers.

* Panel composition. Which competencies the loop must cover, and how many interviewers that takes.

* Interview hours per hire. Start from the 12.3 benchmark and adjust for your own loop length.

* Named interviewers. Who is on the bench for this req, and who backs each of them up. This is the field that converts a plan into a commitment somebody made.

* Period total. The sum of interview hours across every row, which is the number the plan actually has to clear.

The first five fields are in most plans already. The last four are the plan. Fill them in and the document stops describing what you want and starts describing what the organization can carry.

The workflow those reqs travel through is a separate artifact. Our hiring process templates cover the stage gates, panel structures, and debrief criteria that define each loop; this plan decides how many of those loops run at once.

How do you plan interviewer capacity, not just recruiter capacity?

Four steps, none of which need new software.

* Count the bench. List the people who can actually sit on panels this quarter, and ask each of them for a monthly hour ceiling. Not a guess on their behalf, but an answer from them.

* Convert hours to hires. Divide the monthly total by 12.3. That is your hiring ceiling for the period, and it is a harder number than any req count.

* Compare it to the plan. If the plan needs more hires than the ceiling supports, you have three levers: add interviewers, shorten loops, or move reqs into the next period. Pretending is not a lever, although it is the most commonly selected one.

* Give the trade-off an owner. Interviewer capacity has no natural home, which is why it drifts. It usually belongs to recruiting operations, and where that function does not exist, it belongs to whoever will be asked in November why the plan slipped.

One caution on the bench count. Senior interviewers are the scarcest supply and the most heavily requested, so a plan that leans on three staff engineers for every technical loop has a single point of failure dressed up as a roster. Depth per competency matters more than total headcount.

If you want the interview hours in your own plan costed rather than estimated, the interview scheduling ROI calculator works it out from your req load.

"We plan headcount every quarter already"

This is the strongest objection, and it is not wrong on its own terms. Headcount planning is a real, well-governed process in most companies. Finance runs it, it has a cadence, and adding a parallel document sounds like adding overhead to something that already works.

But the two plans answer different questions, and they fail differently.

A headcount plan fails when the money runs out. The failure is visible immediately, it has an owner, and everybody recognizes it.

A capacity plan fails when the money is fine and the interviews will not fit. That failure surfaces six weeks downstream as a slow loop, a stalled search, and a candidate who accepted somewhere else. Nobody attributes it to planning, because the planning artifact never contained the constraint that broke.

You do not need a second meeting. You need three more columns in the one you already hold.

How far ahead should a hiring plan be built?

The horizon is set by how fast the inputs go stale, and the interviewer bench is the fastest-moving input in the document. People change teams, go on leave, get promoted out of the interviewing pool, and take two weeks off in the exact window your loop needed them.

So plan the near quarter properly and sketch the next two. The average role takes 56.7 days to fill, which means a req opening in the last month of a quarter is really a next-quarter hire, worth marking as such in the plan rather than discovering later.

Mid-August is the natural moment for this pass. Fall and Q4 reqs are being agreed now, and the interviewer bench that will run those loops is the same one currently absorbing whatever is left of the summer.

Where the plan meets coordination

There are only two ways to fit more hiring into a period. Add interviewer hours, which means asking people already at capacity for more. Or make each loop cheaper to run, which creates capacity out of work you were doing anyway.

The second is where the leverage is. candidate.fyi is the AI coordination layer across the interview workflow, and the effect on this specific constraint is measurable: panel booking drops from 243 minutes to 27 when candidates self-schedule, and time-to-interview from 5.9 days to 3.9. Zendesk moved from 225 to 445 interviews a week within a month of switching.

That does not change how many interview hours a hire consumes. It changes how much coordination sits on top of those hours, and how quickly a reschedule gets absorbed instead of stalling a search. If you want to know which constraint to attack first, the coordination maturity model places most teams before it tells them.

The bottom line

A hiring plan is not a list of roles. It is a claim about what the organization can absorb, and the claim is only checkable if the plan says what each req costs in interview hours and who is supplying them.

Three columns. One number to compare against the bench. That is the difference between a plan that holds in October and a plan that gets explained in October.

Frequently asked questions

How do you create a recruitment plan?

Start from the roles and dates the business has approved, then add the execution layer: an owner per search, the panel each loop requires, and the interview hours it will consume. Total the hours, compare the total to what your interviewers can realistically supply in the period, and resequence until the two numbers agree. The comparison is the plan; the list of roles is just the input.

What are the five recruitment strategies?

Most frameworks name internal mobility, employee referrals, direct sourcing, employer branding and inbound applications, and agency or contract hiring. They are supply strategies, and they differ mainly in cost and speed. Whichever mix you choose, the interview loop downstream is the same, which is why a recruitment plan built only around sourcing strategy still runs into panel capacity.

Is a hiring plan the same as a recruitment plan?

They are used interchangeably in practice. Where teams distinguish them, the hiring plan is the demand side (roles, headcount, timing, budget) and the recruitment plan is the execution side, covering sourcing channels, process, and owners. Both need interviewer capacity in them, and neither usually has it.

What should a hiring plan template include?

One row per req with role and level, hiring manager, recruiter owner, target open and start dates, panel composition, interview hours per hire, named interviewers, and a period total across all rows. If a template stops at roles, dates, and budget, it is a headcount forecast rather than a hiring plan.

How often should a hiring plan be revisited?

Monthly, and specifically the interviewer bench. Reqs and dates move slowly; interviewer availability moves constantly. A monthly pass that re-confirms who is on the bench and what hours they can give catches the capacity gap while there is still time to add interviewers or move a req, rather than after a loop has already stalled.

How do you plan interviewer capacity rather than recruiter capacity?

Ask each named interviewer for a monthly hour ceiling, total it, and divide by roughly 12.3 interview hours per hire to get the number of hires the organization can absorb. Check depth per competency as well as the total, because a bench that depends on three senior people for every technical loop will fail even when the aggregate hours look sufficient.

Planning a req load your bench has to absorb? Book a demo and we will show you what each loop currently costs you in coordination.