How to talk about technical debt at a steering committee
Technical debt is the topic nobody wants to bring to a steering committee. PMs avoid it because it's hard to quantify. Engineers avoid it because they know they'll be told to prioritize features instead. Executives avoid it because they don't really understand it.
Result: it never gets addressed seriously, until the day it slows everything down.
The usual framing problem
Most teams present technical debt as a technical problem. "Our code is old." "The architecture is fragile." "We need refactoring."
These arguments don't work in exec meetings. Not because decision-makers are obtuse — but because this framing gives them no decision-relevant information.
The right framing: product impact
Technical debt becomes a boardroom topic when it's translated into measurable product impact.
Before
"We need two sprints to refactor the payment module."
After
"Every new feature on checkout currently takes 3x longer than it should, due to tight coupling between the payment module and the catalog. If we don't fix this before Q3, the offer personalization project will take 6 weeks instead of 2."
The difference? The second argument is expressed as future opportunity cost, not past technical work.
The impact/urgency matrix
For strategic meetings, I use a simple matrix:
| Type of debt | Impact on velocity | Risk if unaddressed | Priority |
|---|---|---|---|
| Payment module coupling | High (-40% on checkout) | Blocks Q3 | P1 |
| Insufficient unit tests | Medium | Frequent regressions | P2 |
| Missing logging | Low | Slow debugging | P3 |
This framing turns an opaque topic into a normal prioritization decision.
What NOT to do
- Don't lump everything together. "We have debt everywhere" leads nowhere. Pick 2-3 critical points.
- Don't use technical jargon. Coupling, refactoring, legacy — these words don't resonate.
- Don't ask for a generic dedicated sprint. Ask for a precise outcome: "reduce average delivery time on checkout from 3 weeks to 1 week by end of Q2."
The right moment to raise it
The best time to address technical debt in a steering committee is before a major initiative, not during. Embed it in roadmap planning: "to deliver X, we first need to address Y."
If you have questions on structuring this type of presentation, feel free to reach out.