How to reduce technical debt without stopping delivery

In brief

• Reduce the interest, not the principal. Debt in code that rarely changes costs little; debt in the parts you change every week costs a lot.
• Find it by overlaying where the team spends change effort with where problems occur: incidents, slow reviews, long onboarding, fragile releases.
• For each item choose deliberately: repay it, contain it behind a boundary, accept it with an owner and a review date, or retire the thing that carries it.
• Fund it continuously as part of roadmap work, not in occasional “debt sprints”. Avoid big-bang rewrites.

Why “reduce technical debt” is the wrong first goal

The technical debt metaphor is usually credited to Ward Cunningham, who used it in the early 1990s to explain why shipping imperfect code could be a sound decision, provided the team went back and improved it. The metaphor works because it has two parts. The principal is the gap between the system you have and the system you would design today. The interest is the extra effort, delay and risk you pay every time you work around that gap.

Teams that try to reduce the principal everywhere end up rewriting code nobody needed to touch. The useful goal is to reduce the interest: the drag that debt puts on the work the business actually needs. That changes which debt you pay down first, and it gives leadership a reason to fund the work.

Debt that charges interest, and debt that does not

A module with poor structure that has not changed in two years and has not caused an incident is charging little or no interest. A module with reasonable code that every feature touches, that only one engineer understands and that breaks on every third release is charging a great deal. The second one matters more, even if a code-quality tool scores it better.

Interest shows up in a few recognisable ways:

• Slower change. Work in certain areas consistently takes longer than similar work elsewhere.
• Higher failure rates. Releases that touch certain components are more likely to cause incidents or be rolled back.
• Concentrated knowledge. Only one or two people can safely change part of the system.
• Blocked options. A product or commercial goal cannot be pursued because the platform does not support it.
• Slower onboarding. New engineers take noticeably longer to become productive in some areas.

Classify it: the technical debt quadrant

Martin Fowler’s technical debt quadrant is a widely used way to classify debt by how it was taken on. It is useful less for scoring than for conversation: it separates the debt you chose from the debt you discovered, and the careful from the careless.

The technical debt quadrant

Decision matrix

Deliberate →

• Reckless · deliberateWe do not have time for designShortcuts taken knowingly without a plan to repay them. Fix the decision-making as well as the code.
• Prudent · deliberateShip now, deal with the consequencesA conscious trade-off with a known cost. Record it and schedule the repayment.
• Reckless · inadvertentWhat is layering?Debt created without knowing better. Address skills, review and standards.
• Prudent · inadvertentNow we know how it should have been doneLearning that only comes from building. Normal and healthy if acted on.

RecklessPrudent →

The quadrant also answers a question boards often ask: whether technical debt means the team did a bad job. Usually it does not. Deliberate, prudent debt is how startups get to market. The problem is debt nobody recorded and nobody owns.

Find the debt that matters

You do not need a large tooling project to find the debt that is costing you most. Combine three sources of evidence the company already has.

Locating high-interest debt

Method

1. Map change activityUse version-control history to see which files and components change most often and involve the most people.
2. Overlay the painMark where incidents, rollbacks, slow reviews, flaky tests and support escalations cluster.
3. Ask the engineersIn short interviews, ask where they avoid making changes, what they would fix with a free month, and what scares them before a release.
4. Shortlist the intersectionsAreas that change often and hurt often are your high-interest debt. Write each one down with its evidence.
5. Check against the roadmapMark which shortlisted areas sit in the path of planned work. Those move to the top.

The last step matters most for getting the work funded. Debt that blocks a roadmap item is no longer an engineering preference. It is part of the cost of that roadmap item.

Price it in terms leadership can weigh

Engineers and executives often talk past each other about debt because one side describes code and the other hears cost without benefit. Translate each shortlisted item into the same terms as any other investment: what it costs to fix, what it costs not to fix, and what risk it carries.

A rough but serviceable estimate of interest is the extra effort per change multiplied by the number of changes you expect in a period. Add the expected cost of incidents in that area, and any revenue or commitments the debt is blocking.

Precision is not the point. Ranges and stated assumptions are enough for a leadership team to compare debt work with feature work honestly.

Four ways to deal with a debt item

Not every item should be repaid. For each one on the shortlist, choose one of four responses and record the choice.

Response	What it means	Use it when
Repay	Refactor, restructure or replace the problem area	The interest is high and the area sits in the path of planned work
Contain	Put a clear boundary or interface around it, so new work does not deepen it, and replace it piece by piece	It is too large to repay at once, but it must stop spreading
Accept	Leave it, with a named owner, a reason and a date to look again	The interest is low, or the area may be retired soon
Retire	Remove the feature, system or integration that carries the debt	Usage is low enough that deleting it is cheaper than fixing it

Containment is underused. Wrapping a fragile component behind an interface and routing new work around it, then replacing it in stages, is often called the strangler pattern. It reduces interest immediately and avoids the risk of a long rewrite that delivers nothing until it is finished.

Fund it without stopping delivery

The approach that fails most often is the occasional “debt sprint”: a week or two in which the team stops feature work to clean up. It sends the signal that debt work is separate from real work, it is the first thing cut when deadlines press, and it rarely targets the highest-interest areas.

Three approaches hold up better:

1. A standing capacity allocation. Reserve a fixed share of each team’s capacity for debt and platform work, agreed with leadership and reviewed quarterly. The share is a business decision; what matters is that it is explicit and protected.
2. Repayment attached to roadmap work. When a roadmap initiative passes through a high-interest area, include the repayment in its scope and estimate. This is the easiest debt work to justify because the benefit is immediate.
3. A dedicated stream for large items. Items too big for either approach, such as replacing a core component, get their own initiative on the technology roadmap, broken into stages that each deliver a measurable improvement.

Big-bang rewrites deserve particular caution. They delay every benefit to the end, they usually take longer than planned, and the old system keeps changing while the new one is built. Prefer staged replacement unless the existing system genuinely cannot be changed safely.

How much technical debt is acceptable?

There is no universal number, and any figure presented as an industry standard should be treated with suspicion. The practical test is whether the debt is known, owned and affordable: the company knows where it is, someone is accountable for each significant item, and the interest is not stopping the business from doing what it needs to do. A company in that position can carry a good deal of debt safely. A company that cannot say where its debt is carries more risk than one with more debt it can name.

Govern it so it stays down

Reduction without governance only resets the clock. Four habits keep debt visible and under control:

• A debt register. A short, living list of significant items with their evidence, response, owner and review date. It belongs to the CTO or engineering leadership, not to a spreadsheet nobody opens.
• Recorded decisions. When the team takes on debt deliberately, write down why, what it costs and when it should be repaid. Architecture decision records work well for this.
• A definition of done that includes quality. Tests, documentation and observability are part of finishing work, so new debt is a decision, not an accident.
• Delivery measures that reveal interest. The four key metrics popularised by the DORA research programme (deployment frequency, lead time for changes, change failure rate and time to restore service) show whether the system is getting easier or harder to change. Track trends, not targets.

Report the register to leadership on the same rhythm as the roadmap. Over time the conversation shifts from “engineering wants time to clean up” to “these are the three items costing us most, and here is the plan”.

When to bring in outside help

An outside view is useful when the team is too close to the system to rank the debt objectively, when leadership needs an independent assessment before funding remediation, or when the debt question is tied to a transaction such as fundraising or an acquisition. Comtau’s technical debt assessment produces a register, a priority matrix and a phased remediation roadmap; a broader software architecture review is the better starting point when the concern is the overall shape of the system rather than specific debt. If investors are about to look, the technical due diligence checklist shows how debt will be read from the other side of the table.