Technical debt prioritization

What it means

Technical debt prioritization selects which debt to address and when. Teams can consider customer risk, defect exposure, developer friction, change frequency, security, operational cost, and repayment effort. A transparent rationale is more useful than a universal scoring formula because different systems have different consequences.

Example

A team chooses to fix a fragile deployment script before a low-traffic refactor because release failures are delaying customer fixes. The decision records expected benefit and a review date.

Limitations

Scores can create false precision and favor easily measured items. Debt with low current activity may still be strategically important, while urgent feature work can change the ranking. Revisit priorities as evidence changes.

How to use the signal

A useful decision also states what will be deferred and what evidence would cause the ranking to change.

Make the rationale visible and revisit it when change frequency, exposure, or product priorities shift.

Weave can provide evidence about review queues, rework, and delivery impact around candidate debt. Use it as input to prioritization, not as an automatic debt score.