How do you manage technical debt at the organizational level?

Question

Accepted Answer

At the org level, technical debt is a **portfolio to be managed**, not a backlog to be eliminated. The goal is not zero debt; it is keeping debt at a level where it does not threaten velocity, reliability, or the ability to deliver strategy.

## How to think about it

```text
MAKE DEBT VISIBLE AND PRIORITIZED
- Inventory the debt that actually hurts (slows delivery, causes incidents)
- Classify: strategic (deliberate) vs accidental vs decay/rot
- Quantify impact in business terms (velocity, downtime, churn risk)
- Allocate a steady % of capacity to paydown (commonly 15-25%)
```

Not all debt is worth paying. Debt in a stable, rarely-changed system can be left alone; debt in a hot, fast-changing area should be paid first.

## Concrete example

A CTO institutes a rule that 20% of every team's capacity goes to reliability and debt, then targets it at the three systems causing 80% of incidents, rather than spreading it thinly everywhere.

## Trade-offs and pitfalls

- **Pitfall:** a "big rewrite" to clear all debt, which usually overruns and re-creates debt.
- **Pitfall:** never paying it down, until velocity collapses.
- Framing debt as an engineering-only concern fails; tie it to business outcomes to get buy-in.

## Why it matters

Unmanaged technical debt compounds silently until features take months and incidents spike.

Managing it as a deliberate portfolio keeps the organization fast and reliable over years, and turns an abstract engineering worry into a quantified business trade-off leadership can reason about.