How do you explain technical debt to a non-technical audience?

Question

Accepted Answer

**I translate tech debt into the language the audience already uses: money, speed, and risk.** A non-technical stakeholder doesn't care about coupling or test coverage; they care that features are getting slower and more expensive to ship. So I frame debt as a financial and delivery problem, not a code problem.

## The framing I use

- **The financial metaphor, used carefully.** "We took a shortcut to ship fast, like taking a loan. It worked, and now we're paying interest on it every sprint. Each new feature in this area costs more because of that interest." This lands because everyone understands debt and interest.
- **Make it concrete with their metrics.** Not "the code is messy" but "this feature took three weeks; two years ago the same size took one. The difference is the maintenance overhead we've accumulated."
- **Tie it to outcomes they care about.** Slower delivery, more bugs reaching customers, harder onboarding for new hires, rising risk of an outage. Connect debt to revenue, reputation, and roadmap speed.

## How I make it a decision, not a complaint

- Present it as a **trade-off with options**, not a demand: "We can keep shipping features at the current slowing pace, or invest two sprints now to cut future feature cost by roughly a third."
- Quantify where I can: time lost per sprint, incident frequency, the percent of capacity spent firefighting.
- Be honest that **some debt is fine.** Not all debt should be paid; the point is to pay down the debt that is actively taxing delivery.

## Pitfalls

- **Using jargon** ("refactor," "coupling," "the architecture is wrong"). It makes you sound like you want to gold-plate the code.
- Framing it as engineers wanting clean code for its own sake; that reads as self-indulgent.
- Crying wolf — calling everything debt erodes credibility when something truly urgent comes up.

## Why it matters

If you can't explain tech debt in business terms, it never gets funded, and the team slowly grinds to a halt while leadership wonders why velocity is dropping. Framing it as cost, speed, and risk is what gets you the time to fix it before it becomes a crisis.