Need Help Making the Case for a Cleanup?
Every engineering team eventually needs budget or roadmap time to pay down technical debt, and every engineering team eventually struggles to explain why to the people who control the budget. “The code is messy” does not compete well against a new feature a sales team is asking for. The teams that get technical debt taken seriously translate it into the language stakeholders already use: risk, cost, and speed.
Stop calling it “technical debt” in the room
The term means something precise to engineers and close to nothing to a CFO or a head of sales. What lands better is naming the actual consequence: “every new feature in this module now takes twice as long to ship safely” or “we cannot onboard a new engineer to this part of the system in under a month.” Debt is an accounting metaphor — use the rest of the metaphor. It has an interest rate, and stakeholders understand interest rates.
Translate risk into business terms
“This system has no automated tests” is an engineering fact. “If we ship a change here without extensive manual QA, there’s a real chance of a customer-facing outage during our busiest period” is a business risk. The second version is what earns attention, because it maps to something the business already knows how to weigh: the cost of an outage versus the cost of the cleanup work.
Show the cost as a rate, not a lump sum
Framing a cleanup as “we need six weeks to fix this” invites the question “can we skip it?” Framing it as “this is currently costing us roughly 30% of every feature estimate in this area, and that percentage is climbing” reframes the conversation from a one-time cost to a recurring tax the business is already paying, whether or not the work gets scheduled. That reframe usually does more to secure the time than any amount of technical detail.
Bundle it with visible value, don’t ask for it alone
A pure “refactoring sprint” with no visible output is a hard sell, and often a fair one — stakeholders are right to be wary of open-ended cleanup work. Debt paydown lands better attached to work stakeholders already want: “we can ship the integration you’re asking for in two months if we spend three weeks first, or in five months if we don’t.” That framing turns the debt conversation into a scheduling trade-off instead of a competing priority.
None of this requires stakeholders to understand the code. It requires engineers to do the translation work once, clearly, in terms of risk and rate rather than architecture — the same discipline that applies to any maintenance conversation: the business doesn’t need to see the mechanism to understand the cost of ignoring it.