Technical Debt Quadrants
Distinguishing debt by whether it was taken deliberately or inadvertently, and prudently or recklessly, since the four kinds need different responses.
Treating all technical debt as one thing is why conversations about it go nowhere. The distinction that makes it actionable is two-dimensional.
Deliberate and prudent: "we know this is not the right design, we are shipping to hit the market window and will address it in Q3." This is a legitimate engineering trade, and it is only debt in the financial sense if the repayment is actually planned.
Deliberate and reckless: "we do not have time for design." A choice made knowingly without weighing the cost.
Inadvertent and prudent: "now that it is built, we can see what the right design would have been." This is not a mistake, it is learning, and it is unavoidable — the most common and least blameworthy form.
Inadvertent and reckless: the team did not know what good looked like. This is a capability problem, and refactoring alone will not fix it.
The practical value is in the response. Deliberate prudent debt needs a tracked repayment plan. Inadvertent prudent debt needs continuous refactoring as understanding improves. Reckless debt needs attention to how decisions are being made, or to skills.
The framing that gets it funded, since "technical debt" is a term that has lost force with non-technical audiences: express it as the interest being paid — how much slower each change is, how much of the incident load it causes, what it costs per quarter — rather than as a moral argument about code quality.