Technical debt is universally acknowledged and almost universally underfunded. Walk into the technology function of any large established organisation and the leaders there will tell you — with the weary fluency of people who have made the argument many times — that the accumulated weight of deferred technical decisions is slowing delivery, inflating operating costs, and creating risks that are growing faster than the budget to address them. Walk into the finance function of the same organisation and you will typically find that the technical debt remediation programme has been deferred again in favour of initiatives that can demonstrate a direct business case.
The problem is not that business leaders do not understand technology. In most cases, they understand enough. The problem is that technology leaders have not learned to present technical debt in the language that business leaders use to make funding decisions — the language of risk, consequence and competitive position.
Why Technical Debt Is Consistently Underfunded
The funding failure for technical debt remediation is structural, not accidental. The structural problem is that technical debt creates costs and risks that accumulate gradually, invisibly, and with consequences that are difficult to attribute. A delivery programme that takes three months longer than it should because of accumulated technical complexity does not produce a line in the accounts labelled "cost of technical debt." The extra cost is absorbed into the programme budget, attributed to scope change or estimation error, and not connected to the underlying cause.
This invisibility means that the cost of technical debt, in most organisations, is significantly understated. The estimates that technology leaders present — typically expressed as the cost of remediation, not the cost of non-remediation — consistently lose in budget prioritisation against initiatives where the business benefit is directly visible and the investment case does not depend on trusting a technology team's assessment of hidden costs.
The second structural problem is timing. Technical debt investments pay off over time — lower operating costs, faster delivery, reduced operational risk — but the payoff is not concentrated in a single event or fiscal year. It accumulates gradually, in the same way the debt accumulated. In an organisation that plans and funds on an annual cycle, and where capital and operating budgets are under constant pressure, investments with distributed future payoffs consistently lose to investments with concentrated near-term returns.
"The business case for technical debt remediation almost always fails when it is presented as a technology investment. It succeeds when it is presented as risk management — because risk management is a language that boards and audit committees already speak."
Quantifying the Real Cost
Making the business case for technical debt remediation requires quantifying costs that have previously been invisible. This is harder than producing a remediation budget, but it is the work that makes the difference between a proposal that is funded and one that is deferred.
Delivery velocity cost. The most quantifiable impact of technical debt is the drag it creates on delivery velocity. Development teams working in a highly indebted codebase spend a disproportionate amount of time understanding existing code, working around existing constraints, and managing the side-effects of changes in tightly coupled systems. This shows up as lower sprint velocity, higher defect rates, and longer time-to-market. Quantifying it requires measurement — comparing velocity in high-debt and low-debt parts of the estate, or comparing current velocity against historical benchmarks before the debt accumulated. The numbers, when measured, are typically large enough to make a compelling case on their own.
Operational risk cost. Technical debt creates operational risk in two ways: through fragility (systems that fail in unexpected ways because they are not well understood) and through obsolescence (systems running on technology that is no longer supported and for which security vulnerabilities are no longer patched). Both risks can be quantified using standard risk management approaches — probability of occurrence, cost of the failure event, cost of the regulatory consequences. In regulated financial services, where operational resilience is a supervisory expectation and DORA defines specific requirements for ICT risk management, the regulatory dimension of technical debt risk is increasingly auditable.
People cost. Technical debt creates a retention problem. The most capable engineers — the ones with the most options — find indebted codebases the most frustrating environments to work in. They leave. Their replacements, when they can be found, are more expensive and take longer to become productive. The cost of this dynamic — quantified as the premium cost of recruiting into a legacy environment, plus the onboarding cost of new starters — is rarely included in technical debt assessments but is consistently material when measured.
The most effective framing for technical debt at board level is not "investment in technology quality" — it is "operational resilience risk that is growing." Boards with responsibilities under DORA and the Senior Managers and Certification Regime (SMCR (Senior Managers and Certification Regime — the regulatory framework that assigns personal accountability to named senior individuals for defined areas of a regulated firm)) understand that unmanaged ICT risk creates personal liability. A technical debt assessment that maps the debt to specific DORA risk categories — ICT availability risk, change risk, third-party risk — and quantifies the exposure connects directly to the governance obligations that board members are already accountable for. This framing does not require the board to trust a technology team's abstract judgement about code quality. It requires them to take an informed view on a quantified risk — which is exactly what they are equipped to do.
Building a Remediation Programme That Gets Funded
The structure of the technical debt remediation business case matters as much as its content. The cases that get funded typically share structural characteristics that distinguish them from the ones that do not.
They are risk-ranked, not technically ranked. The prioritisation of remediation activity should be driven by the business and regulatory risk that the debt creates, not by the technical elegance of the solution. Boards fund risk remediation. They do not fund technical elegance. Presenting a remediation roadmap that is explicitly risk-ranked — with the highest-risk items first, tied to specific regulatory obligations or operational resilience requirements — is more fundable than a roadmap organised by technical priority.
They are phased to show early return. A five-year remediation programme that costs £20m and delivers its first measurable benefit in year three will not be funded. A programme that delivers measurable improvements in delivery velocity or operational risk reduction within the first twelve months — with the longer-term benefits building on those early wins — has a better funding profile. Structuring the remediation to show early returns requires discipline: not doing the easy technical work first, but doing the work with the most visible business impact first.
They come with a prevention plan. A remediation programme without a credible plan for preventing the debt from re-accumulating will raise legitimate questions about why it should be funded. The prevention plan does not need to be elaborate — better development standards, more rigorous code review, architecture governance that prevents the most expensive categories of debt from being created — but it needs to exist and be credible.
- Have you quantified the delivery velocity impact of your technical debt, in terms the business can verify — sprint velocity, time-to-market, defect rates — rather than abstract technical metrics?
- Have you mapped your technical debt against your DORA ICT risk categories and quantified the exposure in risk terms?
- Is your remediation roadmap risk-ranked, with the highest business-risk items addressed first?
- Does your business case include the cost of non-remediation — what it will cost to maintain the status quo over three and five years — as well as the cost of remediation?
- Is there a credible prevention plan that addresses the governance and process failures that allowed the debt to accumulate?
Technical debt will never be eliminated from a large, established technology estate. The goal is not elimination but management — keeping the debt at a level where it does not materially impair delivery, operational resilience or the ability to attract and retain capable engineers. Achieving that goal requires sustained investment, and sustained investment requires a business case that connects technology quality to business outcomes in terms that the people controlling the budget can evaluate. Building that case is not a technical skill. It is a communication and risk management skill — and it is the most important capability that technology leaders in complex organisations need to develop.