Making a technical debt case your stakeholders will fund

Every planning cycle, your teams ask for time to fix the things that slow them down, and every planning cycle the request loses to features. It isn't that your product partners don't care. It's that they are comparing a feature with a named customer, a date and a revenue line against "we need to refactor the order service," which sounds like engineers wanting to tidy their room. When you manage several teams, the problem multiplies: each team has its own list, none of it is costed, and you end up either fighting for a blanket percentage or quietly hiding cleanup inside feature estimates.

There's a better way to ask. Treat the debt the way the metaphor suggests: show what it costs now, what it costs to pay down, and when the investment pays back. This post walks through building that case for one piece of debt, with a worked example and a one-page template.

Why the usual request doesn't get funded

Most technical debt requests fail for one of three reasons:

• They describe the code, not the cost. "The billing module has no tests and a tangled data model" is true and means nothing to someone who doesn't work in it.
• They ask for everything. A backlog of 60 debt items with no ranking tells stakeholders the team can't prioritize either.
• They have no end. "Give us 20% for tech debt" with no outcome attached looks like a permanent tax. People resist permanent taxes.

A blanket allocation for technical work is still useful as a baseline (the PTMA study guide discusses typical ranges). But when you need more than the baseline, or a specific multi-week investment, you need a case built around one item.

Find the debt that is charging interest

Ward Cunningham introduced the debt metaphor in 1992. Martin Fowler's later article on technical debt makes the point that matters most for building a case: the interest is "the extra effort that it takes to add new features," and you only pay it when you work in that part of the system. Messy code nobody touches costs almost nothing. Fowler concludes that "crufty but stable areas of code can be left alone," while areas of high activity deserve zero tolerance.

So the first job is to find debt that sits where your teams work most. Three sources, all of which you probably already have:

1. Change frequency. Which files, modules or services have the most commits over the last six months? Your version control history answers this. Adam Tornhill's Your Code as a Crime Scene builds a whole method around combining change frequency with complexity to find "hotspots"; even the crude version, a count of changes per module, is revealing.
2. Incident sources. Which components show up again and again in incident reviews and bug tickets?
3. The team's own list. Ask each team: "Which part of the system do you dread changing, and what did it cost you last time?" Engineers usually know exactly where the pain is.

Where all three overlap, you have a candidate. Pick one. A case for one well-chosen item gets funded far more often than a case for a list.

Put a price on the interest

Now measure what the debt costs per quarter. You don't need precision; you need a defensible number with the method written next to it.

Say one of your teams of eight owns a pricing module (a hypothetical example). Over the last quarter:

At roughly 60 working days in a quarter, 35 engineer-days is more than half of one engineer, every quarter, spent on friction. That's the sentence your stakeholders will remember.

Some honesty rules for this table:

• Use ranges if the team disagrees. "Between 25 and 40 engineer-days" is more credible than a suspiciously precise figure.
• Count only what you can trace. If you can't connect an incident to the module, leave it out.
• Add the cost stakeholders feel directly where it exists: customer-facing incidents, a feature that had to be descoped, a launch that slipped. Name the event; don't invent a revenue figure for it.

Price the paydown and the payback

Next, estimate the investment. Have the team break the paydown into a few concrete steps and size it the same way they size feature work. For the pricing module, say the plan is: add characterization tests around current behavior, separate the pricing rules from the data access code, and retire the old discount path. The team estimates two engineers for four weeks, about 40 engineer-days.

Then estimate what the interest drops to afterwards. Be conservative: debt work rarely removes all the friction. If the team expects changes to cost about half a day extra instead of two, and incidents to drop to one a quarter, the new interest is about 10 engineer-days a quarter.

That gives you the core of the case:

• Investment: 40 engineer-days, once.
• Saving: about 25 engineer-days per quarter (35 now, 10 after).
• Payback: under two quarters, and the module keeps paying after that.

If the payback comes out at two years, that's useful too. It tells you this item shouldn't be first, and you've avoided spending political capital on a weak case.

Write it on one page

Stakeholders don't need the analysis; they need a decision. Use a page like this:

Proposal: Pay down debt in the pricing module.

The cost today: About 35 engineer-days per quarter, more than half an engineer, spent working around the module. Three incidents last quarter, one customer-facing.

The ask: Two engineers for four weeks in Q1.

What you get: A typical pricing change drops from about four days to about two and a half. Interest falls to roughly 10 engineer-days a quarter; the investment pays back in under two quarters.

What it delays: The bulk-export feature moves from February to March.

How we'll know it worked: We'll report change effort and incidents in the module for the two quarters after.

Assumptions: Effort figures are team estimates from the last 14 changes; incident costs from the incident log.

Two lines do most of the work. "What it delays" shows you understand that capacity is finite and puts the trade-off on the table instead of leaving it implicit. "How we'll know it worked" turns the request from a plea into a commitment.

Offer options, not a yes-or-no

A single ask invites a single answer, usually "not now." Give your stakeholders two or three options with their consequences:

Option B is often the one that gets chosen, and it's a good one: it follows the advice to bundle cleanup with feature work in the areas you are already changing, and to say so openly in the estimate rather than hiding it. Option C is a legitimate choice too. If pricing work is about to wind down, leaving the debt alone may be right, and now the decision has been made with the cost visible rather than by default.

Report the payback afterwards

This is the step most managers skip, and it's the one that gets your next case funded. A quarter after the work, send a short follow-up: what you said would happen, what happened, and the numbers. If a typical change in the module now takes two and a half days instead of four, say so. If the saving was smaller than promised, say that too and explain why.

Over a year, this builds a track record. Stakeholders who have seen two debt investments pay back as forecast stop treating the third as a favor to engineering. And if one didn't pay back, you've learned something about how your teams estimate debt work, which is worth knowing before the next request.

Before your next planning meeting

1. Ask each team lead for the one area they most dread changing, and what it cost them last time.
2. Cross-check against change frequency and the incident log. Pick the single item where all three point.
3. Fill in the interest table for last quarter, with the method next to each number.
4. Have the team estimate the paydown and the reduced interest, conservatively. Calculate the payback period.
5. Write the one-page case with three options, including "leave it."
6. Put a date in your calendar one quarter after the work to report what actually happened.

If you can only do one thing, do step 3. A measured cost of friction changes the conversation even before you ask for anything.