Tech Debt — Classification and Communication
Not all tech debt is equal — classify before deciding to pay it down, and communicate it in business impact terms.
When to use
- Before proposing a debt paydown initiative
- When leadership asks "how bad is the debt?"
- During architecture reviews
Tradeoffs
- Calling something "debt" implies a plan to pay — don't use the term if there's no intent to fix
- Paying down debt has opportunity cost against new features; must be justified by measurable slowdown
Tech Debt Registry
| Item | Quadrant | Business Impact | Owner | Priority |
|---|---|---|---|---|
| auth-service coupling | Deliberate/Prudent | Slows every auth change; 3x longer deploy cycle | @alice | High |
| inline SQL strings | Inadvertent/Reckless | SQL injection risk; no testability | @bob | Critical |
| monolithic config file | Deliberate/Prudent | Accepted at launch; makes multi-env hard | @team | Medium |
Gotcha: The cost of tech debt is the slowdown it causes to every future change — not the debt itself. Measure it in deployment frequency and cycle time, then sell the paydown using those numbers.