Technical debt reduction is a hard sell to non-technical stakeholders. Engineers who can translate technical debt into business impact get the investment; those who cannot do not.
The business impact translation
Technical debt has business costs that are measurable: engineering velocity (how long does it take to build a feature that should take one week?), incident frequency (how often does the system fail due to known issues?), time-to-resolve (how long does the on-call engineer spend investigating incidents caused by complex, poorly understood code?), and hiring impact (do candidates decline offers after viewing the codebase?). Each of these is a business cost that can be quantified with data.
The before/after comparison
The most persuasive refactoring proposal includes a before/after comparison grounded in measurements. Before: the payment module averages 3 incidents per month caused by the race condition in the session management code; each incident takes 2 hours to resolve and affects 0.1% of transactions. After refactoring: zero incidents of this class, reducing engineering time by 6 hours per month and improving transaction reliability. The comparison makes the ROI explicit.
Framing refactoring as risk reduction
For finance and product stakeholders, risk reduction is a compelling frame. Technical debt is a risk: the risk that a poorly understood system fails in production (operational risk), the risk that the codebase is too brittle to implement the next strategic feature (delivery risk), and the risk that key engineers who understand the system leave (key person dependency risk). Refactoring reduces these risks. Organisations that have experienced one of these failure modes are receptive to this framing.
Incremental refactoring as the practical approach
Proposing a three-month refactoring sprint with no feature delivery is rarely approved. The practical alternative: propose that 20% of every sprint is reserved for technical debt reduction, ring-fenced by agreement with product. The investment is visible (it appears in sprint planning), bounded (20% cap), and produces incremental improvement. Combine with the Boy Scout Rule for sustained debt reduction without dedicated sprints.