The Bottoms-Up Way to Plan Your Next 18 Months of Hiring

Both failures trace back to the same root cause. Headcount planning that starts from a top-down percentage never asks the question that actually matters, which is what work needs to get done, by whom, and by when. Getting that right requires building the model from the bottom up, department by department, tied to real milestones rather than a ratio borrowed from a benchmark deck.

Why Most Startup Headcount Models Are Wrong

The most common shortcut in headcount planning is some version of the rule of 40 or a flat percentage-of-revenue target, where headcount grows in lockstep with a top-line number or a budget allocation. It’s an easy number to defend in a board meeting because it sounds disciplined, but it breaks down the moment you look at what it’s actually modeling. A percentage of revenue tells you nothing about whether engineering has the capacity to ship what’s on the roadmap, whether sales has enough reps to cover the pipeline needed to hit next year’s target, or whether customer success can support the accounts already in the door.

This shortcut produces one of two planning failures, and both are expensive in different ways. Hiring ahead of revenue means carrying cost the business hasn’t earned yet, which shows up as burn that outpaces plan and forces harder conversations about runway later. Hiring behind revenue means missing the growth targets that hiring was supposed to enable in the first place, because the team physically couldn’t execute on the plan without more people in seats. A percentage-based model has no mechanism for catching either problem before it happens, because it was never built around the actual work.

Bottoms-Up Headcount Planning by Department

The alternative is to build headcount up from the actual drivers in each function, rather than down from a company-wide ratio.

Engineering headcount should tie directly to the product roadmap. If the roadmap calls for three major initiatives in the next two quarters, the question isn’t what percentage of revenue engineering should represent. It’s how many engineers, in which disciplines, are actually required to ship those initiatives on the timeline the business needs. That’s a staffing conversation with your VP of Engineering, not a spreadsheet formula.

Sales headcount should come from a quota model working backward from the ARR target. If next year’s target requires a specific amount of new ARR, and your average rep can be expected to close a certain amount once fully ramped, the math tells you how many reps you need and when they need to start, accounting for ramp time before they’re productive. This is a very different exercise than assuming sales headcount grows at the same rate as revenue.

Customer success headcount should be driven by account-to-CSM ratios tied to the ARR each CSM can support well. As the book of business grows, this ratio tells you exactly when the next hire needs to be in place to avoid a service quality problem, rather than reacting to churn after it’s already happened.

G&A functions are the exception to most of this. Finance, HR, and legal don’t scale with revenue in the same direct way engineering or sales do. They scale with headcount and organizational complexity, so a finance team supporting 150 employees needs meaningfully more capacity than one supporting 50, regardless of what revenue is doing in that period.

Loaded Cost vs. Salary: The 20–30% Gap Most Models Miss

Even a well-built bottoms-up model can understate its own cost if it only accounts for base salary. The gap between salary and fully loaded cost typically runs twenty to thirty percent, and it’s made up of benefits, payroll taxes, equity expense, recruiting cost, and equipment, all of which are real cash or real dilution regardless of whether they show up in the same line item as salary.

Modeling this accurately means building a blended loaded cost rate by department rather than applying one flat multiplier company-wide, since the mix of benefits cost, recruiting spend, and equipment needs varies meaningfully between an engineering hire and a sales hire. A model that uses base salary as a proxy for cost will consistently understate burn by exactly the amount this gap represents, and that gap compounds fast once you’re hiring a dozen or more people a year.

Connecting Headcount to Milestones and Triggers

A headcount plan is only useful if it’s tied to specific, named triggers rather than a generic timeline. Milestone-based hiring means defining in advance what has to be true before a role opens, like “we hire the VP of Marketing when ARR hits three million,” rather than penciling that hire into a specific month regardless of how the business is actually tracking.

This same discipline should extend into your scenario planning. In a bear case, the plan should specify exactly which hires get pushed and by how long, such as moving four planned hires from Q2 to Q3, rather than a vague commitment to “slow down hiring if things get tight.” Defining these triggers ahead of time turns a hiring plan into a real decision framework instead of a wish list that gets abandoned the first time the numbers move.

The Board View: What Good Headcount Modeling Looks Like

All of this work needs a home in the board deck, and a good headcount view gives the board three things at once. The first is headcount by department, actual against plan, so variance is visible immediately rather than surfacing as a surprise in the burn number three months later. The second is a rolling twelve-month hiring forecast that shows open roles alongside planned ones, so the board can see not just where headcount is going but what’s already in motion to get there.

The third, and the one that ties the whole exercise together, is a clear line from headcount to burn. A board that understands how each department’s hiring plan drives the burn trajectory can have a much more productive conversation about tradeoffs, because they’re reacting to the actual drivers rather than a single aggregated number that could be moving for any number of reasons.