CFOs do not fund "tech debt." I've watched that phrase kill budget conversations in boardrooms from Frankfurt to Amsterdam. The moment a CTO says "we need to address technical debt," a CFO's internal translation layer renders it as: "the engineering team wants money to clean up a mess they made, with no clear return, and no way for me to know if it worked."
They're not wrong to be sceptical. "Tech debt" as most CTOs present it is a category, not a number. Categories don't get funded. Numbers do.
Here is how I convert tech debt into the financial language that gets a CFO to say yes.
Why "Tech Debt" Fails as a Budget Argument
The phrase is borrowed from Ward Cunningham's original metaphor, which was precise and useful: taking a shortcut now creates a "debt" of future work, plus "interest" paid as ongoing slowness. The metaphor works for engineers. It fails for CFOs because it stops short of the only question a CFO actually needs answered: what does it cost the business?
A CFO funds things for three reasons: they reduce a quantified risk, they reduce a quantified cost, or they enable a quantified revenue opportunity. "Tech debt" as typically presented doesn't map to any of those three. It maps to a vague sense that things will get worse if we don't deal with it, which is true but not actionable.
The fix is not to explain the technical concept better. The fix is to stop using the concept as the argument and start with the business consequence.
The Three-Category Framework
Every piece of technical debt I've ever seen falls into one of three categories from a financial perspective. Build your budget case around these, not around the technical taxonomy.
Category 1: Velocity Tax
The ongoing cost of engineering capacity consumed by debt, measured in engineer-hours per week and converted to cost. This is the "interest" on the debt.
To calculate it: track (or estimate, honestly) what fraction of engineering time goes to maintaining, working around, or compensating for known architectural problems. Include: time spent on workarounds, time spent on incidents caused by fragile systems, time spent on manual processes that should be automated, and slowed feature delivery due to high coupling or poor testability.
Across the organisations I've assessed, the range is 15–40% of engineering capacity. At the median — roughly 25% — a 20-person engineering team at an average fully-loaded cost of €120k per person per year is carrying a velocity tax of:
20 engineers × €120k × 25% = €600k per year
That number is not debt. That is the annual interest payment you are making right now, every quarter, whether you fund remediation or not. The CFO is already paying it. They just don't know.
Category 2: Risk Cost
Technical debt that creates exposure to material business risk — outages, breaches, compliance failures, or inability to scale — can be modelled as risk cost using standard expected-value framing.
The formula: Annual Risk Cost = Probability of Occurrence × Financial Impact
A legacy authentication system with known vulnerabilities, running on an unsupported framework, that handles customer PII:
- Probability of a material breach in the next 12 months: 15% (conservative, based on industry data for unpatched systems)
- Financial impact of a breach: €800k (incident response, notification, regulatory fines, customer compensation, reputation cost — use your own estimates, be conservative)
- Annual risk cost: 15% × €800k = €120k/year
Remediating the system costs €60k in engineering time. Payback period: less than seven months. Framed this way, the CFO is not being asked to fund "tech debt" — they're being asked to buy a €120k/year risk reduction for a one-time cost of €60k.
The risk model doesn't need to be precise — it needs to be honest
CFOs work with probabilistic models constantly — insurance pricing, revenue forecasting, credit risk. They understand that the numbers are estimates. What they need is a model that was constructed honestly, with stated assumptions they can interrogate. A range (10–20% probability, €500k–€1M impact) with stated assumptions is more credible than a point estimate with no methodology. Show your working.
Category 3: Opportunity Cost
Debt that directly limits the ability to build or ship something with quantified revenue or strategic value. This is the most powerful framing when it's true — and the most dangerous when it's manufactured.
"We cannot launch the German market integration until we refactor the payment service" is an opportunity cost argument if the German market launch has a quantified revenue plan attached to it. If the German launch is expected to generate €2M ARR and the refactor takes 6 weeks, every week of delay costs approximately €38k in revenue. The refactor that costs €40k in engineering time has a payback of slightly over one week.
The table structure that works for CFOs:
| Debt Item | Category | Current Annual Cost | Remediation Cost | Payback Period |
|---|---|---|---|---|
| Legacy auth system (unpatched) | Risk | €120k/year (expected breach cost) | €60k | 6 months |
| Monolithic payment service | Opportunity cost | €38k/week delayed DE launch | €80k | 2 weeks post-launch |
| Manual deployment process | Velocity tax | €180k/year (3 engineers × 30% time) | €40k | 3 months |
| Undocumented data pipeline | Risk + Velocity | €90k/year | €25k | 3 months |
| Total | €390k–€430k/year | €205k | ~6 months blended |
When the CFO sees a table like this, the conversation changes. They are no longer being asked to fund a cleanup exercise. They are being shown an investment with a 6-month blended payback and a clear ongoing cost if they decline.
Building the Model: What You Need
You don't need perfect data. You need defensible estimates with stated assumptions. Here's what to gather:
For Velocity Tax:
- Engineering headcount and average fully-loaded cost (salary + benefits + recruiting amortisation)
- An honest estimate of the percentage of engineering time consumed by debt-related work — get this from your tech leads, not from your intuition
For Risk Cost:
- Identification of the specific risks (outage, breach, compliance failure, data loss)
- Probability estimate — use industry incident rates as anchors, then adjust for your specific exposure
- Financial impact estimate — this requires cross-functional input from legal, finance, and operations to cover regulatory fines, incident response costs, and business interruption
For Opportunity Cost:
- The specific feature, product, or market entry that debt is blocking
- A revenue or strategic-value estimate from the business owner of that opportunity — do not generate this number yourself
The number that kills credibility
Do not manufacture an opportunity cost argument when the opportunity isn't real. CFOs are pattern-matched to detect when a cost avoidance argument is being dressed up as a revenue argument. If you claim debt is blocking €5M of revenue and the CFO knows the product roadmap doesn't include anything worth €5M, you've destroyed trust in your entire model. Use the category that applies honestly. Velocity tax and risk cost are sufficient — you don't need all three.
Presenting to the CFO
Structure the conversation in this order. The flow from diagnosis to decision looks like this:
-
What it's costing now. Lead with the ongoing cost — the velocity tax and risk cost the business is already bearing. This reframes the ask from "please give us money" to "you're already spending this money, just unproductively."
-
What remediation costs. A specific number with a specific scope. Not "the team needs 6–12 months." "The three highest-cost items total €205k in engineering time over 14 weeks, with defined scope and acceptance criteria."
-
What the payback looks like. Blended payback across the portfolio of items. For well-chosen remediation priorities, this is typically under 12 months. Under 6 months is achievable with the right prioritisation.
-
What happens if we don't. Not a threat — a forecast. The velocity tax compounds as the codebase grows. The risk cost is static or increasing as systems age. The opportunity cost accumulates with every quarter the blocking architecture stays in place.
| What CFOs hear | What CTOs usually say | What to say instead |
|---|---|---|
| "Fund risk reduction" | "We need to fix tech debt" | "We're paying €120k/year in breach risk on this system" |
| "Recover lost capacity" | "The team is slowed down" | "25% of engineering is consumed by workarounds — that's €600k/year" |
| "Unlock a revenue initiative" | "We can't build X until Y is fixed" | "Every week of delay on the German launch costs €38k in pipeline" |
| "Clear investment with payback" | "This is important to fix" | "€205k in, €390k/year savings, 6-month payback" |
One More Thing: Debt Prioritisation Is Also Your Job
A CFO who approves a tech debt budget is making a trust investment in the CTO's ability to prioritise. The CFO doesn't know which items to fix first — that's the CTO's expertise. But the CTO must demonstrate that the prioritisation is connected to business impact, not technical preference.
The highest-ROI items are usually not the most technically interesting ones. They are the ones with the highest ongoing cost, the most imminent risk, or the clearest connection to a near-term business priority. Prioritise those. Defend the prioritisation with the financial model. Deliver the outcomes on the timeline you committed to.
One successful remediation cycle, delivered on budget and on time, with a measurable outcome — velocity recovered, incident rate reduced, feature shipped — is worth more than the most elegant financial model. The CFO funded an investment. Prove it paid off. That's how you unlock the next cycle.
Tech debt is not a technical problem that requires technical sympathy. It is a business liability that requires financial clarity. The CTOs who get remediation funded are the ones who show up with a model, not a metaphor.
If you're a CTO who wants help building the financial case for a remediation programme — or a CFO who wants an independent view on whether what's being proposed is appropriately prioritised — let's talk. I've built these models for organisations from €5M to €5B in revenue. Book a 30-minute discovery call.