A field guide to the technical debt that is actually worth paying down

Every engineering org I have ever worked in has a technical debt backlog that is, functionally, a graveyard. Things get added, almost nothing gets removed, and every planning cycle someone points at the backlog's growing size as evidence of dysfunction. The backlog isn't the problem. The problem is that "technical debt" gets used as a label for two completely different categories of risk that deserve completely different urgency, and conflating them is what makes the backlog useless.

The framework I've settled on after years of getting this wrong: sort every debt item into either "compounding" or "static." Compounding debt gets more expensive to fix the longer you wait -- a data model that's slightly wrong today will require migrating more and more data as your system grows, so the fix cost is a function of time, not just complexity. Static debt is expensive today, but the cost doesn't meaningfully increase by waiting -- an ugly-but-isolated piece of code that nobody else touches doesn't get more dangerous just because six more months pass.

Compounding debt deserves real urgency, even when it feels boring, because the fix-cost curve genuinely gets worse. Static debt can, correctly, sit in a backlog indefinitely, and treating it with the same urgency as compounding debt is what makes engineers stop trusting the backlog at all -- if everything is labeled equally urgent, nothing actually is.

The second axis I use, orthogonal to the first: does this debt item constrain a decision the business actually wants to make soon? A slightly-wrong data model that would need to change anyway for a roadmap item three months out deserves urgency regardless of whether it's compounding, because the cost of not fixing it now includes blocking or complicating real, planned work.

Putting these together gives a much more honest prioritization than "how bad does this feel": compounding-plus-blocking gets fixed now, compounding-plus-not-blocking gets scheduled deliberately (not just added to a pile), static-plus-blocking gets fixed as part of the blocking work anyway, and static-plus-not-blocking genuinely can wait, and saying so explicitly is not a failure of engineering discipline -- it's the correct call.