Taming tech debt on a team that has to keep shipping

Every team I have worked with says they want to fix their tech debt and almost none of them ever get the quarter to do it. That quarter is not coming. The product roadmap is full, the business needs features, and a big stop-the-world cleanup project is a fantasy that gets cut the moment priorities tighten. So taming tech debt has to happen while you keep shipping, woven into normal work, or it does not happen at all. The good news is that the continuous approach works better anyway. The big rewrite usually ends in tears.

Not all debt is worth paying

The word debt makes people think all of it must be repaid. It does not. Plenty of ugly code sits in a corner nobody touches, working fine, costing nothing. Rewriting it is pure waste. The only debt worth your attention is the debt you keep paying interest on: the code you fight every time you add a feature near it, the module that breaks in a new way each release, the thing everyone is quietly afraid to change.

That distinction changes everything. Instead of asking what code is bad, I ask where the team keeps getting slowed down or burned. That is where the real debt lives. Beautiful refactors of code that never changes anyway feel productive and accomplish nothing. Follow the pain, not the ugliness.

Let the work tell you where to dig

The most reliable way to find the debt that matters is to watch where the friction shows up during real feature work. When a task that should take a day takes four, and the extra three were spent wrestling some tangled part of the system, that part just told you it is expensive. I keep a running note of these moments. Over a few weeks a pattern appears, and it is rarely the part everyone complains about loudly. It is some quieter module that taxes everything that goes near it.

Signals I treat as debt worth fixing:

• The same area causes bugs release after release, so the design itself is fighting you
• People route their changes around a module instead of through it because touching it is scary
• Onboarding a new engineer to one part of the system reliably takes far longer than the rest

Pay it down inside the work you already have

The approach that actually fits a shipping team is the campsite rule: leave the code a bit better than you found it, every time you are in there for a feature anyway. You are already in the file, already loading the context into your head, already going to test it. Cleaning up while you are there is the cheapest possible time to do it. A name fixed here, a function split there, a dead branch deleted. None of it needs a special project or anyone's permission.

When a piece of debt is too big for that, I do not ask for a cleanup quarter. I attach it to a feature that has to go through that area regardless. The refactor rides along as part of delivering something the business already wants. That framing gets approved when a standalone cleanup ticket never would, because it is tied to value the team actually asked for.

Make the cost visible to non-engineers

Tech debt loses the priority fight because it is invisible to everyone who decides priorities. A product manager sees features ship and does not see the codebase getting harder to work in until velocity has already cratered. My job is to make that cost legible in their language, not mine. Not this code is ugly, but this feature took three times longer because of how this part is built, and the next five features near it will too.

When you connect the debt to delivery speed, the conversation changes. Suddenly fixing it is not a vanity project, it is the reason the next quarter of features can ship on time. That is an argument a business actually listens to, because it is about output, not aesthetics.

Why the big rewrite is a trap

It is tempting to declare the whole thing beyond saving and start over. I have watched several of these. The rewrite always takes far longer than the estimate, the old system keeps needing changes the whole time so now you maintain two, and the new one quietly accumulates its own debt before it even ships. Meanwhile the business froze, waiting. Most rewrites I have seen either got cancelled halfway or shipped late and underwhelming.

Incremental almost always beats the rewrite. Strangle the bad part piece by piece while the system keeps running and shipping. It is less satisfying than a clean slate and far more likely to actually finish. Taming tech debt is not a heroic project you complete once. It is a habit you keep, applied to the parts that actually cost you, while the product keeps moving the entire time.