How to Explain Technical Debt to a Non-Technical Manager in English
Learn the English phrases for explaining technical debt to a non-technical manager in terms of business risk and cost, not code quality.
Technical debt is easy to explain to another engineer and surprisingly hard to explain to a manager without an engineering background, mainly because the natural vocabulary — “messy code,” “quick hacks” — sounds like a complaint rather than a business risk.
Framing Debt as a Trade-off, Not a Mistake
Explain that the shortcut was a deliberate, reasonable choice at the time.
- “When we built this feature, we made a deliberate trade-off to ship faster by skipping a more robust solution — that trade-off is starting to cost us now.”
- “This wasn’t a mistake — it was the right call given the deadline at the time. The situation has changed, though, and it’s worth revisiting.”
- “Think of it like a loan: we borrowed time back then, and now we’re paying interest on it in the form of slower development.”
Translating Risk Into Business Terms
Connect the technical issue to something the manager already cares about.
- “Every new feature in this area now takes about 30% longer to build, because we have to work around this old limitation.”
- “This isn’t just a code quality issue — it’s a real risk to our ability to hit next quarter’s roadmap if we don’t address it.”
- “The current setup makes it harder to onboard new engineers quickly, since this part of the system doesn’t follow the patterns used elsewhere.”
Quantifying the Cost
Where possible, use concrete numbers rather than vague warnings.
- “Based on the last three features we built in this area, this issue has added roughly two extra days of work to each one.”
- “We’ve had two production incidents traced back to this exact area in the last quarter — that’s a cost we can start putting a number on.”
- “Paying this down now is roughly a two-week investment; leaving it as-is likely costs us more than that in slower delivery over the next two quarters.”
Proposing a Concrete Plan
Managers respond better to a plan with a scope than an open-ended request.
- “I’d like to propose a focused two-week effort to address this, rather than an open-ended cleanup — here’s specifically what it would include.”
- “We don’t need to fix everything at once — I’d suggest tackling the highest-risk part first and re-evaluating from there.”
- “This can be scheduled alongside the next feature that touches this area, so we’re not asking for dedicated time separately.”
Responding If the Answer Is “Not Now”
Handle a deferral professionally while keeping the risk visible.
- “Understood — I’ll document this as a known risk so it’s visible when we’re planning future work in this area.”
- “That’s fair given the current priorities. Can we revisit this in the next planning cycle rather than let it disappear entirely?”
- “I’ll keep tracking the cost this adds to future work, so we have real data if we want to revisit the decision later.”
Vocabulary Reference
| Term | Meaning |
|---|---|
| Technical debt | The implied future cost of choosing a faster, less robust solution now |
| Trade-off | A deliberate decision to accept one cost in exchange for a benefit elsewhere |
| Roadmap | A high-level plan of upcoming work and priorities, often over a quarter or more |
| Scope | The defined boundaries of what a piece of work will and won’t include |
| Known risk | A documented, acknowledged risk that hasn’t yet been addressed |
Key Takeaways
- Frame technical debt as a past trade-off, not a mistake, to avoid sounding like a complaint about prior decisions.
- Translate the technical risk into terms a manager already tracks: delivery speed, onboarding time, incident count.
- Quantify the cost with real numbers wherever possible, rather than vague warnings about “messy code.”
- Propose a scoped, concrete plan rather than an open-ended request for cleanup time.
- If deferred, document the risk formally so it stays visible for future prioritization.