Engineering Leadership · Chapter 7 of 9
Budget, headcount and making the case
Where engineering leadership is decided, and the language most engineers never learn.
Above EM, a growing share of the job is arguing for resources with people who do not think in engineering terms. Leaders who cannot do this get smaller teams regardless of how well they deliver.
Translating engineering into the language of the decision
| What you want to say | What actually lands |
|---|---|
| We need to reduce technical debt | This is costing us N engineer-weeks a quarter, here is the measurement |
| We need more headcount | Here is the work we will not do without it, and what that costs |
| The platform team is valuable | Without it this work happens 40 times instead of once, badly |
| We need to improve reliability | Last quarter's incidents cost X in engineering time and Y in customer impact |
| This migration is important | Here is the run-rate saving and the date it starts, and the risk if we do not |
Two habits that make the case credible
- Volunteer the weakness in your own number. ‘This assumes recovered time converts to output, which it does not do one-for-one — so treat it as a range’. A finance audience trusts a caveated number far more than a clean one, because they know clean ones are constructed.
- Frame the alternative honestly. The work does not disappear if it is not funded; it gets done worse, elsewhere, and shows up as slower delivery rather than as a line item. The question is not whether to pay, but whether to pay once or many times.
Cloud and vendor cost, which is now yours
Cost and budget language appears in roughly 40% of the leadership and delivery postings behind this site. You will be expected to have a position on cloud spend per unit of business value, on build versus buy, and on which vendor relationships are strategic. Being unable to discuss the infrastructure bill is a visible gap at director level and above.
Making the case in the language it will be judged in
Engineering proposals fail in finance conversations for a consistent reason: they are argued in engineering terms — reliability, technical debt, developer experience — to an audience that allocates against revenue, cost and risk. The translation is learnable and it is most of the skill.
| Engineering framing | Translated |
|---|---|
| "We need to pay down technical debt" | "Change takes three times longer in this area than elsewhere; here is the delivery cost per quarter, and here is what it would be after" |
| "We need better reliability" | "Last quarter's outages cost X in credits and Y in support load. This reduces the class of failure that caused two of the three" |
| "We need developer tooling" | "Engineers spend N hours a week waiting on builds. At a loaded rate that is Z per year, against a one-off cost of W" |
| "We need to migrate off this platform" | "Support ends on this date. After it, we carry unpatched security exposure and no vendor recourse. Here is the cost of doing it now versus under pressure" |
The load-bearing move in all four is the same: convert to a number, name the baseline, and state what happens if you do nothing. That last part is what separates a request from a case — every proposal competes against ‘not yet’, and only the do-nothing cost argues against it.
Three things that make a case credible, and their absence is what gets one sent back.
Include the cost of the change itself — engineering time at a loaded rate, dual running, migration risk. A case with no implementation cost reads as naive and is the first thing a finance partner looks for.
Give a range with a stated downside, not a point estimate. The reader already knows the point estimate is wrong and is trying to establish by how much; a range answers the question they were about to ask.
Separate cost reduction from cost avoidance and label them. Reduction means a line goes down and is visible in a budget; avoidance means a line would have gone up. Both are real, only one appears in a budget, and presenting avoidance as reduction is the fastest way to lose a finance audience permanently.
And name the payback period unprompted. Most organisations have an implicit threshold; not mentioning it invites the question rather than answering it.
Check yourself