How I Talk to Non-Technical Stakeholders About Technical Debt
'We need to refactor' loses every prioritization meeting. The conversation that wins is about the feature it's currently slowing down.
Tanjil Ahmed
Lead Software Engineer · Notionhive
Technical debt framed as 'code quality' loses against a customer-facing feature in almost every roadmap conversation, and it should — a stakeholder has no way to weigh 'cleaner code' against 'revenue.' The framing that actually wins isn't about the code at all.
Translate debt into velocity, not aesthetics
'This module has no tests, so every change here takes three times longer and carries real regression risk' is a business statement a product manager can weigh against a deadline. 'This code is messy' is not. I keep a running note of which debt is actually slowing down which roadmap item, in language tied to delivery time, and bring that note to planning instead of a general plea to refactor.
- Quantify: 'the last three tickets in this area took 2x longer than estimated because of X.'
- Tie the fix to an upcoming roadmap item that will be slower or riskier without it.
- Propose the smallest fix that unblocks the next few features, not a full rewrite nobody will approve.
- Track debt paydown as a visible line item, the same way you'd track a feature — it earns credibility over time.
Nobody prioritizes 'cleaner code.' Everybody prioritizes 'this feature ships two weeks faster.' Say the second thing.