Glossary
Learn how product teams prioritize technical debt using business impact, engineering effort, and strategic urgency - not intuition or politics.
At Salesken, we had a 'tech debt' label in Jira with 200+ tickets. When our board asked how much technical debt we had, I couldn't give them a number. That experience taught me that unmeasured debt is invisible debt.
Technical debt prioritization is deciding which pieces of technical debt to address first. It's a continuous process: identify debt, assess impact, estimate effort, rank by importance, and execute.
Not all technical debt is equal. Some debt is in systems that are critical and changing frequently. That should be prioritized. Some debt is in systems that are stable and rarely touched. That can be left alone.
Prioritization answers: "We have 20 systems with technical debt. Which 3 should we tackle this quarter?"
Resources are finite. You can't refactor everything. Prioritization ensures you focus on debt that matters most.
Bad prioritization wastes effort: refactoring a system that rarely changes, while a critical system remains brittle. Good prioritization compounds: addressing debt in high-impact systems makes the biggest difference to velocity and reliability.
Prioritization also affects morale. If the team sees leadership committing to debt paydown, and that paydown targets the most painful systems, engagement improves. If paydown efforts feel random or ineffective, frustration grows.
1. Identify all significant debt. You can't prioritize what you haven't identified. Conduct an assessment (if you haven't). Document the hot spots.
2. Assess impact on business. For each piece of debt: what's the impact if we don't fix it?
3. Estimate effort. How much work to fix? Days, weeks, months?
4. Calculate impact/effort ratio. "This system: high impact (saves 2 weeks per quarter), moderate effort (2 weeks to fix). ROI: 1:1 payback in 2 weeks, then ongoing savings. Prioritize."
5. Order by ratio. High impact, low effort first. Low impact, high effort last.
6. Consider dependencies. Some debt fixes enable other fixes. "We need to refactor the auth system first; then we can refactor the payment system." Sequence matters.
7. Allocate resources. "This quarter, 20% of engineering capacity goes to debt paydown. These are the targets." Commit to it.
Frequency of change: Systems that change frequently should have low debt. Systems rarely touched can have more debt.
Criticality: Critical systems should have low debt. If the payment system fails, customers are affected. If an internal tool fails, maybe less impact.
Error rates: Systems with high error rates often have high technical debt. Fixing them reduces errors.
Team pain: Ask engineers: "What systems are most painful to work on?" That's a signal for prioritization.
Business impact: Does fixing this debt enable a new feature? Does it reduce costs? Connect debt paydown to business outcomes.
Dependencies: Debt that blocks other work should be prioritized. "We want to build feature X, but the underlying system's architecture is broken. Let's fix that first."
"Fix the most critical systems first." Not necessarily. Critical but stable systems might not benefit from refactoring. Critical AND frequently-changing systems are better targets.
"Engineer preferences." "I like Python, let's refactor the Python system." Preferences shouldn't drive prioritization. Business impact should.
"Sunk cost fallacy." "We invested a lot in this system, let's fix it." Past investment shouldn't drive future decisions. Focus on future impact.
"Assumed quick wins." "This will take 1 week." Refactoring often takes longer than estimated. Be realistic about effort.
"All-or-nothing thinking." "We need to completely refactor this system." Maybe you don't. Often, strategic small fixes (improve tests in this module, decouple this dependency) have high ROI.
You need both:
Feature work: Ships new value to customers.
Debt paydown: Enables future features, improves reliability.
A reasonable balance: 80% feature work, 20% debt paydown. Adjust based on debt burden.
If debt is high, maybe 70/30 or 60/40 while you pay it down. Once debt is manageable, go back to 80/20.
After you execute debt paydown:
Did velocity improve? If you addressed a slow system, shipping should be faster.
Did error rates decrease? If you improved test coverage, reliability should improve.
Did the team's perception improve? Ask: "Is it easier to work on this system now?" Subjective, but important.
Did it enable new features? If the debt fix unblocked other work, measure that.
If debt paydown didn't deliver expected benefits, ask why. Maybe estimates were off, or the debt wasn't actually slowing you down, or new debt accumulated elsewhere.
"Technical debt prioritization is a one-time activity." It's ongoing. As codebase evolves, priorities shift. Systems that were top priority might now be stable. New hot spots emerge. Reassess quarterly.
"Priorities should never change." They should, based on business context. If Q1's priority was the payment system, and it's now stable, move on. If a new priority system emerges, address it.
"We should fix all high-priority debt before moving to medium-priority." Not necessarily. You might do: 1 week on high-priority paydown, 1 week on feature work, 1 week on medium-priority paydown. Mix it.
Q: How do we get leadership buy-in for debt paydown?
A: Frame it in business terms. "This debt is costing us X in maintenance, Y in slower shipping, Z in hiring difficulty. Fixing it has ROI of M." Show the math.
Q: What if every system has high debt?
A: You can't fix everything at once. Pick the top 3-5 by impact/effort ratio. Fix those. Then reassess.
Q: How do we prevent new debt from accumulating?
A: Process changes. "Code review checklist: did we add tests? Is complexity increasing? Is this a good place for a shortcut?" Help teams make conscious choices about debt.
Q: Should debt paydown ever stop?
A: No. Once you've paid down major debt, allocate continuous effort to prevent new debt. Ongoing maintenance is cheaper than crisis refactoring.
Keep reading
Related resources
