Technical Debt Triage: Choosing What to Pay Down First

Every team I have joined had a document full of things they knew were wrong. Every one of those documents was a list, not a plan, and the list had been sorted by whoever complained last.

The list is not the problem. The problem is that debt is a metaphor that stopped helping around the third year. Financial debt has interest rates you can look up; technical debt has a story somebody tells in a planning meeting, and the story is always about the person who wrote the code rather than the code itself.

So the first move is to stop asking "how much debt do we have" and start asking "which single change would make the next three changes cheaper."

Score it on three axes

For anything on the list, get rough answers to:

How often does it hurt? Not how often it is mentioned — how often someone loses an hour to it. A thing that costs fifteen minutes weekly is worse than a thing that cost four hours once in 2024.
How much does it block? Some debts sit in a corner and never matter. Others sit on the only path every feature must cross. The second kind is the one that compounds.
What does it cost to remove? A day, a month, or "we'd have to rewrite the service." This is the axis everyone skips because it requires actually knowing the code.

You will not get numbers. You want ordering: high, medium, low, with the honest answer being "I don't know" at least twice. "I don't know" is a finding — it means nobody has read that code path in a year, which is itself information about whether it matters.

The four questions I ask before funding it

Once something scores badly on two of the three, I ask:

Does this touch the mainline of delivery? If every release goes through it, it is worth more than its size suggests.
Will it get worse if we leave it? Decaying interfaces do; a slightly awkward helper function does not.
Is it debt, or is it a decision we have not revisited? Half of what gets called debt is a constraint that was correct in 2021. Those need a conversation, not a rewrite.
Can I make it smaller? The full fix is often a month. The ten-line change that removes the weekly pain is often a morning. Take the morning.

That last one matters more than it sounds. The reason debt lists never shrink is that every item is priced at its full replacement cost, so nothing is ever affordable.

What I refuse to fund

Rewrites proposed as a single line item. "Rewrite the billing service" has no intermediate state, no value before the last day, and no way to learn anything until it is nearly done. Every rewrite I have watched closely revealed requirements nobody had written down, six weeks in.

What I fund instead is the seam: pull the tangled part behind an interface, move one caller at a time, and let the platform layer absorb the pattern so the next service does not start the same way.

I also refuse "cleanup" with no observable outcome. If we cannot say what will be faster, safer, or easier to change afterwards, it is not triage — it is tidying, and tidying can happen in a hack day.

Make it visible or it stays forever

Debt that only exists in a retrospective disappears by the following Thursday. Two habits keep it real:

Put the cost in the ticket. "Costs ~2 engineer-hours/week, has done so since March" survives prioritisation; "code is messy" does not.
Re-score quarterly, not continuously. A quarterly pass takes an hour and stops the list becoming a second backlog nobody maintains. Continuous attention turns it into noise.

This is also where on-call pressure gives you an honest signal: the items that keep generating pages are the ones with a measurable interest rate, and no scoring framework will tell you more than that.

Summary

Debt is only worth paying down when it is making the next change cost more. Score each item on frequency, blockage, and removal cost; fund the small versions rather than the full rewrites; refuse anything without an observable outcome; and re-score on a schedule so the list reflects reality instead of whoever complained loudest last quarter. Three items a quarter will beat a list of forty you never start.