Product & Delivery · Chapter 11 of 13
Budgets, business cases and cost, for engineers who lead
Where the money actually is, how to write a business case that survives, and the cost work that is worth doing.
Engineers who move into leadership are usually given a budget with no training and discover that the vocabulary is the barrier rather than the arithmetic. This chapter is the vocabulary, the shape of a real budget, and how to argue for money in terms the person holding it recognises.
Where the money actually is
The proportions surprise people the first time they see them. Salaries and associated costs are typically 70 to 85% of an engineering budget. Cloud is frequently 5 to 15% and receives most of the attention, because it arrives as a bill with line items and salaries do not.
The consequence worth stating plainly: one senior engineer costs more per year than a great many infrastructure line items. A week of five people's time spent optimising a modest monthly bill is not a saving — it is a loss, dressed as diligence. That is not an argument against cost work; it is an argument for doing the arithmetic on the cost work itself before starting it, which almost nobody does.
The vocabulary, which is most of the barrier
| Term | What it means | Why an engineer should care |
|---|---|---|
| Operating expenditure | Ongoing costs — salaries, subscriptions, cloud | Hits this year's profit in full |
| Capital expenditure | Assets used over several years — hardware, sometimes capitalised software | Spread across years, so it lands lighter on this year's number. This is why finance sometimes prefers buying to subscribing |
| Capitalisation | Treating some development effort as building an asset rather than as an expense | Engineering time on new capability can sometimes be capitalised; maintenance cannot. This is why your finance team wants to know what proportion of your time goes to new work |
| Run rate | Current spend annualised | The number an executive holds in their head |
| Total cost of ownership | Everything over the asset's life, including people | The correct basis for any build-versus-buy comparison, and the one people leave the people out of |
| Payback period | How long until the saving covers the cost | Frequently more persuasive than a return percentage, because it is concrete |
The capitalisation row is the one worth understanding properly, because it explains a request that otherwise seems bureaucratic. When finance asks what share of engineering time went to new features versus maintenance, they are usually asking an accounting question, not a productivity one — and giving them a defensible number is genuinely useful to the business. It is also why the commercial delivery frameworks put an impact or new-capability percentage at the centre: it is the number that translates.
Writing a business case that survives
Four elements, and the third is the one people skip
1 · The problem, in the reader's units. Not ‘our pipeline is slow’ — ‘engineers wait an average of 40 minutes per change, which across 30 engineers and 400 changes a month is roughly 260 hours, or about 1.5 full-time engineers of pure waiting’. Convert to the unit the reader controls.
2 · The intervention and its cost, honestly, including the people-time. A project that is ‘free because we will do it ourselves’ costs whatever those people would otherwise have built, and pretending otherwise damages your credibility the second time.
3 · What happens if you do nothing. This is the element that is almost always omitted and it is frequently the strongest part of the argument. Costs that grow, risk that accumulates, a dependency going out of support, attrition. A business case that only shows upside competes with every other upside; one that shows a rising cost of inaction has a clock on it.
4 · A confidence range and what would change it. ‘We expect to recover the cost in seven to eleven months; the main uncertainty is how much of the estate needs migrating, and we will know that within three weeks.’ A range with a named uncertainty is more credible than a point estimate, and it protects you when the number moves.
And one framing that consistently outperforms: offer options rather than a request. Do nothing, do the minimum, do it properly — each with a cost and a consequence. Decision-makers respond far better to a choice than to an ask, and presenting three options makes you the person helping them decide rather than the person wanting something.
Build versus buy, done honestly
Engineers systematically underestimate the cost of building and overestimate the cost of buying, for a reason worth naming: the cost of building is our own time, which feels free because it is already budgeted, while the cost of buying is an invoice that requires approval.
- Include the whole life. Building costs the initial build plus maintenance, on-call, documentation, and the ongoing salary of whoever owns it — forever, or until someone does a migration.
- Include the opportunity cost. The team building an internal tool is not building the thing your company sells. That is frequently the largest term and it never appears in the comparison.
- Ask whether it is differentiating. Build what your customers pay you for. Buy what everyone needs and nobody chooses you for — authentication, payments, log aggregation, feature flags. The clearest form of this question is: would a customer ever choose us because of this?
- And check the exit before you sign. What does leaving cost? A vendor with your data in a proprietary format and no export has priced in your switching cost, and you will discover it at renewal rather than at purchase.
Cost work that is actually worth doing
From the cloud economics chapter, the interventions ranked by return per hour of effort — and note that the ordering is close to the reverse of what most organisations attempt:
- Turn things off. Non-production environments outside working hours. No negotiation, no architecture change, and the largest reliably-available saving most organisations have.
- Right-size before committing. Buying a multi-year commitment on over-provisioned resources locks the waste in. The order is routinely inverted because purchasing is easier than measuring.
- Then commitments on the stable base, layered with staggered expiry.
- Then the invisible internal costs — data transfer between zones, metered gateways where a free path exists, observability spend that nobody governs.
- And the one that is invisible to a finance team: in a container platform the bill is driven by requested resources rather than by what is used, and right-sizing requests typically reclaims a third to a half of the cluster cost. Nobody outside engineering can see this, which makes it your responsibility to raise.
The organisational point that matters more than any technique: give teams visibility, not targets.
Teams that can see their own spend reduce it without being asked, because engineers are generally uncomfortable with obvious waste once it is attributed to them.
Teams handed a target cut whatever is easiest to cut, which is usually a non-production environment somebody needed or a redundancy that was load-bearing. You get the number and a hidden liability.
So the highest-value cost governance is attribution — tagging, showback, a dashboard per team — long before it is control. And the corollary: if you cannot attribute spend to a team, no amount of policy will reduce it, because nobody owns it.
Talking about money in an interview
Engineering leadership interviews increasingly probe commercial literacy, and most candidates have none. Three things that land:
- A number you moved, with the mechanism. Even a small one. ‘We reduced warehouse spend 30% by moving two dashboards off live query and pre-aggregating’ is more convincing than a large architecture you never measured.
- A trade-off you named honestly. ‘We could have saved more by consolidating environments and it would have slowed the team, so we did not’ demonstrates that you weigh things rather than optimise one.
- And a business case you lost. Being able to say what you would argue differently is a stronger signal than an unbroken record, because everyone who has asked for money has been refused.
Check yourself