Engineering leaders are very good at talking to engineers. Most of us are bad at talking to executives. These are different disciplines, and one of them is not taught.

Here is what works.

Translate first, justify second

The single most common mistake is to start a budget conversation with technical evidence. "Our cyclomatic complexity is trending up." "We have 47 critical code smells." "The reviewers say the code is unmaintainable."

All true. All useless.

The CFO does not have a mental model in which any of those numbers can be evaluated. So the conversation stalls. You feel unheard. They feel annoyed.

The fix: translate into their vocabulary before presenting the evidence.

Not "cyclomatic complexity is trending up." But "we are spending €14,000 more on bug fixes this quarter than last quarter."
Not "we have 47 critical code smells." But "four files in our codebase consume 38% of our debugging time."
Not "the reviewers say the code is unmaintainable." But "onboarding a new engineer onto the payment module takes three times longer than onto any other module."

Same facts. Translated.

The three-slide rule

If you have fifteen minutes on a CFO's calendar, you have three slides worth of attention. Here is how to use them.

Slide 1: the status quo cost

One big number. Euros per month. Something like "our current technical debt is costing us €21,300 per month in firefighting and debt servicing, equivalent to 2.4 full-time engineers."

This number must be defensible. Show your work at the bottom of the slide in small font. Be ready to walk through the assumptions.

Slide 2: the investment required

One other big number. One-time cost. Something like "a focused cleanup investment of €58,000, spread over one quarter, would eliminate roughly 60% of the recurring cost above."

Include the breakdown: how much per hotspot, per silo, per dead file. Not to overwhelm — to prove it's grounded.

Slide 3: the break-even and the projection

Ideally a chart. Current trajectory vs. post-investment trajectory. The point where they cross is your break-even. The area between them after that point is your annual savings.

Include a confidence range. Do not claim precision you don't have.

Three questions a CFO will ask

If you get past the first three slides, you will be asked specific, sharp questions. Prepare for these.

"How do you know the savings are real?"

This is the right question to ask. The honest answer is: you don't, not precisely. You can model, you can forecast, you can benchmark against past refactorings. What you cannot do is guarantee.

What you can do is measure. "Three months after the investment, we'll re-run the analysis and compare. If the firefighting cost hasn't dropped by at least X euros, we've learned something important."

This framing — treating the investment as a measurable experiment rather than an act of faith — is what separates a credible engineering leader from an unconvincing one.

"What happens if we don't invest?"

Do not moralize. Do not say "things will get worse." Give a specific, bounded claim: "Based on the last six months of trend data, firefighting cost is growing at approximately 4% per quarter. At that rate, we would be spending €28,000 per month on firefighting alone by the end of next year."

Then add the strategic point: "The cost of cleanup also scales with debt accumulation. A €58k investment now is likely to be a €120k investment eighteen months from now."

"Why now?"

The best answer is: "Because we finally have the data to justify it. Six months ago, I could not have given you these numbers. Now I can."

If you also have a concrete trigger — a major release cycle, a planned hiring ramp, a migration that will be much harder without cleanup — use it.

What not to do

A non-exhaustive list of moves that backfire:

Emotional appeals. "The team is frustrated." True. Not actionable.
Comparisons to competitors. "Google refactors continuously." Irrelevant. You are not Google.
Open-ended time estimates. "It will take as long as it takes." This is not a budget.
Quality arguments without cost attachment. "Our code is bad." The CFO's mental model: "Is bad code costing us money or not? If yes, tell me how much. If no, move on."

One small habit that helps enormously

Keep a running log, for one quarter, of every bug fix, every delayed feature, every incident, every refactoring detour. Write down the file(s) involved and the hours spent.

At the end of the quarter, multiply by your loaded day rate. You now have a quantified, defensible, specific cost for technical debt — derived from your own data, not from any model.

Bring that to your next budget meeting.