How to Decide Which Technical Debt to Pay Down First

A genuinely ugly piece of code that nobody has touched in a year costs you almost nothing right now. A moderately messy module that every feature this quarter has to touch is actively slowing the whole team down every single week.

Weight your debt list by how often engineers actually work in that area, not just by how bad it looks. The worst code in your system, if it's untouched, is a lower priority than mediocre code sitting directly in your team's daily path.

A team's deployment frequency tends to drop quietly as debt accumulates in the areas people touch most, because every change in a tangled area takes longer to test and ship safely¹. If your deploy cadence has been slowing down over the last few months without an obvious external cause, that's worth investigating as a debt signal before it's treated as just a busy quarter.

This is a more honest metric than a subjective "the code feels bad" complaint, because it's something you can actually track over time and point to when arguing for remediation time.

Some technical debt is purely aesthetic, inconsistent naming, an outdated pattern that still works fine. Other debt is structural, tight coupling that makes every change risky, a missing test suite that makes refactoring dangerous. The structural kind deserves priority even when it's less visually offensive, because it's the kind that compounds.

When you're building your priority list, tag each item honestly: is this slowing anything down, or does it just bother the engineer who has to look at it? Both are valid to note, but only the first kind should compete for sprint time against features and bug fixes that have a clearer, more immediate payoff for the business this quarter and the next.

For example, a team lists two items. One is an inconsistent naming scheme in a billing module nobody has changed in a year. The other is a missing test suite around the order flow that every feature this quarter touches. The naming issue is visible and irritating, but it costs almost nothing. The missing tests make each change risky and slow, so they go first. Log the naming issue, tag it as aesthetic, and revisit it at the next quarterly pass rather than letting it compete with features and bug fixes for sprint time.

The teams that actually make progress on debt set aside a consistent share of engineering time for it, every sprint, and treat that time as non-negotiable the same way they'd treat a security fix. Teams that only address debt "when things slow down" never get to it, because things are always busy.

Whatever share you choose, the discipline of protecting it consistently matters more than the exact number. A team that skips debt work every time a deadline looms never actually pays it down.

Not everything on the list deserves a fix. If an area is genuinely untouched, isolated, and working, the right call is often to formally remove it from the list rather than let it sit there as guilt. A shorter, honest list that the team actually works through beats a long, sprawling list nobody believes will ever get fully done.

Debt lists rot just like code does. An item that was critical eight months ago might no longer matter because the surrounding code was rewritten for unrelated reasons, and an item that seemed minor might now sit directly in the path of your most active feature work.

Set a recurring quarterly pass to re-score the whole list, not just add new items to the bottom. A list that only grows and never gets pruned stops being a useful prioritization tool and turns into background noise nobody trusts, which defeats the point of tracking it at all, and makes the whole exercise feel like busywork instead of a real prioritization tool the team actually trusts and uses when planning the next sprint.

Prioritize each item on the debt list with these questions:

• How often do engineers actually work in this area, compared with how bad the code looks?
• Is the debt structural, such as tight coupling or a missing test suite, or only aesthetic?
• Has deploy frequency dropped in this area without an obvious outside cause?
• Is the area untouched, isolated, and working, which makes it a candidate for removal from the list?
• Does the item still matter after the last quarter of unrelated rewrites in the surrounding code?