Technical debt isn't old code. It's a tax.

Technical debt gets framed as old code. It isn't. It's a tax — paid every quarter, in calendar time and team morale, on every piece of work that touches the affected parts of the system.

The reason it gets ignored is that it doesn't show up as a line item. There's no invoice for "shipping took 40% longer this quarter because the auth layer is a minefield." There's no row in the P&L for "the senior engineer spent two days reviewing a change that should have taken two hours, because nobody trusts the test suite." The cost is real, but it's diffuse, so it loses every prioritisation conversation against features that have a clean ROI story.

Meanwhile, the tax compounds. Bugs take longer to find because the code is harder to read. New hires take longer to ramp because the system doesn't behave the way the docs say. Good engineers leave because shipping anything feels like wading through cement, and the ones who stay get worse at their jobs because the environment punishes care. Eventually the only honest path forward is a rewrite, which costs an order of magnitude more than the maintenance you skipped.

The move isn't a heroic refactor sprint. Those rarely work — they sprawl, they don't ship, and they create a parallel system nobody owns. The move is a small, permanent allocation: 10–20% of every cycle goes to paying down debt in the parts of the system you're actually working in. No grand plan. Just the rule that you leave each area cleaner than you found it.

Here's the test I use: ask the team to estimate a small, well-understood change in the worst part of the system. If the estimate is more than 3x what it would be in a clean codebase, the tax is now structural — and ignoring it is the most expensive decision on the table.