8 November 202611 min read

How to Manage Technical Debt: A Practical Guide

A 1980s bank counter holding an open card file, a mechanical adding machine with paper tape and a brass stamp, lit by a small amber lamp.

To manage technical debt, make it visible, rank it by business impact, reserve a fixed share of every sprint or budget for paying it down, and measure whether the work is paying off. You don’t need a rewrite or a freeze on new features. You need a short written list of the debt that hurts most and a steady habit of fixing it.

This guide walks through that process in order: what technical debt is, how to assess it, how to prioritize it, how much capacity to set aside, and how to tell that it’s working.

TL;DR

Technical debt is the future cost of shortcuts taken now. It compounds, so the longer it sits, the more expensive it gets.
Start with an audit: baseline delivery metrics, a look at architecture, code and infrastructure, interviews with your developers, and one shared register.
Rank each item by business impact and by cost of delay, not by how ugly the code looks.
Reserve a recurring slice of capacity. Published figures range from about 15% to 30% of IT budgets, so pick a number you can hold and keep it steady.
Track a small set of measures, such as delivery frequency, recovery time and the technical debt ratio, and review them every quarter.

What technical debt is, and why it costs real money

Gartner defines technical debt as the deviation of a system from its nonfunctional requirements. Teams create it through short-term sacrifices, shortcuts and workarounds made to hit a deadline. The academic working definition from a Dagstuhl seminar says the same thing more formally: design or implementation choices that are expedient now but make future change more costly or impossible.

The financial metaphor holds up. IBM describes technical debt as accumulating interest over time, so the longer it goes unaddressed, the more expensive it is to resolve. In practice the interest shows up as slower releases, bugs that return, and developers who spend their week working around the system instead of improving it.

It is also very common. A Gartner survey run from December 2022 to March 2023 found that 93% of respondents currently experienced technical debt, most often in architecture (67%), infrastructure (58%) and code (53%). Gartner also expects that by 2027, 80% of technical debt will be architectural, up from 30% in 2024. That matters for how you manage it: the expensive debt is increasingly in how systems fit together, not in individual lines of code.

The business impact is measurable. A 2024 Morning Consult survey of 500 US business and technology leaders found that 80% had delayed or canceled business-critical projects in the previous 12 months because of technical debt, and 79% reported higher software costs. The survey sponsor sells software, and the sample is American, so read it as an indication rather than a Swiss benchmark.

Not all debt is a mistake

Before you try to remove debt, separate the debt you chose from the debt you drifted into. Martin Fowler’s quadrants, summarized by Asana, sort it along two lines: deliberate or inadvertent, prudent or reckless.

Quadrant	What it looks like	What to do
Prudent and deliberate	You ship fast and plan to deal with the consequences later	Log it with a repayment trigger
Reckless and deliberate	You know the better way but skip it for speed	Stop the pattern, fix the highest-risk items first
Prudent and inadvertent	You find a better design after building	Schedule the refactor when you next touch the area
Reckless and inadvertent	The team lacked the knowledge to do it well	Add review, pairing or senior guidance, then fix

Taking on debt on purpose can be the right call. The Dagstuhl report notes that it may be warranted in a rapidly growing market where time to market is essential. A startup launching an MVP in eight weeks is making a trade, not a mistake. The mistake is making the trade and never writing it down.

InfoQ’s authors add a useful point: almost every architectural decision trades one quality against another, such as security against usability or scalability against time to market. So some debt is simply the price of any decision, and the goal is to know where it sits.

Step 1: Assess your technical debt

An assessment, or technical debt audit, gives you a shared picture of what you owe. A practical sequence, drawing on GainHQ’s audit guide, looks like this.

Collect baseline delivery metrics

Pull data from the tools you already use, such as GitHub, GitLab, Azure DevOps or Jira. Look at deployment frequency over the last 6 to 12 months, mean time to restore after incidents, and change failure rate. These numbers show whether debt is slowing you down, and they become your “before” picture.

Review architecture, code and infrastructure

Walk through current architecture diagrams, and compare them with what is actually running. Use static analysis to find hotspots: files with high complexity or low test coverage. GainHQ suggests treating cyclomatic complexity scores above 10 as a sign of high maintenance risk. Treat that as a rule of thumb, not a verdict, and look at hotspots that are also changed often.

If your debt includes a public website, an automated technical website audit can flag site-level issues alongside the code review, so the findings land in one list.

Interview the people who live with it

Data misses a lot. Ask developers and stakeholders which parts of the system they dread touching, which releases hurt, and which workarounds everyone knows. A support lead will often name a fragile integration that no dashboard shows.

Build one register

Keep every finding in a single technical debt register with consistent fields: category, location in the codebase, symptoms, estimated effort and business impact. A spreadsheet is enough for a small team. Larger organizations sometimes track lifecycle statuses, and the IF4IT inventory model lists states from Suspected and Validated through Deferred, Approved for Remediation and Closed. For a small team, four will do: Suspected, Accepted, Planned, Done.

Step 2: Prioritize what to fix first

Research on prioritization starts with a simple question. A systematic literature review says practitioners should first decide whether they are ranking refactoring tasks against each other, or ranking a refactoring against new features and bug fixes, because the two need different ways of assessing impact.

For most teams the second question is the real one: this debt item against that feature. A workable scoring approach uses four questions per item:

Business impact. Does it block revenue, slow a roadmap item, or raise the risk of an outage or data problem?
Frequency of contact. How often do developers touch this area? Debt in code nobody changes costs little.
Cost of delay. Does it get worse as you build on top of it? Architectural debt usually does.
Effort. Can you fix it in days, or does it need a multi-month project?

Score each from 1 to 3, multiply impact, contact and delay, and divide by effort. The point is not mathematical precision. It’s to force a conversation in which engineering and the business use the same words.

Gartner warns that reducing debt needs stakeholders to agree on the risk and work together. It names three obstacles: short-term savings, shiny object syndrome and stakeholder gridlock. Without targeting the main issues, it says, the enterprise reverts to its original state. So pick a few high-impact items and finish them, rather than spreading effort thinly.

A worked example

Imagine a Zurich e-commerce team with four items on its register:

Item	Impact	Contact	Delay	Effort	Priority
Hand-built order export to ERP breaks monthly	3	2	3	2	9
Outdated checkout framework	3	3	3	3	9
Inconsistent naming in admin screens	1	3	1	1	3
Unused legacy reports module	1	1	1	1	1

The export and the checkout framework tie, so the team picks the export first: it is a smaller job, and it can be done in a single sprint. The naming mess waits for the next time someone touches those screens. The unused module is deleted when convenient. Nobody argues about taste, because the ranking rests on impact and effort.

Step 3: Reserve capacity and put it in the plan

Debt work that competes with features in every planning meeting loses. The fix is a standing allocation.

Published figures vary a lot, which shows that there is no single right number:

Accenture says companies need to allocate about 15% of IT budgets to remediating technical debt, and that companies with lower-than-average debt expect better growth (5.3% vs. 4.4% for 2024 to 2026).
Protiviti reports that organizations spend on average 30% of IT budgets and 20% of resources on technical debt management.
A 2024 vFunction study of more than 1,000 US leaders found that 51% of companies dedicate more than a quarter of annual IT and engineering budgets to remediation.

For a small team, a practical starting point is one day in five, which matches the common rule of thumb of about 15 to 20%. Put it in the sprint as named work with an owner, just like a feature. If a release is at risk, shrink the scope of the feature before you raid the debt allocation, otherwise the allocation quietly disappears.

Two habits keep debt from growing back:

Leave it better. When a developer touches a risky area for a feature, they add tests or simplify it as part of the same change.
Definition of done. A feature isn’t done until its shortcuts are logged in the register with a repayment trigger, for example “revisit when we pass 1,000 orders a day.”

Step 4: Pay it down in small pieces

Big-bang rewrites are the most expensive way to reduce technical debt, because you pay for the old system and the new one at once and the business waits. Incremental repayment works better:

Refactor behind tests. Add tests around a fragile module first, then change its internals.
Strangle the legacy part. Route one function at a time to a new component, and retire the old code when nothing calls it.
Wrap, then replace. Put a clean API in front of a messy system so new work stops depending on its internals, then replace the internals later.
Delete. Unused features, dead code and abandoned dependencies are the cheapest debt to remove.
Review AI-generated code. Code produced by assistants needs the same review and testing as anything else, or it becomes new debt faster than you can pay the old.

When the debt sits in the platform itself, a staged migration or replatforming is sometimes the honest answer. Plan it as a series of releases with a working system at each step, not as one cutover.

Step 5: Measure whether it’s working

Pick a few measures and review them each quarter.

Delivery metrics. The deployment frequency, restore time and change failure rate you captured in the audit. Improving trends are the clearest sign that debt work is paying off.
Technical debt ratio. SonarSource describes this as the estimated cost to fix existing issues as a proportion of the cost to build the code originally. A rising ratio signals that debt is piling up faster than you pay it down.
Register health. Items closed versus items added per quarter. If the register only grows, your allocation is too small or your habits aren’t changing.
Team sentiment. A short quarterly question to developers: how hard is it to ship a change safely? It often moves before the numbers do.

Report these in business terms, such as “releases are now weekly instead of monthly,” because that is what keeps the allocation funded.

When to bring in outside help

An outside review makes sense when your team is too close to the system to rank its problems, when a key engineer has left, or before an investment, acquisition or major replatform where you need an independent picture.

At Ampersand, senior engineers lead each engagement from the first conversation to handover, so the person who reviews your system is the person who explains the findings. Our offer covers audits, technical due diligence, replatforming and migration of legacy systems, and part-time CTO roles. If you want guidance on an ongoing basis, our Guidance plan is 799 CHF per month, and our Run & monitor plan for ongoing support is 750 CHF per month. For projects and other plans, see the full list of services and plans, or start from our homepage.

FAQ

How much time should we spend on technical debt?

There is no universal figure. Published numbers include about 15% of IT budgets from Accenture and 30% on average from Protiviti. A small team can start with one day in five and adjust after a quarter, based on how your delivery metrics move.

Should we stop building features to fix technical debt?

Usually not. A freeze costs the business momentum and rarely addresses the right items. Reserve a steady share of capacity, fix the highest-impact items first, and combine small repairs with feature work in the same area.

What is the difference between a technical debt assessment and an audit?

In practice the terms overlap. Both collect metrics, review architecture, code and infrastructure, interview the team, and end with a register of findings. An audit tends to be a one-off, more formal exercise, while an assessment can be a lighter, recurring check.

How do we explain technical debt to non-technical stakeholders?

Use the financial comparison: shortcuts saved time now but charge interest through slower releases and higher costs. Then show two or three register items with their business impact, such as a monthly failure that costs your operations team hours.

Is all technical debt bad?

No. A deliberate shortcut taken to reach the market in time can be a sound decision, as long as it is logged and you have a plan to revisit it. The harm comes from debt nobody knows about.

Sources

Talk to us

Have a project this touches on?

A free 10-minute call is the fastest way to find out whether we are the right studio for it.

Book a free 10-min call

Keep reading