Every IT team carries technical debt. Trouble starts when nobody can say how much there is, where it sits or what it costs. In Protiviti’s survey of more than 1,000 technology executives, organizations said they spend an average of 30% of their IT budgets on technical debt. Nearly 70% said it has a high impact on their ability to innovate.
The debt itself is not the problem. Shipping a known shortcut to hit a launch date is often the right call. The problem is debt nobody manages: shortcuts nobody tracks, interest nobody measures and a backlog that only grows. Technical debt management turns that pile into a short list with owners, numbers and a budget. This guide covers the three parts of it: measuring debt, ranking it by business risk and paying it down without stopping delivery.
What Technical Debt Actually Means
Ward Cunningham coined the term in 1992 to explain to business stakeholders why software needs rework. A team borrows time today by taking a shortcut. It pays interest later, every time someone has to work around that shortcut.
The interest is the part that matters. A messy module nobody touches costs almost nothing. A messy module that three teams change every sprint costs hours every week, plus failed deployments and delayed releases. That is why the size of the debt tells you less than how often you pay for it.
Technical debt is also wider than code:
- Code debt: duplication, overly complex functions, missing tests.
- Architecture debt: tightly coupled services, a monolith that blocks independent releases, shared databases.
- Infrastructure debt: end-of-life operating systems, manual deployments, outdated dependencies.
- Data debt: inconsistent schemas, duplicate records, datasets with no owner. It is the main reason so few companies have AI-ready data.
- Knowledge debt: systems that only one person understands and nobody documented.
Types of Technical Debt: The Fowler Quadrant
Martin Fowler’s technical debt quadrant sorts debt by two questions. Was it taken on deliberately? And was the decision prudent or reckless?
| Reckless | Prudent | |
|---|---|---|
| Deliberate | The team skips design to hit a date and has no plan to come back | The team ships a known shortcut on purpose, with a ticket and a date to repay it |
| Inadvertent | Poor design because the team did not know a better way | The team finds a better design only after the system is built and in use |
The quadrant tells you what kind of fix you need. Prudent, deliberate debt is a business tool and needs a repayment plan. Reckless debt in either row points to gaps in skills, review or process. Paying it down helps for a quarter, but the same causes will create more of it.
Technical Debt vs Legacy Systems
The two terms overlap but are not the same thing. A legacy system is software that still works but runs on outdated technology or no longer fits how the business operates. Technical debt is the accumulated cost of shortcuts and decay, and it can sit in a system shipped last year.
Legacy systems usually carry the heaviest debt, which is why both end up on the same roadmap. When paying down the debt in a system would cost more than replacing it, the question changes from debt management to legacy system modernization. In McKinsey’s research on tech debt, surveyed CIOs estimated debt at 20 to 40% of the value of their entire technology estate. At that level, some systems are cheaper to rebuild than to repair.
How to Measure Technical Debt
No single number captures technical debt. The teams that manage it well track two layers: engineering metrics that show where the debt is, and business metrics that show what it costs.
Engineering metrics
| Metric | What it shows | Where to get it |
|---|---|---|
| Technical debt ratio | Cost to fix known issues compared to the cost of building the code | Static analysis tools such as SonarQube |
| Complexity of frequently changed files | Where debt charges interest right now | Git history plus complexity scans, CodeScene |
| Test coverage of critical paths | How risky each change is | CI pipeline reports |
| End-of-life components and outdated dependencies | Security and support exposure | Dependency scanners, asset inventory |
| Change failure rate and lead time for changes | How debt slows and breaks delivery | DORA metrics from your CI/CD tooling |
Business metrics
| Metric | What it shows |
|---|---|
| Share of the IT budget spent on maintenance (run vs change) | How much money debt absorbs |
| Share of engineering time spent on unplanned work | How much capacity debt absorbs |
| Incidents and outage minutes tied to known debt items | What debt costs customers and operations |
| Lead time for a typical change in a given system | How debt delays business requests |
Technical debt ratio
The technical debt ratio (TDR) compares the effort needed to fix known issues with the effort it took to build the code:
TDR = (Remediation cost ÷ Development cost) × 100If fixing the known issues in a service would take 400 hours and building it took 8,000 hours, the TDR is 5%. Thresholds depend on the tool’s rules and cost model, so the trend matters more than the absolute value. A ratio that rises every quarter is a warning even if it still looks small.
Start with a debt register
Metrics only help when they point to specific items. Keep a technical debt register: one row per item, with the system, an owner, the estimated cost to fix, the estimated interest (hours lost per month, incidents) and the business risk. A spreadsheet is fine to start. What matters is that the register is updated every quarter and not written once for an audit.
How to Prioritize Technical Debt
Rank debt by the interest it charges, not by how ugly it looks. A simple scoring model works for most portfolios. Rate each item from 1 to 5 on four factors:
- Business impact: how much revenue or how many operations depend on the system.
- Change frequency: how often teams modify that part of the system.
- Risk: security exposure, compliance gaps, outage history, vendor support ending.
- Effort: how much work the fix takes.
Priority score = business impact × change frequency × risk ÷ effort.
| Debt item | Impact | Frequency | Risk | Effort | Score | Decision |
|---|---|---|---|---|---|---|
| Payment service on an unsupported framework | 5 | 4 | 5 | 4 | 25 | Fix this quarter |
| No automated tests in the checkout flow | 5 | 5 | 3 | 3 | 25 | Fix this quarter |
| Duplicate customer tables in CRM and ERP | 4 | 2 | 3 | 4 | 6 | Plan for next quarters |
| Messy code in an internal reporting tool | 2 | 1 | 1 | 2 | 1 | Accept and document |
The scores lead to four decisions:
- Fix now: critical systems with high risk. These go into the current quarter.
- Plan: critical systems with manageable risk. Schedule the work into the roadmap.
- Delay: low-impact systems with real debt. Write down the risk and review it every quarter.
- Accept: low-impact, low-risk debt, or code that is about to be retired. Do not spend on it.
The last category matters more than it seems. A stable system that nobody changes can carry a lot of debt at almost no cost. Refactoring it wins nothing.
How to Pay Down Technical Debt
One-off cleanup projects rarely last. A team spends a quarter on debt, delivery pauses, and within a year the backlog is back where it was. McKinsey makes the same point: earmark part of the IT budget for steady repayment instead of funding large write-off projects. In practice, that means:
- Set a standing budget. Many teams reserve 10 to 20% of each sprint or release for debt. The exact share matters less than keeping it fixed, so debt work does not lose every fight with feature work.
- Attach paydown to feature work. When a team changes a module for a new feature, it also fixes the debt in that module. Debt in the most-changed code gets paid down first, almost by default.
- Stop new debt at the door. Quality gates in CI, code review rules and a definition of done that includes tests stop the register from refilling. Deliberate shortcuts go into the register with an owner and a repayment date.
- Replace large debt in increments. For a system that needs deep change, patterns like the strangler fig let teams replace parts one at a time while the old system keeps running. Our legacy modernization guide covers these patterns in detail.
- Retire before you refactor. Some debt disappears when the application does. Before you fund a cleanup, check whether the system is still needed or duplicates another one.
- Track the trend. Review the register, the debt ratio and the business metrics every quarter. A falling trend is the evidence that keeps the budget in place.
How to Build the Business Case
Business leaders do not fund refactoring. They fund faster delivery, fewer outages and lower risk, so the case has to be written in those terms. That is the core of business-IT alignment: IT work explained through the outcomes the business already tracks.
Translate the top items in your register into money and time. Say 20 engineers lose 6 hours a week working around one brittle integration. At a loaded cost of USD 70 per hour, that is USD 8,400 a week, or about USD 437,000 a year. Add the incidents tied to that integration and the features delayed by it, and the fix has a clear return.
Keep the report to one page: the top 10 debt items, the interest each one costs, the plan and the trend since last quarter. Leaders can approve a page like that in one meeting.
Technical Debt and AI-Generated Code
AI coding assistants help teams write code faster. They can also add debt faster: more code, more duplication and code that nobody on the team fully understands. The answer is the same discipline as before, with review, tests and quality gates applied to generated code as strictly as to human code.
AI can help with paydown too. Mechanical work such as dependency upgrades, framework migrations and adding tests to old code suits AI tools well, as long as engineers review every change.
FAQ
What are the 4 types of technical debt?
The phrase usually refers to Martin Fowler’s quadrant: deliberate-reckless, deliberate-prudent, inadvertent-reckless and inadvertent-prudent. Some guides use it for areas of debt instead: code, architecture, infrastructure and process.
What is the 80/20 rule for technical debt?
It is used in two ways. The first says most of the interest comes from a small share of the code, usually the complex parts that change often. The second is a capacity rule: about 80% of engineering time goes to features and 20% to debt and maintenance.
What is a good technical debt ratio?
There is no universal target, because each tool calculates remediation cost differently. Many teams aim to keep the ratio in single digits. A stable or falling trend matters more than the exact number.
How much of the IT budget should go to technical debt?
There is no standard figure. In Protiviti’s survey, organizations spent an average of 30% of IT budgets on debt, mostly as unplanned cost. A planned allocation of 10 to 20% of engineering capacity is a common starting point. Adjust it to the size of your register.
Who owns technical debt?
Ownership is shared. Engineering teams estimate the debt and the effort to fix it. System and product owners decide what gets fixed and when. IT leadership owns the portfolio view, the budget and the quarterly report to the business.
