Headcount Planning That Protects Runway, Not Just Records Hires

Most hiring plans are a list of titles with a start-date column. They live in a tab of the board deck, get approved in a compensation-committee meeting, and get filed. What separates that artifact from headcount planning that protects runway is whether the list carries the one number that actually moves cash: fully-burdened cost, staged against the month it hits the bank, tied to the revenue it is supposed to produce. A list records intent. A model tells you when you run out of money.

At most growth-stage companies, people are the burn. For a Series A–C software business, salaries, benefits, and payroll taxes run 60–75% of operating expense. The plan that governs headcount is, functionally, the plan that governs the runway. Treating it as an HR artifact rather than a financial model is the single most common way a finance team loses control of its own cash forecast.

A list is not a model

The difference is concrete. A headcount list has a name, a title, a base salary, and a start date. A headcount model has, for every role, four things the list omits: fully-burdened monthly cost, the cash lead time before the start date, a ramp curve, and a dependency chain. Each of those four is a place where a plan that looked affordable in the deck turns out not to be.

Fully-burdened cost

Base salary is the number everyone quotes and the number that understates the truth by a third or more. The load — the stack of costs that ride on top of base — typically adds 30–40% before you have accounted for anything discretionary.

Start with the statutory floor. In the U.S., the employer pays 6.2% for Social Security up to the Social Security wage base and 1.45% for Medicare with no cap; that is 7.65% before you touch anything else. Federal and state unemployment insurance add more. Then benefits: the average employer contribution to a family health premium was roughly $17,400 a year in the KFF 2023 Employer Health Benefits Survey, which on an $80,000 base is another 20-plus points on its own.

Then the software and equipment nobody models as headcount cost but which scales with it exactly — a seat of every tool the person touches, a laptop, the equity expense that flows through the P&L. A useful rule: if you are quoting base, you are quoting about 70% of what the role actually costs. A $150,000 engineer is a $195,000–$210,000 line item. Build the model on the loaded number or the model is wrong by 30% on its largest cost category.

The pre-start cash lead time

A start date is not the date the money starts. Recruiting agencies bill 15–25% of first-year comp on signing. Signing bonuses clear before day one. Equipment and software provisioning hit in the two weeks before start. For senior roles you are often carrying relocation or a buyout of forfeited equity.

Plan for 30–60 days of cash outflow ahead of the start date on any meaningful hire. A model that books cost from the start date understates the burn in exactly the months you most need the number to be right — the ones just before a raise, when the runway math determines whether you raise from strength or from a position where the term sheet knows you are running out. The mechanics of translating a staffed plan into month-by-month outflow are their own exercise; we walk through it in Building Forward Burn From Your Headcount, Line by Line.

Ramp

A salesperson who starts in January does not produce in January. This is obvious for quota-carrying roles and quietly true for most others. The standard treatment is a ramp curve: a new AE contributes roughly 25% of full productivity in the first quarter, 50% in the second, 75% in the third, and full quota by the fourth. Ramp times for SaaS sales reps commonly run three to six months, and for complex enterprise motions longer.

The cost, meanwhile, ramps instantly. You pay full loaded comp from day one and collect fractional output for two or three quarters. A model that books full productivity from the start date will show you hitting plan a quarter before you actually do — which is the same as showing you more runway than you have. The gap between cost-on and productivity-ramping is where optimistic plans quietly overspend.

Dependency hiring

Roles do not arrive alone. Approving a VP of Sales is not one line. It is the VP, and then the two SDRs and the sales engineer that VP was hired to build around, and the $15,000–$30,000 a month in indirect cost that arrives with the function — the sales-engagement platform, the data enrichment, the incremental CRM seats, the increased T&E, the enablement software.

A first engineering manager pulls an infrastructure budget. A first sales leader pulls a go-to-market stack. The dependency is the point of the hire; you are not hiring the leader for their individual output, you are hiring them to stand up a team. Model the leader without the team they imply and you have modeled the least expensive quarter and none of the ones that follow.

Tie every role to a revenue driver

Once you have the true cost of a role, the harder discipline is refusing to approve it until it is attached to a specific thing it is supposed to move. Not "we need more engineers" but "this pod ships the billing feature that unblocks the enterprise tier we've had three deals stall on." Not "sales is understaffed" but "each ramped AE carries $1.2M in pipeline coverage against a $900K quota, and we are two AEs short of the coverage the board plan assumes."

The test is simple and unforgiving: for every open role, name the revenue driver or the risk it retires. Roles that pass this test go in the plan. Roles that cannot are either cost you are choosing to take on faith — sometimes legitimate, for platform or compliance work — or they are the roles that get cut first when the plan tightens. Making the distinction explicit at approval time is far cheaper than making it during a reduction.

This is also where the CFO and the functional leader stop talking past each other. The VP of Sales wants heads; the CFO wants coverage math. Tying the role to the driver forces both into the same sentence. a16z's benchmarks on sales efficiency and the coverage ratios most boards now expect give you the shared vocabulary — pipeline coverage, magic number, payback period — to argue about the plan in units that connect to the model instead of headcount for its own sake.

Stage the plan against the driver

A plan is not a hire date; it is a sequence. Staging means ordering roles so that the ones that produce revenue land in time to fund the ones that only cost. The infrastructure hire that enables the launch goes before the sales team that sells it, not after. The first AE ramps before you approve the next three.

Staging is where scenario work lives. The same list of roles produces very different runway depending on whether you front-load or back-load it, and whether you hold the plan when a quarter comes in soft. The discipline is not picking the right number of hires once; it is building conservative, base, and aggressive versions of the sequence and knowing in advance which triggers move you between them. We lay out how to build and cadence those three cases in Conservative, Base, Aggressive: Modeling Three Hiring Cadences.

The staging question that trips up most teams is the trigger. "We'll hire the next two AEs when we hit X" is only useful if you know X against live numbers, not last quarter's board deck. Tie the trigger to a metric you can actually see — bookings run rate, net revenue retention, cash balance — and revisit it on a fixed cadence rather than when someone notices runway is shorter than they thought.

The model is only as current as its inputs

Here is the failure mode that undoes all of the above. You build a careful headcount model — loaded costs, ramps, dependencies, staging — in a spreadsheet, in February. By April the model describes a company that no longer exists. Two hires slipped a month. One offer came in $20,000 over band. Someone left. The health plan renewed 9% higher. A vendor contract you modeled as monthly is annual.

None of those changes are exotic. Every one of them is invisible to a model built on numbers that were typed in once. The plan sitting in the deck is reconciled to reality exactly on the day it was built and drifts every day after.

This is the argument for building the plan on live data rather than a static snapshot. Payroll knows who is actually on the books, at what rate, starting when. The bank knows what actually cleared. When the model reads from those sources instead of a February typing session, the reconciliation problem — the gap between what you planned to spend and what you actually spent — closes on its own instead of surfacing as a quarter-end surprise. That gap, and how loaded comp in the plan should tie back to what the general ledger records, is the subject of The Case for Making Loaded Comp Match the Books.

The tooling here matters less than the wiring. Plenty of teams run this in a spreadsheet connected to their HRIS and accounting system through something like a Google Sheets connection to their data warehouse, and plenty of others use a dedicated planning tool — Cube, Mosaic, Runway, or one of the others in the category CFOs increasingly treat as core infrastructure. What separates the ones that work is not the interface. It is whether the numbers underneath refresh on their own or wait for someone to update them. We have made the broader case for operating off live actuals instead of static dashboards elsewhere; headcount is where the difference shows up first and costs the most.

See how a live-data headcount model reconciles against actuals →

What the discipline buys you

The payoff is not a prettier spreadsheet. It is that you can answer the two questions that matter — how much runway do we have, and what happens to it if we hire the next five roles — with numbers you trust, on the day someone asks, not after a two-day reconciliation exercise.

A headcount list tells you who you hired. A headcount model tells you what hiring them does to the runway before the offer goes out, and keeps telling you the truth as the plan meets reality. The first is a record. The second is the difference between raising from strength and discovering, a quarter late, that the plan you approved cost more than the company could carry. The mechanics of getting there — forward burn, scenario cadence, and reconciliation — are the rest of this series. The thesis holds across all three: the plan has to sit on live numbers, or it is describing a company you no longer run.