A Way to Prioritize Pipeline Technical Debt That Isn't a Guess

An engineer's daily irritation with a piece of code isn't the same thing as its risk to the business. For each debt item, ask what breaks and who's affected if it fails under load: one internal dashboard, or the billing pipeline for every customer. Score blast radius separately from how annoying the code is to work in, because the two often don't correlate, and a scoring system that conflates them tends to fix the most annoying thing rather than the most dangerous one.

A fragile piece of code that only runs during a rare edge case is a different priority than one that runs on every message. Pull real frequency data where you can, such as how often a particular retry path actually triggers, rather than estimating from memory. Debt that fires constantly but causes small annoyance and debt that fires rarely but causes major damage need different remediation urgency, and a single combined score, blast radius times frequency, usually separates them better than either factor alone.

Teams often set a rule like 'twenty percent of sprint capacity goes to debt,' which sounds disciplined but ignores how much cadence has already degraded. DORA's research puts deployment frequency into four clusters, from teams shipping multiple times a day at the fastest end down to teams going as long as 180 days between releases at the slowest¹. If your own release cadence has been sliding toward that slower end, that's itself a symptom of accumulated debt, and it's a signal to increase remediation time temporarily rather than hold a fixed percentage that no longer matches reality.

A team that used to ship weekly and now ships monthly doesn't usually notice the slide happening in real time, since each individual release still feels normal. Tracking deployment frequency as a trend line, not just a current snapshot, is what surfaces that kind of drift early enough to act on it.

Not every high-scoring item needs to be fixed immediately. Some debt is safe to leave alone until you touch that part of the system again for an unrelated reason, at which point fixing it becomes nearly free compared to a standalone project. Tag items this way explicitly: urgent and needs its own ticket now, versus fix opportunistically the next time this file is touched. This keeps the urgent list short enough that it actually gets worked, instead of drowning in items that could reasonably wait.

Write the reason for each tag down alongside the item, not just the tag itself. A future engineer deciding whether an 'opportunistic' item is still safe to defer needs to know what assumption that deferral was based on, since the system it was deferred against may have changed.

A debt item's score isn't permanent. A consumer that was low blast radius because it fed one internal report can become high blast radius the day a customer-facing feature starts depending on that same report. Rescore debt items when you notice a dependency has changed, not just on a fixed calendar, since the score reflects the current system, not the one it was written against.

An AI CTO like Taj can flag when a low-scored item's dependency graph changes in a way that would raise its blast radius, which is easy for a busy team to miss without someone or something watching for it continuously.

A scoring system that only engineers see tends to lose every planning conversation to a feature with a clearer business case, even when a high-scoring debt item carries more actual risk. Bring the top few scored items into the same planning conversation as feature work, with the blast radius and frequency reasoning stated plainly, so the tradeoff is made deliberately rather than by default. A debt item that keeps losing that conversation despite a high score is worth escalating explicitly rather than letting it quietly reset to the bottom of the list.

A short scoring routine looks like this:

1. List each debt item and note what breaks, and who is affected, if it fails under load.
2. Score blast radius separately from how annoying the code is to work in, since the two rarely correlate.
3. Add how often the failure mode actually fires, using real data such as retry path counts wherever you can.
4. Tag each item as fix now with its own ticket, or fix the next time that part of the system is touched.
5. Bring the top scored items into the same planning conversation as feature work, and rescore when a dependency changes.