Technical debt is a measurable drag, not a metaphor

'Technical debt' sounds like an excuse until you measure the time it consumes. Stripe's Developer Coefficient survey estimated that developers spend roughly 42% of their working time dealing with maintenance issues and bad code, and put the global opportunity cost in the tens of billions of dollars a year.

Whatever the exact figure in any one organisation, the pattern is consistent: a large fraction of expensive engineering capacity goes not to new capability but to working around decisions made years earlier.

The research behind Accelerate and the annual DORA reports gives a complementary view. The strongest-performing teams deploy far more frequently, have dramatically shorter lead times, and recover from incidents much faster than low performers. Technical debt is one of the things that separates the two groups: it lengthens lead times and makes every change riskier.

Debt also compounds. Each shortcut raises the cost of the next change built on top of it, until routine work that should take days takes weeks and breaks things elsewhere.

The instinct to pause feature work and 'fix the debt' rarely survives contact with the business. The more durable approach is to pay debt down in the course of delivery: isolate the worst areas behind stable interfaces, replace them incrementally, and clean up the data model where the hardest problems usually live.

Treated this way, modernisation is not a separate line item competing with delivery. It is how delivery stays fast.