Managing Tech Debt

Tech debt is inevitable—it's the natural result of shipping under constraints. The question isn't whether you have it, but whether you manage it. This guide covers what tech debt actually is, how to quantify and track it, how to advocate for paydown, and how to prevent it from overwhelming your team.

What Tech Debt Actually Is (and Isn't)

Ward Cunningham's Original Metaphor

Ward Cunningham first described the debt metaphor in his 1992 OOPSLA experience report. Tech debt is borrowed time. You take a shortcut to ship faster; you pay interest (extra effort) on future changes until you pay down the principal (refactor). Like financial debt, some is strategic and some is reckless. The metaphor helps non-engineers understand trade-offs. Martin Fowler later expanded on this with his Technical Debt Quadrant, distinguishing between deliberate vs. inadvertent and reckless vs. prudent debt.

Tech Debt vs. Bad Code

Not all bad code is tech debt. Tech debt implies a deliberate decision—"we're taking a shortcut because X." Accidental messiness, lack of knowledge, or copy-paste without intent isn't debt; it's just poor quality. Debt has a rationale; sloppiness doesn't.

When Debt Is Acceptable

Early-stage startups often take on debt to validate the product. Speed matters more than perfection. The key: acknowledge it, track it, and plan to pay it down before it compounds. Denying debt or pretending it doesn't exist is when it becomes toxic.

Types of Tech Debt (Deliberate, Accidental, Bit Rot)

Deliberate Debt

You consciously chose a shortcut: "We'll use a quick hack for now and refactor in Q2." Document it. Create a ticket. Schedule the paydown. Deliberate debt with a plan is manageable.

Accidental Debt