Most recruiting teams are sized by rules of thumb — "a recruiter carries about 20 reqs" — applied the same way to very different roles. Capacity plans rarely account for how hard each role actually is, and the reasoning behind the headcount number is difficult to defend when finance asks where it came from.
I built a model that does the math explicitly. To test it, I ran it on a real company: 87 open US requisitions pulled from the public careers page of an AI-native dev-tools company in San Francisco (referred to here as Company AI-XYZ).
| Recruiter type | Open reqs | Hard | Moderate | Standard | Recruiters needed |
|---|---|---|---|---|---|
| Technical | 44 | 42 | 2 | 0 | 9–10 |
| Business | 39 | 19 | 20 | 0 | 6–7 |
| Leadership (VP+) | 4 | 4 concurrent exec searches | 1 | ||
| Total | 87 | 61 | 22 | 0 | ~16 |
Assumes best-in-class sourcing support and AI tooling, priced as a bounded range from published evidence. With typical support and tooling, the same board needs about 18.
Each req is scored on four market factors — talent scarcity, seniority, location requirements, and comp competitiveness — plus two company adjustments that can move a search in either direction: employer brand (which can make recruiting easier, harder, or have no effect, and is scored per talent pool) and hiring bar (more selective companies need more sourcing and more interviews per hire). The combined score places each req in a difficulty tier. Standard roles are expected to fill within the quarter; harder tiers get more time; VP-and-above searches run on published search-firm timelines and are handled by one leadership recruiter. Difficulty weights the load, and benchmark throughput converts the load into a number of recruiters.
For this company, the strong engineering brand and the high hiring bar roughly offset each other. The model states that explicitly rather than assuming it — and for a company where the two don't offset, the answer would change accordingly.
Every figure in the output carries a tag showing its source:
| company data | The company's own ATS history — hires per recruiter, time-to-fill, offer rates. Used whenever it exists; the model has labeled placeholders showing where it plugs in. |
| benchmark | Published and recent: Ashby and Gem platform data measured across millions of applications (2024–2026), SHRM survey medians. Each figure is cited with source and year. |
| derived | Arithmetic on published figures, shown step by step. |
| gap | No data exists — the model says so and shows a sensitivity range instead of filling the hole. |
Where the evidence is thin — for example, the productivity effect of AI sourcing tools — the model uses a bounded range built from published research and labels the assumption, rather than inventing a number.
The model is built to be interrogated. Difficulty scores can be reviewed and overridden req by req. A company's own data replaces the benchmarks when it's available. The fill expectation is an explicit input rather than a hidden assumption — change it, and the answer changes for reasons you can see. And when the recommended number isn't fundable, the model computes the practical alternative: how many open reqs the existing team can keep inside the fill window.
If you'd like to see it run on your req list, email me — a careers-page export is enough to start.