Why vague framing loses every time
A feature request comes with a named customer, a revenue or retention estimate, and a delivery date. 'The code is messy' comes with none of that, so it loses by default to any proposal with actual numbers attached — not because quality doesn't matter, but because the debt case was never actually built as a business case.
The fix is not better rhetoric. It's doing the same quantification work for debt that product teams already do for features, as a matter of course.
Quantify the specific, not the general
Instead of 'the codebase needs refactoring,' name the specific debt item, its measurable cost (incident frequency in this module, average time-to-ship for changes touching it, on-call burden it generates), and what resolving it would be expected to change about those numbers.
This converts an abstract quality complaint into a bounded investment proposal with an expected return — exactly the structure a board is already equipped to evaluate.
Maintain a visible, prioritised debt register
A standing, visible register of quantified debt items — each with its cost estimate and proposed fix — lets leadership see technical debt as an ongoing, manageable portfolio decision rather than a surprise ask that appears only when something breaks.
Teams that maintain this register consistently find debt work gets funded more often, not because the board became more sympathetic, but because the asks finally look like every other investment decision the board already knows how to evaluate.
'Messy code' is not a budget line. 'This module causes forty percent of our incidents' is.MNB Software Practice
Key actions
- Name the specific debt item, not the codebase in general
- Quantify its measurable cost: incidents, lead time, on-call burden
- State the expected return of resolving it
- Maintain a standing, visible, prioritised debt register