"Technical debt" loses every budget fight because it shows up as a metaphor competing against features that show up as numbers. This guide translates debt into the language finance already uses balance, carrying cost, payoff schedule, write-offs so paying it down becomes a decision the business can make, not an argument engineering keeps losing.
Why it keeps getting deferred: "we have a lot of technical debt" is unfalsifiable to a CFO no balance, no carrying cost, no consequence in money so it loses to features with revenue attached, every quarter, while it compounds.
What changes when you measure it: give the debt a balance, a monthly carrying cost, a payoff schedule, and a write-off list, and it becomes a managed liability the business can fund on purpose exactly like any other line on the balance sheet.
Estimate the effort to bring the system to a healthy state the backlog of shortcuts, unsupported dependencies, missing tests, and brittle areas priced in engineering time or money. Rough but explicit beats precise but never finished.
The interest, and the most persuasive number: the extra time every change takes, the incidents the debt causes, the velocity it drains. Translate lost engineering time into money and a CFO understands it instantly.
A schedule that pays down the highest-interest debt first, in increments the business can absorb and an explicit list of debt you'll never repay because the underlying system is being retired.
Pay down the debt that costs the most per month, not the code that offends engineers most. Some ugly code is cheap to carry; some innocuous debt is quietly expensive.
Frame it like capex: this much engineering time recovers this much delivery capacity. That's a proposal a CFO can weigh, not a vague plea for "cleanup time."
Allocate a standing share of capacity each cycle to keep the carrying cost from compounding predictable and sustainable, instead of lurching between neglect and "stop everything."
Take debt in soon-to-be-retired systems off the active schedule. That's discipline, and it keeps the payoff focused on debt that actually costs you.
You never eliminate technical debt, and you shouldn't. The organizations that manage it well keep the carrying cost from compounding, pay down the expensive parts on a schedule, and make the trade-offs with their eyes open. The difference is measurement and a balance sheet the business reviews every quarter.
Yes - deliberately taken debt that buys speed can be a smart trade, like financial leverage. The problem is unmeasured debt that compounds unnoticed. The goal isn't zero debt; it's a known balance with a carrying cost you've chosen to accept.
The carrying cost the monthly interest. Translating lost engineering time (Stripe found ~42% goes to maintenance and bad code) into money makes the debt's ongoing drag concrete and fundable.
CTOs and VPs of Engineering who need to fund debt paydown, and the CFOs who decide whether that funding is justified.
Start rough. List the high-pain areas, unsupported dependencies, and missing tests, and price them in engineering time. A directional estimate you act on beats a precise one you never finish.
Almost never - a "stop everything" rewrite is the risk profile that fails most. Fund a standing debt budget and pay down the highest-carrying-cost items on a schedule instead.
