Managing Technical Debt: When Clearing It Speeds Up Delivery

Managing technical debt means treating clean-up work as an investment with interest and clearing only what measurably slows delivery. The interest appears as extra effort on every change, as defects after releases and as deadlines that teams stop committing to. Once it is calculated, clean-up work can be weighed against new features like any other investment.

This article shows how executives and product owners bring technical debt into planning: with a calculation for interest and repayment, a four-quadrant model for classification and a checklist for sequencing.

What is technical debt and why does it slow delivery?

Technical debt is a set of shortcuts in software that save time now and add effort to every later change. Ward Cunningham coined the term in 1992 in an experience report on a financial application: a quick first version resembles a loan: a little debt speeds up development as long as it is repaid soon by reworking the code, and unpaid debt keeps generating interest. The interest arises when developers must first understand how an earlier shortcut behaves before they can build on it, and when they double-check every change because tests are missing.

For delivery, what matters is where this interest accrues. A team that touches one module six times a month and needs ten additional hours each time for familiarisation, manual testing and fault-finding loses 60 hours a month. That is more than a third of a full-time post, and it appears on no cost centre. It becomes visible as longer lead times, as queues in front of testing and as commitments the team no longer gives. Machine-learning systems accumulate debt as well. A research group around D. Sculley showed in a widely cited conference paper in 2015 that in such systems the model is only a small part of the code, and that the debt arises mainly in data dependencies, configuration and the connection to other systems. Anyone who brings AI into operations takes on that obligation too.

How do you recognise that technical debt is slowing your delivery?

Technical debt is slowing delivery when four signals appear together: the lead time for similar changes grows from quarter to quarter, the number of fixes after releases rises, estimates are regularly overrun, and experienced developers keep naming the same modules as the cause. Each signal can be measured without reading any code.

Research on software delivery provides a frame. In their book “Accelerate” (2018), Forsgren, Humble and Kim analysed several years of survey data and found four measures that describe delivery performance: deployment frequency, lead time from change to production, the share of changes that fail, and time to restore service. Teams that score well on speed also score well on stability. Speed and quality therefore improve together, which is the strongest reason to treat clean-up as a delivery topic. A rising lead time combined with a falling deployment frequency points to debt before anyone names it. The measures for the flow of work are explained in the article on flow metrics.

Which debt is acceptable? Fowler's quadrant

Debt is acceptable when it was taken on deliberately and with a plan for repayment. In 2009 Martin Fowler arranged technical debt along two axes: deliberate or inadvertent, prudent or reckless. This yields four quadrants that call for different responses.

The classification explains why clean-up fails in some organisations. Where deliberate debt is taken on without a date, repayment never reaches the plan because nobody owns it. Where feature deadlines override every quality rule, reckless debt accumulates, and that is a question of leadership.

How do you calculate interest and repayment?

The interest on a debt equals the additional hours per change multiplied by the number of changes per month. Repayment is the one-off effort that removes that interest. Divide repayment by interest and you obtain the payback period in months. The following calculation is illustrative and shows the method.

The example shows that the interest rate decides and the size of the debt matters less. The reporting system is unattractive and expensive to fix, but because it is rarely touched, its interest stays small. The billing module is modest in size and changed constantly, so repayment pays for itself within a quarter. Multiplied by your team's hourly rate, the calculation becomes an amount you can set beside the benefit of a new feature. The principle matches the logic of cost of delay: you prioritise by the cost of waiting.

Interest also includes the cost of defects. If a module triggers two fixes after every change, the effort belongs in the additional hours. Use only figures the team can support from its own records, such as the ticket system of the last three months.

How much capacity should be reserved for clean-up?

Reserve a fixed share of team capacity for paying down debt and set it for every planning period. A share of one tenth to one fifth of capacity is a suitable starting value for the first planning round, which you adjust using the payback periods: if the calculation shows many debts with payback under six months, raise the share; if it shows none, lower it. The order of magnitude is a rule of thumb from delivery practice and not a figure from a study.

The fixed share protects against two errors. The first is the clean-up phase that ties up the whole team every few years and brings the business nothing visible, so it is cancelled at the first schedule slip. The second is clean-up on the side, which is the first item to drop in every sprint. A share in the backlog, with an owner and a calculation, survives both. Limiting work in progress pulls in the same direction, since fewer parallel initiatives leave room for repayment, as the article on limiting work in progress shows.

The last question links repayment with prevention. A definition of done with automated tests and code review stops cleared debt from returning. What it looks like in practice is shown in the article on the definition of done.

How do you talk to the executive team about technical debt?

Talk in hours, deadlines and defect counts, because architecture terms cannot be weighed against revenue. The executive team chooses between a feature that promises revenue next quarter and a clean-up task that makes the team faster. That choice works only if both options are expressed in the same unit. The calculation supplies the unit: repaying debt A costs 240 hours and returns 60 hours a month to delivery from the fifth month onwards.

A delivery manager has a clear task in this setting. They keep the debt list with interest and repayment beside the feature backlog, present both in quarterly planning and record the decision with an owner and a date. From the delivery perspective, what counts in the end is whether teams can commit reliably, and that depends directly on how much interest they pay every day.

Managing technical debt with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisational design from the delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects from VC-funded scale-ups to DAX-40 corporations and in more than 20 countries on six continents. In the service area of delivery management he works as delivery manager, project manager or product owner and makes debt and delivery performance visible to decision-makers.

The approach follows the Niehues Delivery Model. For technical debt, three of its check questions matter: What is the baseline, and how do we measure success? Which roles, decision paths and interfaces does operations need? Who is responsible for operations from day one? The answers settle who maintains the debt list and who decides on the sequence. The scope and terms of an engagement are discussed in the free initial consultation, which lasts 30 minutes and can be booked through the contact page.