How to actually prioritize tech debt
Every engineering team has a list of things that should have been fixed last quarter. The list grows faster than the team can ship against it. By the time it gets brought up in a planning meeting, half the room thinks "we just need to do all of it" and the other half thinks "we never have time." Both are wrong.
The frame this tool uses — impact × effort — is the simplest one that actually works in practice. It isn't perfect (we'll get to the limits below), but it forces a productive conversation: instead of arguing about which items matter, you debate the scores. And once items are scored, the ranking and the quadrant fall out automatically.
What "impact" actually means
Impact is the value of fixing the debt. That value can be:
- Reliability: how often is this on the incident timeline?
- Velocity: how much time does this cost the team every sprint?
- Security or compliance: what is the risk of leaving it?
- Cost: what's the cloud/SaaS bill or the customer churn driven by this?
- Strategic enablement: what becomes possible once it's fixed?
A useful 1–10 rubric: 1 = nice-to-have, 4 = blocks one team weekly, 7 = recurring incident contributor, 10 = active security or availability risk. Score in isolation. Relative-ranking as you go biases everything toward the median.
What "effort" actually means
Effort is the total cost to fix — engineer-time, complexity, organizational blast radius, risk of regression. A useful 1–10 rubric: 1 = afternoon, 4 = sprint, 7 = quarter, 10 = multi-team multi-quarter. Be honest about complexity. The most expensive debt is usually the one labeled "should be easy."
How to read the quadrants
- Quick Wins (high impact, low effort): Do these immediately. They're the highest-leverage work on the list. Most engineering orgs underinvest here because they assume small things must matter less.
- Big Bets (high impact, high effort): Plan deliberately. These need an explicit allocation, an owner, and protection from feature work. One or two per quarter is realistic for most teams.
- Fill-ins (low impact, low effort): Do when there's a gap. Don't schedule a sprint around them.
- Avoid (high effort, low impact): Say no. Or descope until the cost looks different.
Where the simple frame breaks down
The matrix isn't perfect, and the two failure modes to watch for:
- Compounding debt. Some debt accumulates interest. The cost in six months is materially worse than the cost now. Score impact based on a 6–12 month horizon to capture this, or it'll always lose to fresh work.
- Strategic enabler debt. Some debt blocks a category of future work that hasn't been planned yet. The impact looks low if you score it against current pain; it's actually high if you score it against the opportunity it unlocks. Tag these and treat them separately.
Use this tool as a starting frame for the conversation, not a substitute for it. The matrix exists to make the discussion faster and less political — not to remove your judgment from the loop.
More tools for engineering teams
Browse the full JobsByCulture developer tools — code review checklist generator, conventional commit builder, release notes generator, and more. Or if you're hiring engineering managers and tech leads who'll be running this kind of prioritization, browse engineering jobs with culture context.