Technical Debt: What It Costs and How to Put a Number On It

Technical debt is not a metaphor for messy code. It is a standing charge against your future engineering capacity, and like any debt, it compounds if the interest is never paid down.

What the evidence says it costs

McKinsey surveyed 50 CIOs at financial services and technology firms with revenues above $1 billion. They estimated technical debt at 20–40% of the value of their entire technology estate, before depreciation, and reported that 10–20% of their budget for new products was diverted to resolving debt-related issues rather than building anything new. Sixty percent said their debt had grown noticeably over the previous three years. (McKinsey, 2020)

This is a small sample, self-estimated, drawn from two sectors — not a number to treat as universal. But it aligns with what developers report from the inside. In Stack Overflow's 2024 survey, 62.4% of the 28,251 professional developers who answered the relevant question named technical debt their top frustration at work, by a wide margin over the next-ranked item. (Stack Overflow)

Two independent measurements — executive estimate and developer sentiment — pointing the same direction is more persuasive than either alone.

Why it compounds

Every quarter debt goes unpaid, two things get worse simultaneously. The codebase gets harder to change safely, so new work takes longer. And new work keeps being added on top of the same shaky foundation, so the next unit of debt costs more to service than the last one did.

This is why "we'll fix it later" is rarely a neutral deferral. Later is more expensive than now, and the gap grows the longer it's left.

A practical way to size it in your own codebase

You do not need McKinsey's survey infrastructure to get a working number. Track four things over a month:

Time spent on unplanned work. DORA's research found that even elite-performing engineering teams report spending only about 50% of their time on new work, the rest on unplanned work, rework, defects and support. (DORA) If your team is well below that on the "new work" side, debt is very likely part of the reason.

Time-to-change on your oldest modules versus your newest. If a comparable feature takes twice as long to build in an old part of the system, that difference — in engineer-hours, priced at loaded cost — is debt service you're paying on that specific area.

Defect rate by module. Debt-heavy code tends to break more often for the same amount of change. Track it, and you have a second, independent signal pointing at the same modules.

What developers actually say. Ask your own team where they lose the most time to workarounds. They usually know exactly where the debt lives, and asking costs nothing.

What to do with the number once you have it

Debt service that eats 10–20% of your new-product budget, unaddressed, does not stay flat — the McKinsey data suggests it grows. Treating debt reduction as a recurring line item, not a one-off cleanup sprint, is the only approach consistent with the fact that it compounds. A single "tech debt week" against a 20–40% estate-wide problem is a rounding error, and pretending otherwise wastes the one sprint you spent finding that out.

Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions. Every statistic here is linked to its original published source, with sample sizes and limitations stated where they matter.