The word "debt" gets used as an insult, as if any shortcut were a mistake. That framing is wrong and it makes the conversation harder. Debt taken deliberately, to hit a deadline that genuinely matters, with a plan to pay it back, is a sound engineering decision. Debt that accumulates because nobody noticed is the real problem.
Deliberate versus accidental
We separate the two because they need different responses. Deliberate debt - "we will hardcode this list now and make it configurable after launch" - is a choice with a known cost. Accidental debt - a design that no longer fits because the product changed under it - is something you discover later. You manage the first with discipline and the second with attention.
- Deliberate: a conscious shortcut with a written reason and a payback plan
- Accidental: drift you only see in hindsight, usually from changed requirements
- Bit rot: dependencies and patterns that aged out while the code stood still
- Name which kind you have - the fix for each is different
Write the interest rate down
A debt ticket that just says "refactor the order service" never gets prioritized, because nobody can weigh it against a feature. We write down the cost of carrying it: this shortcut adds a day to every change in this area, or it causes one incident a month, or it blocks a feature the sales team keeps asking for. Now the product owner can make a real decision instead of treating "clean it up" as a vague good.
Tech debt without a stated cost is not a backlog item, it is a complaint nobody can act on.
Pay it down where you already are
Big refactoring projects that touch everything are hard to justify and risky to ship. We get more done by improving code in the area we are already changing for a feature. We are in that file, we understand it today, the test coverage is fresh in our heads. A little cleanup with each change compounds, and it never requires asking permission for a two-week "refactor sprint" that the business has every reason to distrust.