Every engineering team I've ever worked with has tech debt. That's not the problem. The problem is the teams that have stopped feeling bad about it — the ones where "we'll clean it up later" has quietly become official policy, and nobody notices because the app still ships. Tech debt tolerance is an engineering culture problem, and it's harder to fix than the debt itself.
We've Normalized the Wrong Thing
There's a version of the tech debt conversation that's healthy: you consciously take on debt to hit a deadline, you document it, you schedule the paydown. That's a legitimate trade-off. Teams do it all the time and come out fine.
But that's not what I usually see. What I usually see is debt that accumulated invisibly — no decision was ever made, no trade-off was ever named. It just happened, because everyone was moving fast and the test suite was "good enough" and that one service that nobody wants to touch has been that way since 2019. The debt wasn't chosen. It was tolerated. And there's a massive difference.
Chosen debt has an owner and a plan. Tolerated debt has neither. It just sits there compounding, making every new feature slightly more expensive than the last, until one day a two-hour task takes two weeks and nobody can explain why the estimates are always wrong.
The Steel-Man Case for Leaving It Alone
Let me give the other side a fair hearing, because it's not entirely wrong.
- Refactoring has a real opportunity cost. Every sprint you spend cleaning up old code is a sprint you're not shipping features users asked for. That's a legitimate business concern, not just an excuse.
- Not all debt is equal. A messy internal utility that one developer touches twice a year is not the same as a tangled authentication flow that every new feature has to route through. Prioritizing ruthlessly is smarter than treating all debt as equally urgent.
- Some debt expires naturally. If you're planning to replace a subsystem in six months, deep-cleaning it today is pure waste. The pragmatic call is to leave it and build the replacement cleanly.
All of that is true. None of it justifies a culture where debt is never named, never tracked, and never paid down — where "pragmatic" has become a euphemism for "we've given up."
How You Can Tell the Difference
Here's the diagnostic I use. Ask your team these three questions:
- Can you name the five riskiest areas of the codebase right now?
- When was the last time you paid down a piece of debt on purpose — not as a side effect of a feature, but as a planned work item?
- Is there any part of the system that new engineers are quietly warned away from during onboarding?
If the answers are "not really," "I can't remember," and "yes, definitely" — you don't just have a tech debt problem. You have a tech debt culture problem. The debt has become load-bearing. People have built workflows around it, workarounds on top of it, and institutional knowledge about it — knowledge that lives only in people's heads because nobody ever wrote it down because the plan was always to replace it eventually.
What a Healthier Culture Actually Looks Like
I'm not going to tell you to dedicate 20% of every sprint to refactoring. That's a rule that sounds good in a conference talk and falls apart the first time you're behind on a release. Real debt management is less ceremonial and more habitual:
- Name it when you create it. If you're cutting a corner to hit a deadline, open a ticket the same day. Not a vague "TODO: clean this up" comment — an actual backlog item with context on what the shortcut was and what good looks like.
- Make the cost visible. When a feature estimate balloons because of existing debt, say so explicitly in the planning meeting. "This would be a three-day task in a clean system; it's ten days because of the way the data layer is structured." Visibility creates pressure.
- Treat the scariest files as signals, not fixtures. If there's a file everyone dreads opening, that's not a personality quirk of your codebase — it's a risk register item. It will bite you. The only question is when.
- Refactor on the way through, not as a separate project. The most sustainable paydown I've seen happens when engineers clean up the area they're already working in — not perfect, not everything, just "leave it better than you found it." Tiny improvements compound just like debt does.
Where I Land
Tech debt is a tool. Used deliberately, it's a reasonable trade-off that mature teams make all the time. But tech debt culture — the kind where nobody tracks it, nobody owns it, and the response to every slowdown is "yeah, that part's always been rough" — that's an organizational failure masquerading as a technical one.
The codebase reflects the decisions, habits, and values of the team that built it. If your debt is invisible and growing, that's not bad luck. That's a culture that made peace with it. And the only way to fix a culture problem is to first refuse to treat it as normal.
Start naming it. Start tracking it. Start saying "this is costing us" out loud in rooms where product managers can hear you. The discomfort of that conversation is exactly the pressure that keeps debt from becoming permanent furniture.
