Technical Debt When You Do Not Own the Stack

You own a roadmap. Somebody else, or nobody in particular, owns the software it runs on. The assessment gave you an exposure level and three lines behind it: whether the business gets what it asks for, how much of the spend goes to standing still, and whether anyone can still change the system safely. This article is about what a manager in that position can actually do.

Most advice on technical debt is written for the people who can rewrite the code. This is for the people who can only decide what gets asked for, what gets paid for, and who gets asked. That is more power than it sounds.

First, what technical debt is, in business terms

Every shortcut taken to ship something on time is a loan. The interest is paid every time the system is changed afterwards: the change takes longer, breaks more, and needs the one person who remembers why the shortcut was taken. Debt is not a moral failure. Most of it was the right call at the time. The problem is that nobody tracks it, so nobody knows when the interest started to cost more than the change budget.

The three lines in your result are the interest, seen from outside the code. Slipping deliveries are interest. A maintenance bill that grows every year is interest. Being unable to change the system because the people who understood it left is the loan being called in.

The six options

None of them is right in general. Each is right in a specific situation, and most managers end up using two at once. They are ordered from the one you can do this week to the one that takes a year.

1. Make it visible

You cannot manage a debt nobody has written down. Ask for a list: every known shortcut, workaround and "do not touch" area, with what it costs in business terms. Not "the payment module needs refactoring" but "every price change takes three weeks because the payment module needs refactoring."

When it is the right answer. Always, first. It costs a few days of an engineer's time and it turns every later conversation from opinion into arithmetic.

When it is not enough. When the list comes back empty or vague. That is not good news. It means the people who could write it have already left, and you are on the Knowledge line, not the Delivery line.

2. Separate the running budget from the change budget

Most companies have one software line in the budget. Split it. One line keeps the system standing: fixes, patches, support, hosting. The other changes it. Then watch the ratio over four quarters.

When it is the right answer. When your Running cost line was strained or at risk, and nobody can say whether it was worse last year. The split makes the trend visible, and a trend is something a board understands.

When it is not enough. When the running line is already over half and rising. Then the split tells you what you already know, and the question becomes option 3 or 5.

3. Pay it down in the path of the roadmap

Do not fund a "technical debt project". Fund the roadmap, and require that every feature which touches a debt item clears that item on the way through. The payment module gets refactored the next time a price change is scheduled, as part of the price change.

When it is the right answer. When the roadmap is live and funded and the debt sits where the roadmap is going anyway. This is the only approach that pays debt without stopping delivery, and it is the one most engineering teams prefer if asked.

When it is the wrong answer. When the debt sits somewhere the roadmap does not go. A fragile reporting layer nobody plans to touch will not get fixed this way. It also fails when there are no engineers left who know the area well enough to clear it safely, which is the Knowledge line again.

4. Recover the knowledge

If one or two people carry the system, or nobody still here does, everything else waits on this. Three things work: pairing a second engineer onto every change the one person makes, for months not weeks; automated tests written for the existing behaviour before anything is changed, because a test is documentation that cannot go out of date; and a written map of the system at the level a new engineer needs on day one.

When it is the right answer. When your Knowledge line was at risk, and before options 3, 5 or 6 are attempted. Every other option is done by someone, and that someone has to understand the system first.

When it is not enough on its own. It recovers the ability to change the system. It does not add the capacity to change it. If Delivery was also at risk, this is the first half of the answer.

5. Add a second engineering source

When the internal team, or the incumbent vendor, cannot both keep the system running and change it, the answer is usually not to replace them but to add a second source and split the work. One source keeps the lights on and holds the knowledge. The other takes the roadmap, or the debt, or one product line.

There are three shapes: hire, a development partner for a scoped piece, or a dedicated team that takes a whole area for years. Judge each on the same seven things: how soon the capacity arrives, where the money goes and when, how far it can stretch, how much of your own time it takes, whether it reaches skills you cannot find locally, what goes wrong and what it takes with it, and the situation it fits. Cost is one of the seven and never the reason on its own.

When it is the right answer. When Delivery and Running cost are both strained and the current source is honest that it cannot do both. When the roadmap is a multi-year commitment, the dedicated shape fits. When it is one integration or one rebuild, the scoped shape does.

When it is the wrong answer. When option 4 has not been done. A second source pointed at a system nobody can explain will spend its first six months rediscovering the debt, and you will pay for the discovery twice. It is also wrong when the incumbent's problem is one of trust rather than capacity. Adding a second vendor does not fix a first one you cannot rely on; it doubles the management.

6. Replace the system

The last resort, and sometimes the right one. When the system is over ten years old, the people who built it are gone, over half the spend keeps it standing, and the business has several changes waiting, a rebuild can cost less than three more years of interest.

When it is the right answer. When all three lines are at risk together and options 3 and 4 have been tried. When a vendor product now does what the custom system was built to do.

When it is the wrong answer. More often than it looks. A replacement takes longer than any estimate, the old system must keep running throughout, and the knowledge problem does not go away: somebody has to know what the old system does to build the new one. Companies that skip option 4 and go straight to 6 usually end up running both systems for years.

Which line decides

If Delivery was the worst line, start with 1 and 3. If Running cost was, start with 1 and 2. If Knowledge was, 4 comes before everything, and it is the one most often skipped because it produces no feature anybody can see.

One question to ask yourself

Not "how much technical debt do we have". Nobody knows that, and the number would not change what you do. The question is: which change that the business is waiting for would be worth paying the interest to unblock, and what is the interest on that one change? Answer that, and you have the first item on the list in option 1, with a business cost attached, and a reason to fund it that a board will accept.