How do I defend engineering headcount in a budget meeting?

Bring three things: throughput per engineer measured against your own prior-year window; a named list of the work that won’t happen at the smaller number; and an interval for every figure you quote. Capacity arguments lose because they describe how the team feels. A comparison against your own history, with the work being traded away named on the slide, turns the request into a decision about scope rather than a judgment about effort.

What a headcount defense has to prove

The meeting is rarely about whether your engineers work hard. Everyone in the room assumes they do. The question on the table is whether the next engineer buys more than the same amount of money would buy elsewhere, and whether the team you already have is converting its cost into delivered work.

As a former CTO, I sat on the wrong side of that gap for years. I could describe what the team had absorbed, quarter after quarter, and I couldn’t produce a figure that survived contact with a spreadsheet.

Three claims have to hold up, each against one follow-up question.

That the current team is delivering more per person than it was, or delivering the same while absorbing more complexity. That the work queued behind the current capacity carries a cost if not done. That the figures come from a method you’d be comfortable having someone else run.

Miss the third, and the first two stop counting.

Why “we’re at capacity” loses the room

It’s true and it’s unusable. Every department is at capacity. Support is at capacity. Finance is at capacity. The phrase carries no comparison, no period and no unit, so the CFO has nothing to do with it except note that engineering said the same thing last year.

The version that works names the trade. “At 14 engineers we ship the billing migration and the mobile release. At 12 we ship one of them, and my recommendation is the migration, because the billing system is the constraint on the pricing change finance asked for in March.”

That sentence hands the decision to the room, with the consequences already priced in. It also does something a capacity complaint can’t: it makes you the person who brought options rather than the person who brought a problem.

The three numbers to bring, and where they come from

Throughput per engineer against your own prior window. The comparison is your team last year, not an industry benchmark. Your Git history already holds the raw material. Pick the same repository set for both windows, because a figure drawn from 4 repositories and compared against 9 is measuring scope rather than performance.

The cost of the deferred queue. Take the 3 or 4 items that don’t get built at the lower number and attach a real consequence to each. A compliance deadline. A support cost that continues. A customer commitment. Finance can price a deferred deadline. Finance cannot price “the backlog is growing”.

The full cost of the current team, including tooling. Loaded salary from finance’s own figure, plus seats, plus token spend, plus the CI and preview compute the tooling triggers. Bringing the cost side yourself changes who is auditing whom.

Each of those has an interval or a stated assumption behind it. Say so on the slide. A range reads as instrumentation, and a point estimate with no range reads as a request dressed as arithmetic.

If you want throughput per engineer scored against your own prior-year window before the budget cycle opens, connect a repository and the historical window scores in the first pass.

How to answer “can’t AI absorb this?”

This is now the question the whole meeting turns on, and the honest answer has structure.

Navigara’s Q2 2026 study measured 699 qualifying engineers and 137,592 qualifying commits across 65 public repositories at 6 organizations. The decomposition is the part that matters here. Commits per engineer rose 14.9% year over year. Performance per commit rose 100.4%.

Where the change sits: Q2 2026 study

Year over year, 699 engineers, 65 public repositories

Two columns comparing components of the Q2 2026 result: commits per engineer up 14.9 percent year over year, and performance per commit up 100.4 percent, showing the change is concentrated in the value of each merged change rather than in how many changes were made.

Two uses for that pair, pointing in different directions.

It supports the claim that the value of each change can move a long way while activity barely moves. So a team that looks flat in commit volume may have changed considerably in what it delivers, which is why you should measure your own team properly before anyone reasons about its size.

It refuses to support a headcount conclusion. The study measures merged changes in public repositories and explicitly states that it “does not quantify what share of the level shift, if any, is attributable to AI coding assistant adoption.” 21 of the 65 repositories in the sample are AI or agent SDKs, spread unevenly across the organizations, and demand for that category grew across the same window, so for those repositories throughput per engineer and market growth can’t be separated.

Say that out loud. When someone in the room quotes a vendor claim that AI removes 30% of engineering needs, you’re now in a stronger position because you’re the only person present who has stated what their data can’t prove. Then bring it back to your own figures: here’s what our throughput per engineer did, here’s the tooling cost that produced it, here’s what’s still in the queue.

What to do when the ask is a backfill rather than growth

Backfills get treated as free savings, because the work was already being done by someone who has left. The defense differs from a growth defense and is usually easier.

Name what left with the person. Not their hours. The specific systems they were the only current maintainer of, the reviews they were absorbing, and the on-call rotation that now has one fewer name in it. Then state the timeline plainly: a backfill takes 3 to 6 months to reach the previous level of contribution, so the gap is a period rather than an event.

If the decision is to hold the position open, get the scope reduction recorded in the same meeting. An unfilled seat with unchanged commitments becomes a delivery miss with your name on it in 2 quarters.

How to prepare the numbers before the meeting exists

The measurement that wins a budget meeting can’t be built inside the budget meeting, because the first pass always finds problems in the data rather than answers. A repository nobody remembered. A bot account inflating the historical window. A 3-week gap during which the CI provider changed, and the commit metadata changed with it.

Run it 2 quarters early. Fix the scope, rerun, and show the team its own numbers before anyone in finance sees them. That sequencing matters more than the wording of any announcement. Data the team already holds is an instrument. Data that arrives downward from finance is an audit, and an audit gets gamed.

What to concede

Concede one thing on purpose, early, before you’re asked.

Concede that a single quarter proves nothing. The Q2 2026 study is useful here as a discipline: quarter-over-quarter, the open cohort came in at +17.5% with a 95% confidence interval from -0.7% to +38.8%, and the report’s own conclusion reads: “The quarter-over-quarter change cannot be distinguished from zero.” A noisy series needs more than one quarter to carry a claim, and saying so about your own data is what makes the annual comparison believable.

Concede the boundary of what you measure. Merged changes don’t capture the depth of code review, incident response, planning, or mentorship. Anyone who has run a team knows most of the load lives there, and a manager who volunteers the limitation is harder to catch out than one who doesn’t.

What you don’t concede is the frame. The question is how much scope the company wants delivered next year, and at what cost. Headcount is the answer to that question, not the subject.

Talk to us if you want the prior-year comparison run against your own repositories before the next planning cycle.