Making a technical debt case your CFO will fund

Refactoring appeals to engineers and repays nothing on its own. The work is real and the benefit is deferred, which is the worst possible combination for a funding decision.

The fix is not better explanation. It is changing what you are proposing — from a cleanup to a reduction in a specific business risk.

Lead with the risk, not the code

Compare two framings:

The order module has 4,000 lines of untested legacy code and significant duplication.

Changing the order pipeline currently takes an average of nine days and carries a one-in-five chance of a regression reaching customers.

The second gets funded. It is expressed in the terms the decision is actually made in, and it can be checked later.

The first is a true statement that nobody can act on. "Significant duplication" is not a cost. A nine-day lead time is.

Name the mechanism

Not every piece of debt produces a risk. Be specific about the pathway:

• change lead time on the journeys we are actively investing in
• the cost of each incident in engineering hours
• the manual effort absorbing capacity that could be product work
• a specific compliance finding that traces back to a system characteristic

If you cannot name the mechanism, you may have a preference rather than a case. That is worth discovering before the meeting.

Cost the incidents you can evidence

For a system under active change, the strongest available number is usually historical:

• how many incidents in the last two years originated in this component
• the mean time to resolve, and the engineering hours consumed
• how often changes had to be rolled back

These are in your own incident records. Assembling them is a day's work and it moves the conversation from assertion to evidence.

Be careful not to overstate. If one incident was caused by a configuration change that has not happened since, say so.

Frame the option set, not the request

Present three options with costs, not one proposal with a justification. The request becomes a choice between alternatives, which is a decision rather than a favour.

• Do nothing. State what happens: lead time stays at nine days, the next feature in this area takes a quarter, the two engineers who understand it remain the constraint.
• Targeted work. Name the specific change, its cost, and which risks it removes. Usually the highest-value option and rarely the whole codebase.
• Full remediation. State it, cost it honestly, and say why you do not recommend it now.

Teams that present a single large number get asked for justification. Teams that present options get a decision.

Make progress visible or the request recurs

Debt work is invisible while it is succeeding. The business sees no feature, no incident, and no change in any dashboard.

Instrument the thing you claimed to improve. If the case is change lead time, publish it. If it is incident rate in a component, track it. Review it at the same governance meeting, on a schedule, with the baseline visible.

Without that, the work completes, the benefit is never demonstrated, and the next request starts from zero.

Know what you are actually proposing

One caution. "Technical debt" as a category often absorbs work that is really one of:

• a feature nobody has prioritised
• a migration postponed three times
• a component that is genuinely fine and disliked by the team

Each needs a different argument. A migration is a schedule question. A feature is a product question. Only genuine debt is a risk-reduction question, and it is a smaller category than people assume.

Being clear about which is which makes the proposal harder to sell and far more likely to be funded when it eventually succeeds.