Strategy · May 2026 · 6 min read
The real cost of tech debt
Tech debt doesn't announce itself. It hides in the feature that took three weeks instead of three days. Here's a number leadership will act on — and the one metric that proves the payback.
Ask a team how much tech debt costs and you'll get a shrug. It doesn't show up on a balance sheet. It shows up as the feature that should have been a day and took a week, the test suite nobody trusts so nobody runs it, and the quiet attrition of engineers who'd rather build than excavate.
The reason it never gets paid down is that the cost is diffuse and the payment is invisible. To fix that, you have to make the cost a single, legible number — and tie the payback to a metric the business already watches.
Put a number on the slowdown
We measure lead time for a standard change — the median time from 'ready' to 'in production' — and we track it against a baseline from when the system was young. The gap, multiplied by the number of changes a quarter, is your debt tax in engineer-weeks. It's not perfect, but it's legible, and leadership can read a number in weeks the way they read a number in dollars.
Debt you can't measure is debt you'll never pay. Make the slowdown visible and the conversation changes overnight.
Then pay it back the way you'd pay any debt: a fixed, protected slice of every sprint, not a heroic quarter when things are quiet — because things are never quiet. Watch the lead-time number fall as you go. When it stops falling, you've paid enough, and the team that used to dread the codebase starts volunteering for the hard parts again. That's the real return on the investment — not the weeks saved, but the team you get back.
Put this to work on your stack
Every article here came out of a real engagement. If the problem sounds like yours, a free audit is the fastest way to see what it'd look like applied to your systems.
Get a free audit