Technical Debt Is a Metaphor Your CFO Has Not Agreed To

The engineer says the system has significant technical debt. The CFO nods and asks what it will cost to fix. The engineer gives a range so wide it spans a year of the IT budget. The CFO says bring me a business case and the conversation ends. Three months later someone writes the same thing in the annual risk register and the cycle starts again. This is not a failure of will on either side. It is a failure of translation, and the metaphor is where it breaks down.

The word "debt" does specific work in a finance team. It implies a principal, an interest rate, a repayment schedule, and a date at which the obligation ends. Technical debt has none of those things in any agreed form. It is a metaphor borrowed from finance and used in engineering to describe something genuinely real - but the moment it crosses back into a finance conversation, the borrowed language sets off expectations the engineering team cannot meet. The CFO is not wrong to ask for a repayment schedule. The engineer is not wrong to say one does not exist. The problem is the word that created the expectation.

This post is about what to put in its place.

What does technical debt mean, and why does the definition matter to the person funding it?

The term was coined by Ward Cunningham in 1992, and he used it deliberately as a metaphor to explain to non-technical managers why previous decisions were slowing current work. The idea was that writing imperfect code to ship faster is like borrowing money: you get something now and pay interest later in the form of extra effort. Cunningham has since said in public interviews that the metaphor was misread almost from the start - people began using it to justify any kind of messy code rather than the specific trade-off he described.

That matters because "technical debt" in the wild now covers at least five meaningfully different situations. There is the deliberate shortcut taken to meet a deadline, where the team knew the cost and accepted it. There is the inherited system nobody designed but everyone added to for fifteen years. There is the dependency on a third-party library or platform that has gone out of support. There is the accumulated effect of team turnover, where the people who understood why something was built a certain way have all left. And there is genuine poor engineering - work that was never good - which is a different problem requiring a different response.

A CFO who is told "we have significant technical debt" cannot tell from that phrase alone which of these situations they are funding a response to. Each has a different cost profile, a different risk profile, and a different set of realistic responses. The phrase papers over distinctions that matter enormously to anyone building a budget case.

The discipline that actually serves the funding conversation is not better metaphors. It is making the specific problem visible in terms that a finance team can audit.

Why does the technical debt metaphor break down in a budget committee?

Consider what happens in a typical budget conversation. The engineering team says the system carries a substantial technical debt burden. The CFO asks: how much, and what does it cost to clear it? Engineering produces an estimate with a range that might span two to ten million pounds depending on scope, approach, and what they find once they start. The CFO asks when the debt will be paid off. Engineering explains that it is not really like that - it is an ongoing quality issue, not a fixed liability.

At this point the CFO has two rational responses. One is to push the item down the priority list because it cannot be bounded. The other is to ask for a full rewrite proposal, because at least that has a scope and an end date, even if it is expensive. Neither response is what engineering actually wanted, which was probably a steady allocation to targeted improvement work.

The metaphor has steered the conversation toward the wrong set of choices.

There is a secondary problem. The word "debt" carries a mild moral charge in everyday language: debt is something you should not have accumulated and should address as soon as possible. That framing makes it easy for an executive team to feel that acknowledging the debt without immediately funding a fix is somehow irresponsible. So the item gets deferred, with some discomfort, rather than being treated as a managed operating reality. And when it is finally raised again the following year, the same discomfort produces the same deferral.

The cycle is not caused by a lack of urgency. It is caused by a framing that makes the problem sound like a moral failing rather than an engineering trade-off with a calculable business cost.

What language actually works in a funding conversation about technical debt?

Operational drag is not a perfect term either, but it does something the debt metaphor does not: it describes a friction cost rather than a liability. It is the difference between saying "we owe money" and saying "this machine runs at 60% of capacity because it is poorly maintained." A finance team knows how to think about maintenance costs, efficiency losses, and the business case for investment in reliability.

The numbers that make this concrete are available in most engineering teams, though they are rarely collected in a form that speaks to a CFO.

The first number is the proportion of engineering capacity consumed by maintenance, rework, and working around system limitations rather than delivering new capability. Industry surveys, including Stack Overflow's annual Developer Survey, consistently show that engineers across a wide range of organisations report spending a material portion of their time on this kind of work - often between a quarter and a third of their capacity. What the survey measures is self-reported time allocation, so treat the specific figures as directional rather than precise. But your own teams can produce a version of this number from sprint retrospectives or time-tracking data, and that version is more credible than any external benchmark because it is specific to your systems.

The second number is mean time to deploy a change. This is a standard engineering metric tracked by most delivery teams and benchmarked by the annual DORA State of DevOps research. Systems with high levels of accumulated technical complexity take longer to change safely. That delay has a business cost: features that take six months instead of six weeks arrive after the market window. That is a revenue figure, not just an engineering inconvenience.

The third number is defect escape rate - the proportion of changes that cause incidents in production. High rates mean customer impact and support cost. Both translate directly to the CFO's world.

Put those three numbers in a one-page summary with the system name, the annual all-in cost of the team supporting it, and the percentage of that cost going to maintenance rather than value, and you have a business case for the conversation - not a metaphor.

How do you calculate the cost of technical debt for a business case?

Here is the arithmetic made concrete. A team of twelve engineers at an average all-in cost of ninety thousand pounds per person per year costs just over one million pounds annually. If 35% of that capacity goes to maintaining, debugging, and working around an ageing system rather than delivering new functionality, the annual carrying cost of that drag is roughly three hundred and seventy-five thousand pounds. Every year. Before you account for the incidents that become customer-visible problems, the compliance exposure if the system holds regulated data, or the competitive cost of delivering features slowly.

That number is not the cost of fixing the technical debt. It is the cost of not fixing it. That distinction matters enormously in a funding conversation.

A CFO who hears "it will cost two million to fix" and "it costs three hundred and seventy-five thousand a year to leave it" is now doing a payback calculation, which is familiar territory. If the fix takes three years to deliver, the break-even is roughly year five assuming costs hold flat. That is a capital allocation question the finance team knows how to evaluate. It is not a perfect model - software projects do not run on clean assumptions and the Standish Group CHAOS data consistently shows that large software projects overrun budget more often than not - but it is a model, which is more than a metaphor provides.

The important caveat: this calculation only tells you the economic case for doing something. It does not tell you what to do. The right response to the carrying cost might be a targeted refactoring of the highest-friction components. It might be retiring the system and migrating to something better maintained. It might be accepting the cost because the system is stable, the team knows it deeply, and the risk of change outweighs the drag. "Leave it alone" is a legitimate answer when the system is not on a trajectory that requires frequent change and when touching it carries significant delivery risk.

Konnectedly's work is specifically about reaching that conclusion through evidence rather than assumption - assessing which systems deserve investment and which should simply be allowed to run.

When is technical debt worth fixing, and when should you leave it alone?

The most common mistake in technical debt conversations is treating modernization as the default answer. It is not. There are systems in almost every organisation that carry significant technical debt by any engineering measure - they are built on old frameworks, poorly documented, resistant to change - and the right answer for them is to leave them exactly as they are.

Consider a payroll system built in the early 2000s. It runs twice a month, processes correctly, and has not had a material incident in four years. The team knows exactly what it does and what it cannot do. The business process it supports is stable. Nobody is asking it to integrate with new systems or change its calculation logic. The technical debt in that system is a fact, not a problem. Spending two million pounds to rewrite it in a modern framework would produce a system that does the same thing, creates project risk during transition, and will itself accumulate technical debt within five years. That is not a sound investment.

The systems that genuinely warrant intervention share common characteristics. They are on a trajectory of increasing change requests, usually because the business around them is evolving. They are consuming a disproportionate share of engineering capacity in maintenance. They are creating compliance exposure because they cannot be audited or cannot meet new regulatory requirements. Or they are becoming impossible to staff because the skills required to support them are leaving the market. The Stack Overflow Developer Survey is useful here: it tracks which languages and frameworks engineers are choosing and which they are actively avoiding. A system built on a technology that engineers consistently rate as "dreaded" and are avoiding is a staffing risk, and that risk has a calculable cost.

The discipline is triage, not transformation. Which systems are actively limiting the business? Which are stable liabilities that can be managed? Which should simply be retired? Those are three different answers, and they require different budget requests and different conversations with the CFO.

Frequently Asked Questions

What is technical debt in plain business terms?

Technical debt is the ongoing cost of decisions made in the past to deliver software faster or cheaper than was sustainable. It shows up as slower releases, higher defect rates, difficulty hiring engineers, and rising support costs. It is not a one-time write-off; it compounds quietly until something forces the issue.

Why does the technical debt metaphor fail in a funding conversation?

Because debt implies a repayment plan with a known end date, and technical debt has neither. CFOs hear "debt" and expect a schedule and a payoff figure. When engineers cannot supply those, the conversation stalls. The metaphor is useful for engineers but it imports financial logic that does not translate cleanly to a budget committee.

What language does resonate with a CFO when discussing technical debt?

Operational drag is a more productive frame. It describes a recurring cost with measurable symptoms: mean time to deploy, defect escape rate, the percentage of engineering capacity consumed by maintenance rather than new capability. These are numbers a finance team can audit, compare year-on-year, and use to build a business case.

How do you calculate the cost of technical debt for a business case?

Start with three figures your engineering team can produce: the percentage of sprint capacity spent on maintenance and rework, your average all-in engineering cost per person per year, and the number of engineers on the affected system. Multiply the first by the second and third. That is your annual carrying cost, before you count defect-related revenue impact or compliance exposure.

When should you fix technical debt and when should you leave it alone?

Fix it when it is slowing down work that matters to the business, raising compliance risk, or making the system dangerous to change. Leave it alone when the system is stable, well-understood, and not on a path that requires frequent change. Not every debt needs repaying; some systems are better left running quietly than disturbed.

Does technical debt always require a modernization project to resolve?

No. Some technical debt is resolved by retiring the system entirely. Some is managed through targeted refactoring of the highest-friction components without touching the rest. A full rebuild is one option, often the most expensive and highest-risk one. The right answer depends on the system's trajectory, not its age.

How long does it take to build a credible business case for addressing technical debt?

With access to the right data, a credible first-pass case takes two to four weeks. The bottleneck is usually not analysis but data collection: organisations rarely track engineering capacity consumption by system. Establishing that baseline is the first and most important step, and it is work that pays off regardless of what decision follows.