Technical Debt Triage: A Framework for Prioritising What to Fix First

A technical debt triage framework prioritises what to fix first by scoring each item on two axes — how much risk it carries if it fails, and how often the code it touches actually changes — rather than fixing whatever is oldest, ugliest, or loudest in the last retrospective. Debt that is rarely touched and low-risk can wait indefinitely; debt in your highest-change, highest-risk path cannot.

"Pay Down the Debt" Is Not a Priority, It Is a Slogan

Every engineering team has a backlog of technical debt, and almost every one of them prioritises it the same unreliable way — whatever is loudest in the last retrospective, whatever the most senior engineer personally finds most annoying, or whatever is oldest and therefore assumed to be worst. None of these are proxies for actual business risk, and treating them as prioritisation criteria is why technical debt backlogs grow for years without ever meaningfully shrinking, even when teams genuinely spend time on them every sprint.

A usable triage framework needs to answer a specific question for every item: if we do not fix this in the next quarter, what is the realistic cost of that, and how does it compare to fixing something else instead? Answering that question consistently requires a shared scoring method, not individual engineering judgement applied ad hoc to whichever item is in front of someone that week.

The Two Axes That Actually Matter

Score every debt item on two independent axes: blast radius, meaning how severe the consequence is if this fails or is misunderstood, ranging from a minor visual bug to a data integrity or security incident, and change frequency, meaning how often the code around this debt item is actually touched by new feature work. Debt in a stable, rarely-modified corner of the system, however ugly, can safely wait, because nobody is working near it and it is not actively creating new risk. Debt in a high-change area of the codebase compounds every time a new feature has to work around it, and it is where new bugs are most likely to originate, because engineers are constantly modifying code they do not fully trust.

The combination of these two axes, not either alone, is what determines priority. High blast radius, low change frequency items are worth scheduling but rarely urgent. Low blast radius, high change frequency items are often worth fixing quickly precisely because they slow down every future change, even if a single incident from them would be minor. High blast radius, high change frequency items are the ones that should top every triage list, and are usually smaller in number than teams expect once scored honestly.

Building the Triage Matrix in Practice

Plot every open debt item on a simple two-by-two grid — blast radius on one axis, change frequency on the other — and score both from data where it exists rather than gut feel: incident history and the severity of past failures for blast radius, git commit frequency and the number of pull requests touching that area in the last quarter for change frequency. This turns a subjective argument about which debt is worse into a shared, revisable scoring exercise the whole team can see and challenge, and it produces a ranked list rather than a flat backlog nobody can order.

Keeping a Living Debt Register

• Log every known debt item with its blast radius score, change frequency score, and a one-line description of the actual risk, not just the technical complaint
• Re-score the register quarterly — change frequency shifts as the roadmap shifts, and yesterday's low-priority item can become urgent once a team starts building near it
• Attach an estimated fix cost to each item so the triage conversation weighs cost against risk, not risk alone
• Assign an owner to each item in the top-priority quadrant, with a target quarter, not an open-ended someday
• Track debt items closed each quarter as a visible metric, the same way feature delivery is tracked

Making the Business Case to Leadership

Technical debt conversations with non-engineering leadership fail when they are framed as "the code is messy" — that framing has no business translation and predictably loses budget to feature work every time. Framed instead as a specific item sitting in the highest-risk, highest-change part of the system, with the incident and velocity cost of leaving it left in place, using the same scoring data from the triage matrix, technical debt becomes a comparable investment decision rather than an engineering preference competing against revenue features on faith alone.

Triage does not mean fixing everything, and it is not meant to. It means being able to say, with evidence, which handful of debt items are actually costing the business money or risk right now, and defending a fix schedule for those specifically — while being honest that the rest can, and should, wait.