How do I defend engineering headcount in a budget meeting?
To 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. Comparing against your own history, with the work being traded away named on the slide, turns the request into a scope decision rather than a judgment about effort.
What a headcount defense has to prove
A meeting to defend engineering headcount is rarely about whether your engineers work hard. Everyone in the room assumes they do. The question is whether the next engineer buys more than the same amount of money would elsewhere, and whether your existing team 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 absorbed quarter after quarter, but I couldn’t produce a figure that survived a spreadsheet review.
Three claims have to hold up to defend engineering headcount, 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 current capacity costs something if it isn’t 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 defends engineering headcount 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, not the person who brought a problem.
The three numbers that defend engineering headcount
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. 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 every engineering headcount 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 matters here. Commits per engineer rose 14.9% year over year. Performance per commit rose 100.4%.
Where the change sits: Q2 2026 study
| Component | Year over year |
|---|---|
| Commits per engineer | +14.9% |
| Performance per commit | +100.4% |
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 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 an engineering 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 the engineering headcount case 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.
If that vendor claim is already circulating in your org, book 20 minutes with us and roast it before the meeting.
What to do when the ask is a backfill rather than growth
Backfills get treated as free savings because someone who left was already doing the work. Defending engineering headcount for a backfill differs from a growth defense and is usually easier.
Name what left with the person. Not their hours. Name 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. 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
You can’t build measurements that defend engineering headcount in a budget meeting, because the first pass always finds problems in the data, not 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 the engineering headcount numbers 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 any announcement’s wording. Data the team already holds is an instrument. Data that comes down from finance is an audit, and audits get gamed.
What to concede when you defend engineering headcount
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. Engineering 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.
Frequently asked questions
- What data should I bring to defend engineering headcount?
- Throughput per engineer against your own prior-year window on the same repository set; the named work that gets deferred at a lower headcount, with a consequence attached to each item; and the full cost of the current team, including tooling and compute. Put an interval or a stated assumption next to each figure.
- How do I answer a CFO who says AI should reduce engineering headcount?
- Separate activity from value using your own data, then state what the data can’t support. Navigara’s Q2 2026 study shows commits per engineer up 14.9% year over year, performance per commit up 100.4%, but it doesn’t quantify how much of that is attributable to AI assistant adoption. No published research supports a headcount conclusion.
- Is a capacity or utilization argument ever enough to defend engineering headcount?
- Rarely, because every department reports being at capacity, and the claim offers no basis for comparison. Converting it into a scope trade works better: name what ships at the requested number, what ships at the lower number, and which you’d recommend.
- How far ahead should I start measuring to defend engineering headcount?
- About 2 quarters. The first pass mostly finds data problems, such as bot accounts, forgotten repositories, and gaps where tooling changed the commit metadata. The second pass is the one worth taking into a meeting.
- Does measuring throughput per engineer mean tracking individuals?
- No. Throughput per engineer here is the team total divided by team size, so it’s a unit cost rather than a per-person score. Individual reporting creates a ranking that misrepresents shared work, so we exclude it from the measurement.
- What if our throughput number came out flat?
- Then report it flat and show the work mix alongside it. A flat total with a falling maintenance share and a rising test share is different from a flat total with no mix change, and a manager who accurately reports a flat quarter keeps the credibility to report a good one later.
