When to Pay Down Technical Debt (And When Not To)

I wrote previously about treating technical debt as a budget item. But having a 15% allocation does not tell you which debt to pay down first. That prioritization decision is where most teams struggle.

The Prioritization Matrix

I evaluate technical debt on two axes: impact on delivery and cost of remediation.

High impact, low cost — do it now. A flaky test that causes the pipeline to fail twice a week and takes thirty minutes to fix is high impact, low cost. These are the easy wins that pay immediate dividends. I pick these off during regular sprints.

High impact, high cost — plan it. A monolith that needs to be decomposed into services is high impact but requires significant investment. This goes on the roadmap as a planned initiative, not a sprint task. I build a business case and negotiate dedicated capacity.

Low impact, low cost — batch it. Minor code quality issues, outdated comments, small refactors. I batch these into a "hygiene" task each sprint. A developer picks up three or four of them when they have a gap between larger work items.

Low impact, high cost — probably skip it. A legacy system that works fine but uses an old framework. Nobody touches it frequently. The refactoring cost is weeks of effort. Unless there is a compelling reason — security vulnerability, end of support — I leave it alone.

How I Assess Impact

Impact is not about code quality in the abstract. I measure it by asking: is this debt causing bugs? Is it slowing down development? Is it creating security risk? Is it making onboarding harder?

If the answer to all four is "not really," the debt can wait regardless of how ugly the code looks.

The Trap to Avoid

Engineers often want to refactor because the code offends them aesthetically. I respect that instinct — it usually comes from good judgment. But in a resource-constrained environment, aesthetic refactoring competes with features that deliver client value. The PM's job is to balance both without dismissing either.