Most leadership teams have heard “we need time for technical debt” more than once. It usually comes as a request for a sprint, or a share of capacity, with a loose promise that things will go faster afterwards. Leadership hears less feature work for an unclear return, and the request loses to whatever has a revenue number attached.
Engineering is usually right that the debt is real. The trouble is that it’s presented in engineering terms to people who decide in business terms. Debt nobody can price doesn’t get prioritised, so it grows until it turns into something nobody can ignore: an outage, a missed launch, or a senior engineer handing in their notice.
Where the cost shows up
Technical debt rarely gets its own line in the budget. It shows up in places that are already measured, just not attributed to it.
Slower delivery. A change that should take a week takes three, because the code around it is fragile, undocumented or tested by hand. Spread across a year of roadmap, this is often the biggest cost of all.
Incidents. Outages, failed releases and payment errors that keep tracing back to the same few parts of the system. Each one costs lost revenue, support contacts, and engineering time pulled off planned work.
Repeated work. On multi-brand and multi-market platforms, a change that should be made once gets made five times, because each brand runs its own version of the same component. Each version is tested separately too, and in regulated markets, documented for compliance separately.
Deadlines you don’t control. An outdated library, an integration the vendor stops supporting, an API version a payment provider is about to retire. Nothing happens until the deadline arrives, and then everything else waits.
People. Engineers who spend their weeks working around the same problems eventually leave. The ones who know where the problems are tend to be the most senior.
Putting a number on it
The aim is a rough figure leadership can compare with other investments. It doesn’t need to be precise. An estimate that’s within a factor of two is enough to make a decision.
Start with time. Take the last quarter and ask the team to flag the work that was slowed down or caused by a known problem area. In most ticketing tools that’s a label and a filter, not a project. Convert the extra hours into cost using a fully loaded engineering rate.
Add incidents from the same period that came from those areas, with a rough estimate of revenue lost and hours spent on recovery.
Add the repeated work. Where the same change had to be built and tested several times because brands or markets have drifted apart, count the extra cycles.
Then price the fix. What would it cost to pay down the debt in the one or two worst areas, and how much of the recurring cost would that remove?
Say a company finds that its checkout code was involved in a third of last quarter’s delays and two of its four incidents. The extra engineering time comes to around 40,000 euros a quarter, and the incidents cost roughly the same again in lost sales and recovery. Rebuilding the fragile part is estimated at 60,000. Framed like that, the work pays for itself in well under a year, and it can be ranked against a new feature on the same terms.
Running it
Avoid the single large programme. A request to “fix technical debt” for a whole quarter is the hardest kind to approve and the easiest to lose control of. Name specific areas, each with its own cost, fix and expected saving.
Put those items on the same roadmap as everything else. When debt work sits on a separate list, or competes under separate rules, it loses. When it carries a cost and a payback like any other item, it wins often enough.
Keep a standing share of capacity for small fixes, somewhere between 10 and 20 percent. That covers clean-up too small to price, and lets engineers fix things as they pass through them. Leave it to the team to decide how to use it, and ask for a short note each month on where it went.
Then check the result. If an area was rebuilt to remove delays and incidents, look a quarter later at whether delays and incidents actually went down. That review is what earns trust for the next request.
What to ask when it comes up
Next time engineering raises technical debt, ask where exactly it is, what it’s costing now and in what form, and what fixing the worst of it would cost and return.
A team that can answer is giving you an investment case, and it deserves to be judged like one. A team that can’t answer yet should get a few weeks to find out. The debt is costing money in the meantime either way.
