Making the case to the people who fund it

The conversation fails in a predictable place. An engineer explains that the payments module is a mess and needs time spent on it; the person holding the budget hears a request to spend money on making the code nicer, weighs it against a feature a customer has been promised, and declines — reasonably, given what was actually said. Nothing about that exchange is a communication problem. The request had no rate attached, and a rate is the only thing that makes it a business question at all.

What people usually want here is not a script. It is to understand why an argument that is obviously correct from the inside keeps losing to arguments that are weaker.

What they hear when you say debt#

The word was borrowed from finance and is almost always used without any of finance’s arithmetic. A finance person hearing “debt” expects a principal, an interest rate, a term and a comparison against what else the money could do. When an engineer says debt and supplies none of those, the word does not carry its meaning across — it becomes a technical-sounding way of saying the code is unpleasant to work in.

That reading is not unfair. It is the only one available. And it puts the request in the worst possible category: a cost with no stated return, competing against a feature with a named customer behind it. A cost with no return loses that comparison every time, and it should.

The interest, not the mess#

Martin Fowler’s formulation is the one worth borrowing wholesale, because it is already in the right currency. He describes the underlying problem as cruft — deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further — and then names the thing you are actually asking about: the extra effort that it takes to add new features is the interest paid on the debt.

That single sentence relocates the argument. The mess is not the cost. The mess is the reason for a cost, and the cost is measured in delivery time on work that is already planned. Once the case is made that way it is no longer a request for money to improve the code; it is a claim that the next four things on the roadmap are more expensive than they were quoted, with a proposal to change that.

Fowler draws a practical consequence from the same framing that is worth carrying into the meeting, because it is the part that establishes you are not simply asking for everything you want: areas of code modified frequently deserve aggressive cruft removal, because the interest is being paid continuously, while stable but messy code can be left alone without triggering interest payments at all. Volunteering which of your team’s debt is not worth paying is disproportionately persuasive. It converts you from someone who dislikes the codebase into someone doing the same triage the budget-holder is doing.

His technical debt quadrant supplies the other half, which is political rather than financial. Debt sorts along two axes — deliberate or inadvertent, reckless or prudent — and the important cell is prudent-inadvertent, which even excellent teams accumulate as a matter of course. His reason for it is worth stating in the room, roughly as he puts it: it can take a year of programming on a project before you understand what the best design approach should have been. Framed that way, the debt stops being an accusation about whoever wrote the code and becomes a normal consequence of having learned something. That matters more than it sounds like it should, because a request that implies the previous team was careless has to survive their manager as well as the numbers.

How to price it in their currency#

Pick one area, not the codebase. Interest accrues per area, and a request covering everything cannot be sized, cannot be finished, and offers the person approving it no way to tell later whether it worked. One module, named, with the roadmap items that pass through it listed underneath.

Measure the rate with what is already recorded. Nobody needs a study. Take the last four changes made in that area and four comparable changes made elsewhere, and put the elapsed times side by side, along with how many of each needed a follow-up fix within a fortnight. If the answer is that work in the payments module takes two and a half times as long and fails twice as often, that is the interest rate, stated in a unit the plan is already written in. It is an imperfect measurement and it is far stronger than any adjective, because it invites a counter-argument made of the same material.

Make the offer as a trade, not a request. “Two weeks on the payments module now; after that the three pricing changes in the autumn plan cost roughly a third less each, and the risk of a follow-up fix goes down. If we skip it, the Q4 pricing change is a six-week job rather than three.” That is a sentence a budget-holder can decide about. It has a price, a return, a term, and a stated consequence for declining, and it does not require them to have an opinion about code.

The one thing to avoid asking for is a rewrite. A rewrite has no partial return, so it can only be approved as an act of faith, and it competes against the entire roadmap at once rather than against a slice of it. The corresponding form of the same accounting on the delivery side is what it really costs to get a single change merged and out — the same insight, aimed at the pipeline instead of at the code, and useful in this conversation because it is where the other half of the interest is hiding.

Where it goes wrong#

The most common failure is the debt register, and it fails by looking like progress.

A team, frustrated at losing these arguments one at a time, decides to make the problem visible: every known piece of debt goes into a list, tagged, sized and ranked. Sixty items. The list is shown at a planning session, and from then on it exists as a category.

Three things follow. A category competes as a category, so every item in it is now weighed against the whole feature roadmap rather than against the specific feature it would make cheaper — and a general good loses to a specific promise reliably. The size of the list makes any individual payment look pointless, so the natural response to sixty items is to fund none of them rather than four. And because the list is maintained by the people who wrote it, it grows faster than it is paid down, which turns it over time into documentary evidence that the situation is hopeless.

The register also quietly removes the one thing that made an individual case winnable: its attachment to a piece of work someone wants. An item sitting in a backlog labelled “tech debt” has no advocate outside engineering. The same item, written into the estimate for the pricing change that has to go through that module, is defended by whoever wants the pricing change.

The second failure is winning with a number you invented. Under pressure it is tempting to say the cleanup will make the team forty per cent faster, because a specific figure ends the conversation. Two quarters later somebody checks. Nobody remembers the reasoning, everybody remembers the forty per cent, and the credibility spent is not recoverable in the currency it was borrowed in — which is why the range with its method shown beats the confident number every time, exactly as it does in an estimate you have to defend later.

Being able to run this argument at all — pricing a consequence before anyone has felt it, in a currency that is not yours — is one of the concrete things people mean by the step up in seniority, and it is worth seeing next to the others: what actually changes between mid and senior is when the question reaches you, and this is one of the questions.