Key takeaways
Build the budget from what last year actually cost, not from last year’s budget. Those are different numbers and the gap between them is where your credibility lives.
Split spend into run, grow and transform. A budget that cannot say which is which invites cuts in the wrong place.
AI is now three separate line items, and the third one, downstream infrastructure, usually sits on someone else’s budget.
Justify headcount with evidence of the constraint, not with a story about ambition. Show what the queue costs today.
Capitalization is the largest financial lever most engineering leaders never pull.
Budget season punishes engineering leaders who arrive with a narrative and rewards the ones who arrive with arithmetic. This is the practical version: how to build the numbers, what the new AI lines look like, how to justify headcount in a year when headcount is the hardest ask, and how to run the conversation with finance. For the strategic context behind the squeeze, see engineering budgets under pressure.
Most engineering budgets are built by taking last year’s budget and adjusting it. That is the wrong starting point, because last year’s budget is a plan and what you need is a record. The two diverge, often significantly, and the divergence is the most useful information you have.
Before anything else, reconstruct where the money went: by initiative, by team, and by category. If you cannot do that from your systems, that is itself the finding, and it is worth fixing before the planning conversation rather than after. Project costs and resource allocation generate this from data you already have rather than from a survey of managers’ recollections.
Figure 1
Structure the budget so each line answers a different question
The fourth category is the one most budgets omit and every organization spends. Naming it turns an overrun into a forecast.
The reason this split matters is that finance cuts what it cannot distinguish. A single engineering number invites a single percentage cut. Four categories with different payback profiles invites a conversation about which one to trim, and that is a conversation you can win.
In most organizations AI arrived outside the planning cycle, on someone’s card or as a pilot that quietly became permanent. This is the first budget where it has to be a proper line, and it is really three lines, only two of which people remember.
| Line | What it covers | How to forecast it |
|---|---|---|
| Licences | Per-seat cost of coding assistants and agents. | Base it on active users rather than headcount. Silent seats are the easiest saving you will find all year. |
| Consumption | Inference and usage-based charges, which scale with behaviour rather than with headcount. | The hardest line to predict. Model a range, not a point, and set an alert threshold rather than discovering it at invoice time. |
| Downstream cost | More services, more telemetry, more query load, more review time. Usually lands on platform or infrastructure. | Plot infrastructure spend against service creation rate. If the line bent when agents rolled out, attribute it honestly. |
The third line is the one that damages credibility when someone else finds it first. We covered the mechanism in the AI bill nobody budgeted. Bringing it into your own budget voluntarily, with the attribution explained, is far stronger than having the platform team raise it in the same meeting.
Against those three costs you need a return. Not adoption, a return. Adoption, impact and ROI as three separate figures, with the method in the AI ROI playbook and a first estimate available from the AI ROI calculator.
Headcount is the hardest ask in this cycle, and the reason most requests fail is that they describe ambition rather than constraint. “We want to move faster on the roadmap” is a wish. “Review is the bottleneck, here is the queue, here is what the delay costs, and here is the specific capability that clears it” is a business case.
Figure 2
The evidence chain behind a headcount request
Ask for the capability rather than the headcount where you can. A senior engineer who clears a review backlog is a different request from two juniors, and finance can tell the difference even when the cost is similar. Merge quality and cycle time by stage are where the constraint shows up in evidence rather than in assertion.
Qualifying development effort can often be capitalized rather than expensed, which changes how engineering appears in the accounts without changing anything about how you work. Many engineering organizations either do not claim it or claim it from a rough manual estimate that finance discounts heavily. Doing it properly, from actual effort data, is frequently worth more than any cut you were considering, and it is the fastest way to become someone finance enjoys working with. Cost capitalization covers the mechanics, and it is worth raising with your finance partner before the budget rather than during it.
Every organization spends on incidents, rework and emergency requests. Almost none budget for it, so it appears each year as an overrun and an apology. That is a presentation problem more than a spending problem.
Look at what share of effort went to unplanned work over the last four quarters, budget that share explicitly, and commit to reducing it with a named plan. A leader who forecasts their own variance and then beats it is in a very different position from one who explains it afterwards. The rework calculator and change failure cost calculator give you the numbers, and velocity and sprint commitment track it through the year.
Align with product first. If the product owner and the engineering lead present different versions of the same plan, neither gets funded. Non-technical leaders will ask both, and any daylight between the answers reads as disagreement about whether the work is needed at all.
Lead with the business question, not the engineering answer. The CFO is not interested in deployment frequency. They are interested in cost, risk and time to market. Translate: faster cycle time becomes earlier revenue recognition, lower change failure rate becomes less unplanned spend, capitalizable effort becomes a different line on the P&L.
Bring the trend, not the snapshot. One quarter proves nothing and everyone knows it. Four quarters of the same metric, defined the same way, is what makes a forecast believable. This is also why the baseline work matters long before budget season.
Name the thing you are not going to do. Budgets that fund everything get trimmed arbitrarily. A budget that says explicitly which initiative is being dropped at this funding level moves the decision back to the business, where it belongs. There is more on handling that conversation in the questions boards actually ask and in engineering metrics that matter to the board.
A budget defended in Q4 and never looked at again becomes next year’s credibility problem. Review actual against plan quarterly on the same four categories, watch the consumption line monthly because it moves fastest, and set targets with notifications so variance reaches you before it reaches finance. Arriving at the next planning round able to say what you forecast, what happened, and why, is worth more than any single argument you can make in the room.
The short version
Build from what it actually cost, split it into run, grow, transform and unplanned, put all three AI lines in including the one on someone else’s budget, justify headcount with the constraint rather than the ambition, and claim the capitalization you are entitled to. Then track it, so next year you are the leader whose forecasts hold.
Build the budget from real numbers
Connect your repositories and we will backfill your history, so you can see what each initiative actually cost, where effort went, and what share was unplanned, before you write a single line of the plan.
Cost and planning: Project Costs · Cost Capitalization · Resource Planning · Resource Allocation · Business Alignment · Cost per feature
Calculators: AI ROI · Cost of rework · Cost of technical debt · Cost of change failure rate · Reducing development costs
Further reading: Engineering budgets under pressure · Metrics that matter to the board · Engineering Leaders Handbook · Measuring AI ROI
Ready to unlock your SDLC productivity?
