Every IT leader knows the feeling. You are staring at a system that works - technically - but every change takes three times longer than it should. Deployments that should take minutes take hours. New starters spend their first week trying to understand why the codebase has four different ways of doing the same thing. And somewhere in the back of your mind, you know that one critical integration is held together by a script nobody fully understands.
That is technical debt. And if you cannot put a number on it, you will never get the budget to fix it.
I have spent years managing IT infrastructure and development teams supporting over 250 users at an e-commerce company. Along the way, I have learned that the biggest barrier to tackling technical debt is not technical - it is communication. Engineers understand the problem intuitively. The board needs it in pounds and pence.
Here is the framework I use to measure technical debt, prioritise what to fix first, and build a business case that actually gets approved.
What Technical Debt Really Is (and Is Not)
Ward Cunningham coined the term "technical debt" in 1992 as a metaphor for the shortcuts teams take to ship faster. Like financial debt, it accrues interest - every future change costs more because of the shortcuts taken earlier.
But not all technical debt is bad. Just as a mortgage lets you buy a house before you have saved the full price, deliberate technical debt lets you ship features quickly when speed matters. The problem is unmanaged debt - the kind that accumulates silently until it becomes a crisis.
In my experience, technical debt falls into four categories:
- Deliberate and prudent - "We know this is not ideal, but shipping this week is worth more than perfection next month." This is strategic debt with a clear payoff.
- Deliberate and reckless - "We do not have time for tests." This is corner-cutting that always costs more later.
- Inadvertent and prudent - "Now we know what we should have built." This is the natural result of learning and is unavoidable.
- Inadvertent and reckless - "What is a design pattern?" This comes from lack of skill or oversight and is the most expensive to fix.
Understanding which type you are dealing with changes how you prioritise and communicate the problem. I explored the strategic mindset shift required in my earlier piece on reframing tech debt as a leadership challenge - this post focuses on the practical measurement and business case side.
Why the Board Does Not Care (Yet)
I have sat in boardrooms where I tried to explain technical debt using engineering language. Terms like "code smell," "coupling," and "architectural drift" got blank stares. The conversation moved on quickly.
The board cares about three things: revenue, risk, and cost. If you cannot connect technical debt to at least one of those, you will not get budget. Full stop. That is exactly where IT management consulting adds value - turning technical concerns into commercial decisions leaders can actually act on.
Here is what changed my approach: I stopped talking about the debt itself and started talking about its consequences in business terms.
- "Our deployment pipeline takes 4 hours instead of 20 minutes, which means we can only ship once a day instead of continuously. That cost us two weeks of lost sales during the Black Friday promotion because we could not push a critical pricing fix fast enough."
- "Three of our five senior developers spend roughly 30% of their time working around legacy code rather than building new features. That is the equivalent of burning one full-time salary on maintenance that should not exist."
- "Our payment integration uses an API version that reaches end-of-life in six months. If we do not migrate, we lose the ability to process card payments."
Numbers. Timelines. Business impact. That is the language that gets attention.
A Framework for Measuring Technical Debt
Quantifying something as nebulous as technical debt sounds impossible, but it is not. You just need to measure the right proxies. Here is the framework I developed and refined over several years.
Step 1: Identify the Debt
Start with a structured audit. I use a simple spreadsheet with the following columns:
- System/component - What is affected
- Type of debt - Using the four categories above
- Description - Plain-English explanation of the problem
- Impact area - Velocity, reliability, security, or scalability
- Severity - High, medium, or low
Get your engineering team involved. Run a session where everyone can contribute anonymously - you will be surprised what surfaces. In our case, we identified 47 distinct items of technical debt across our platform in the first audit.
Step 2: Quantify the Cost of Inaction
For each item, estimate the ongoing cost using these metrics:
Developer time tax - How much extra time does this debt add to every related task? If a developer spends an extra 2 hours per week working around a legacy authentication module, that is roughly 100 hours per year. Multiply by your loaded cost per developer hour (salary plus benefits plus overhead, typically between £50 and £80 per hour for mid-level engineers in the UK), and you have a tangible annual cost.
Incident cost - How often does this debt cause incidents? What is the cost per incident in terms of engineer time, lost revenue, and customer impact? We tracked this over six months and found that our legacy order processing system was responsible for 60% of our on-call pages - roughly 3 incidents per week, each costing an average of 4 hours of engineer time plus measurable revenue impact during downtime.
Opportunity cost - What features or improvements cannot be delivered because the team is fighting fires or working around limitations? This is harder to quantify but often the most compelling. We estimated that technical debt was consuming roughly 35% of our total engineering capacity - meaning for every three engineers we employed, one was effectively doing nothing but servicing debt.
Risk cost - What is the probability and impact of a catastrophic failure? An end-of-life dependency with no migration plan is a ticking time bomb. Multiply the probability of failure by the estimated business impact to get a risk-adjusted cost.
Step 3: Calculate the Cost of Remediation
For each item, get engineering estimates for the fix. Be honest about uncertainty - use ranges rather than single numbers. A database migration might take "between 3 and 6 weeks of one engineer's time," which translates to a cost range you can present with confidence.
Step 4: Prioritise Using a Debt Ratio
I use a simple ratio to prioritise:
Debt Ratio = Annual Cost of Inaction / One-Time Cost of Remediation
A ratio above 2.0 means the debt pays for itself within six months. Anything above 1.0 pays for itself within a year. Below 1.0, you are looking at a longer payback period - which might still be worth it for risk reduction, but requires a different argument.
Sort your debt items by this ratio. The top of the list is where you start.
In our case, the top three items had ratios of 4.2, 3.8, and 3.1. That made the business case almost trivial - we were spending four times more per year living with the debt than it would cost to fix it.
Building the Business Case
With your data in hand, building the business case becomes a straightforward exercise. Here is the structure I use.
The One-Page Executive Summary
The board does not want a 30-page document. They want clarity. I use a single page with four sections:
- The problem - "Technical debt is costing us an estimated £X per year in lost productivity, incidents, and delayed features."
- The evidence - Two or three specific, quantified examples from your audit.
- The proposal - "We recommend a 12-week remediation programme targeting the top 10 debt items, requiring £Y in dedicated engineering time."
- The return - "This will reduce ongoing costs by £Z per year, improve deployment frequency by X%, and eliminate our three highest-risk dependencies."
Framing It as Investment, Not Cost
Language matters enormously. "We need to refactor our codebase" sounds like an expense with no return. "We are proposing a £80,000 investment that will save £200,000 annually and reduce critical incident risk by 60%" sounds like a no-brainer.
I always present technical debt remediation alongside feature work, not as an alternative to it. The pitch is not "instead of building features, we want to fix old code." It is "by investing 20% of our capacity in debt reduction, we will increase our feature delivery speed by 40% within two quarters."
Using Leading Indicators
Once you have approval, you need to show progress. Track and report on:
- Deployment frequency - How often can you ship?
- Lead time for changes - From commit to production
- Change failure rate - What percentage of deployments cause incidents?
- Mean time to recovery (MTTR) - How quickly can you fix problems?
These are the four DORA metrics, and they are well-understood benchmarks that translate directly to business value. Report on them monthly. When the board sees deployment frequency double and incident rates halve, the next budget request becomes much easier. For more on translating technical outcomes into language the board understands, see my guide to data storytelling for IT value.
Making It Sustainable
The biggest mistake I see is treating technical debt remediation as a one-off project. It is not. Debt accumulates continuously, and you need a continuous process to manage it.
The 20% Rule
We allocate 20% of every sprint to debt reduction. This is non-negotiable and built into our capacity planning. It is not glamorous, but it keeps debt from compounding. Think of it like making minimum payments on a credit card - it prevents the balance from growing while you tackle the big items strategically.
Debt Retrospectives
Every quarter, we run a technical debt retrospective. The engineering team reviews the current debt register, updates estimates, and identifies new items. This keeps the data fresh and ensures nothing festers unnoticed.
Architectural Decision Records (ADRs)
When we take on deliberate debt - and sometimes we should - we document it in an ADR. This includes what the debt is, why we are taking it on, and when we plan to pay it back. This creates accountability and prevents "temporary" solutions from becoming permanent fixtures.
Common Objections (and How to Handle Them)
Over the years, I have heard every objection. Here are the most common and how I address them.
"We cannot afford to slow down feature delivery."
You are already slower than you should be. Technical debt is the reason features take longer than estimated. Investing in debt reduction accelerates future delivery.
"If it is not broken, why fix it?"
It is broken - you just cannot see it yet. Show them the incident data. Show them the developer time tax. Show them the end-of-life dependencies. "Not broken" and "not yet catastrophic" are very different things.
"Can we just rewrite the whole thing?"
Almost certainly not. Full rewrites are expensive, risky, and take far longer than anyone estimates. Incremental remediation delivers value continuously and reduces risk at every step.
"How do we know this will actually deliver the savings you are projecting?"
You do not, with certainty. But you have data, benchmarks, and a clear measurement framework. Propose a three-month pilot targeting the highest-ratio items and measure the results before committing to the full programme.
The Real Cost of Doing Nothing
Technical debt does not stay static. It compounds. The longer you leave it, the more expensive it becomes to fix, and the more it constrains your ability to respond to market changes.
I have seen companies where technical debt became so severe that they could not adopt new payment providers, could not scale for peak trading, and could not meet regulatory deadlines. At that point, the cost is not measured in developer hours - it is measured in lost contracts and failed audits. This is exactly why boring, reliable infrastructure beats cutting-edge every time - it reduces the kind of accumulated complexity that makes technical debt unmanageable.
The true cost of technical debt is not what it costs today. It is what it will cost you when you can no longer afford to ignore it.
Key Takeaways
- Technical debt is a business problem, not just a technical one. Frame it accordingly.
- Measure the cost of inaction using developer time tax, incident cost, opportunity cost, and risk cost.
- Use the debt ratio (annual cost of inaction divided by remediation cost) to prioritise ruthlessly.
- Present a one-page business case with clear numbers and projected returns.
- Make debt management sustainable with the 20% rule, quarterly retrospectives, and ADRs.
- Track DORA metrics to demonstrate ongoing value to leadership.
The conversation about technical debt does not have to be adversarial. When you bring data, clarity, and a clear return on investment, it becomes one of the easiest business cases you will ever make.
If you need help building the business case for technical debt remediation or want an outside perspective on your technology estate, my IT management consulting and technical consulting services can support both the strategy and delivery. Get in touch to discuss your priorities.
Daniel Glover is an IT leader with experience managing technology teams and infrastructure for organisations with 250+ users. He writes about IT strategy, cybersecurity, and engineering leadership at danieljamesglover.com.
