Technical Debt Is Not the Problem You Think It Is
Most teams use 'technical debt' to describe something much more specific — and much more fixable — than the term implies.
Every engineering team I've led has had a version of the same conversation. The engineers want to "pay down technical debt." The business wants to ship features. The conversation gets framed as a tradeoff — sustainability vs. velocity — and it never fully resolves.
I've come to think this framing is wrong. Not because the tension isn't real, but because "technical debt" is almost always the wrong name for what's actually happening.
What teams actually mean
When engineers say "technical debt," they usually mean one of three things:
Legacy complexity — code that was written under constraints that no longer apply, that nobody fully understands anymore, that's expensive to change. This is real and accumulates quietly.
Deferred decisions — places where the team made a pragmatic choice that was right for the moment but created a known obligation. "We'll clean this up after launch." This is what the original technical debt metaphor actually described.
Bad code — code that shouldn't have been written the way it was. Not a strategic tradeoff, just a mistake that wasn't caught or corrected.
These three things have different causes, different costs, and different solutions. Treating them as one thing ("technical debt") is why the conversation never lands anywhere useful.
Why the framing breaks down
The financial metaphor implies an obligation with a predictable cost structure — you borrow, you repay with interest, you know roughly what you owe. Technical complexity doesn't work like that.
The cost of legacy complexity isn't linear. It's fine until it isn't, and then it's catastrophic. The system that nobody fully understands doesn't accumulate cost — it waits. And then one day you need to change something in that system, and you discover the real cost all at once.
Treating this as "debt" implies it's on a repayment schedule. It isn't. It's deferred risk.
The question I ask instead
Rather than asking "how much technical debt do we have?" I ask: what are we afraid to change?
That question surfaces the things that actually matter. If engineers are afraid to deploy on Fridays because the payment system is fragile, that's a concrete, specific problem with a solution. If they're afraid to touch the authentication layer because nobody wrote tests for it, that's a different concrete problem.
"Technical debt" is the symptom. The question is: what specific thing is hard, why is it hard, and what would it take to make it easier?
The teams I've seen handle this well are the ones that make the implicit explicit. They don't set aside a "20% time for tech debt." They identify specific systems that are constraining velocity, scope the work to make them less constraining, and prioritize that work in their planning like any other prioritized work.
That's not debt repayment. That's just good engineering leadership.