Technical Debt Prioritization Framework

Not all debt deserves repayment. Some is cheap to carry, some compounds. The framework gives engineers and product partners a shared method to separate the two and to spend limited capacity where it pays back most.

Avoid the term debt for deliberate, accepted tradeoffs that have an agreed review date. Distinguish prudent debt, taken knowingly to meet a deadline, from reckless debt that came from neglect, because the response differs: schedule the first, and fix the process behind the second.

How it works

Each debt item is expressed as interest and principal. Interest is the ongoing cost: slower changes, extra incidents, manual work, or security exposure. Principal is the effort to fix. Priority is roughly interest times affected scope, divided by principal, adjusted for risk. Items are also tagged by type, such as code, architecture, test, infrastructure, dependency, or documentation, and by whether they sit on a frequently changed path. Hot-path debt in areas that change weekly outranks equivalent debt in dormant code.

Implementation steps

1. Define debt categories and a one-page item template.
2. Collect items from engineers, incident reviews, and code analysis tools.
3. Estimate interest using evidence: hours lost per month, incidents per quarter, blocked features.
4. Estimate principal in engineer-weeks with a range.
5. Calculate scores and rank, then review the top ten with product and operations.
6. Reserve a capacity percentage and schedule top items, bundling with nearby feature work where sensible.
7. Define done criteria and measure whether interest fell afterward.
8. Retire stale items that no longer matter.

Common pitfalls

• Counting aesthetic preferences as debt.
• Scoring without evidence, producing arbitrary rankings.
• Large repayment projects with no incremental milestones.
• Never declaring items accepted, leaving the register to grow forever.

Metrics to watch

Lead time for change in hot areas, change failure rate, recurring incident count by cause, share of capacity spent on repayment, register size and age, and measured reduction in interest after each repayment.

Present these metrics alongside product metrics in quarterly planning. When repayment is shown to reduce incidents or cycle time, product partners treat it as an investment instead of a concession.

Example register entry

id: TD-0187
title: Hand-rolled retry logic duplicated in 14 services
type: architecture
affected: [checkout, billing, notifications]
interest:
  incidents_per_quarter: 3
  engineer_hours_per_month: 18
  security_exposure: low
principal_weeks: 4
change_frequency: weekly
priority_score: 8.1
plan: Replace with shared client library, migrate three services per sprint
done_when: No custom retry loops remain; incident class closed

Key takeaways

• Express debt as interest and principal, with evidence.
• Prioritize debt on frequently changed or high-risk paths.
• Protect a fixed capacity share for repayment.
• Measure whether repayment actually reduced the cost.