There’s an expression among sailors: “Everything on your boat is either broken or about to break”. This mirrors technical debt in deteriorating IT systems.
Once you accept that, owning a yacht becomes considerably easier. Psychologically, at least. Financially, perhaps not.
Last weekend I was sanding some tired teak on my boat, getting it ready for some fresh coats of varnish. For once I wasn’t fixing anything. Everything was working, which meant I could spend some time improving the boat rather than repairing it.
It was a nice feeling. It lasted until that afternoon, when I discovered the alternator wasn’t charging properly.
But while I was sanding, I found myself thinking about how much time and money we spend keeping an asset going compared with making it better. With a boat, you quickly learn that maintenance isn’t optional. Leave the small jobs long enough and they have an unfortunate habit of becoming larger and much more expensive ones.
Technology works in much the same way.
The debt we don’t see
In software development, there’s a term for this: technical debt.
In its purest form, it describes the future cost.
That cost comes from choosing an easier or quicker solution today.
That doesn’t necessarily make the original decision a bad one. There can be perfectly good reasons to take on technical debt. Getting something to market quickly might be more important than building the perfect solution. An upgrade might sensibly be deferred because the business has more pressing priorities. A workaround might be good enough for something that isn’t especially important.
The problem is not necessarily taking on the debt. The problem is forgetting that you’ve taken it on.
I’ve always thought the idea applies much more widely than the software development definition. Technical debt also accumulates when businesses fail to maintain and upgrade existing technology, when documentation isn’t kept up to date, when knowledge becomes concentrated in a few people, or simply when a succession of sensible short-term decisions creates an increasingly complicated technology environment. Those were some of the issues I identified when I first wrote about technical debt several years ago.
Like financial debt, technical debt can then start accumulating interest. Changes become more difficult, support becomes more complicated and increasing amounts of time and money are needed simply to keep everything running.
And this is where technical debt stops being purely a technology problem.
The more effort you put into running the business, the less capacity remains for changing the business.
But I now think there’s another dimension to the problem.
Technology can work perfectly well and still lose value
Most businesses work quite hard to establish the value of technology before they buy it. There will be a business case, expected benefits and plenty of discussion about what the organisation hopes to get in return for its investment.
Then the system goes live and everybody moves on.
The trouble is that value doesn’t stand still.
The business changes. Processes change. People leave and new people arrive. Someone builds a spreadsheet because it’s easier than changing the system. Another tool is purchased to solve a problem that the first one was supposed to address. Meanwhile, the original supplier releases new capabilities that the business may barely notice, let alone use.
There may be nothing technically wrong with the original system. It might still do exactly what it was designed to do.
It just doesn’t deliver as much value as it could.
I’ve come to think of this as value debt: the growing gap between the value an organisation is getting from its technology and the value it could reasonably be getting.
Technical debt and value debt are closely related, but they’re not quite the same thing. A technically well-maintained system could still be delivering poor value because the business has changed around it. Equally, an older system might contain significant technical compromises but continue to deliver considerable business value.
That distinction matters because it changes the question we should be asking.
“Is it working?” is a bit like asking whether the boat floats.
It’s important, but it’s a pretty low bar.
A much better question is:“Is it still earning its keep?”
So how do you manage technical debt?
The temptation once you identify technical debt is to turn it into another programme. Catalogue everything, establish a large remediation plan and start replacing systems.
I think that’s the wrong place to begin.
The objective isn’t to eliminate all technical debt. That would probably be impossible and may not even make commercial sense. The objective is to understand the debt you’re carrying, decide which parts matter and consciously manage the consequences.
A good starting point is simply to find out where the debt is.
Talk to the people who actually use and support your systems. Ask which upgrades keep getting postponed, which systems are difficult to change and where people are relying on spreadsheets or manual workarounds. Ask what they would fix tomorrow if they suddenly had the time and budget. Find out which processes depend on one person knowing something that nobody has ever written down.
I’m particularly interested when I hear the phrase“We’ve always done it that way.”
It often means that something which was once a perfectly reasonable decision has quietly become a permanent feature of the business.
The objective isn’t to compile an enormous register of everything that’s technically imperfect. Almost every organisation would end up with a very long list. What matters is identifying the things creating meaningful cost, risk, friction or constraint.
That means making the debt visible in business terms.
You can see the invoice for a new system. What is much harder to see is the cumulative cost of employees spending extra time on workarounds, maintaining duplicate information, manually passing information between systems or avoiding functionality because nobody really understands how it works.
Rather than trying to put an artificial monetary value on everything, I’d start with a few straightforward questions. What problem is this creating today? What happens if we do nothing? Is it becoming harder to address? Is it preventing us from making other changes? And is it consuming resources that could be used more productively elsewhere?
That gives you the basis for distinguishing between debt that really matters and debt you can consciously choose to live with.
Stop adding debt accidentally
The next step is less exciting, but arguably more important: stop creating unnecessary new debt.
Some technical debt is taken on consciously. A lot of it simply accumulates.
A temporary workaround becomes permanent. Documentation isn’t updated after a change. An upgrade gets postponed once and then postponed again. A key person leaves and takes years of undocumented knowledge with them. Another application gets bought to solve one particular problem without anyone considering how it fits with everything else.
None of these things necessarily creates an immediate crisis. That’s precisely why they are easy to tolerate.
Good technology housekeeping therefore matters. Keeping reasonably current with supported versions, maintaining useful documentation, building organisational knowledge and assigning clear ownership were all part of my earlier approach to managing technical debt. [Solitaire…l Debt.PDF | PDF]
None of this is especially glamorous.
But then neither is sanding teak.
The value comes from avoiding a much bigger problem later.
There is also a danger of assuming that managing technical debt means replacing old technology. I don’t think that’s right either. An older system that is stable, understood, properly supported and doing what the business needs may represent considerably less of a problem than a newer system surrounded by poor processes, workarounds and unnecessary complexity.
Age isn’t the important measure. Neither is whether the technology is fashionable.
The question is whether it remains fit for the business you have today.
Sometimes the answer will be replacement. But it might equally be an upgrade, some simplification, a process change, better training, removing unnecessary customisation or simply making better use of functionality you’re already paying for.
Protect the capacity to improve
There is a vicious circle in all of this that I think deserves more attention.
As technical debt accumulates, more resource is required to keep the existing environment running. As more resource is consumed keeping things running, there is less capacity available to make improvements. And because fewer improvements are being made, more debt accumulates.
Eventually an organisation can find itself spending most of its energy maintaining yesterday while struggling to invest in tomorrow.
The obvious answer is to protect some capacity for continual improvement rather than waiting until enough problems accumulate to justify another large transformation programme.
This is perhaps one of the biggest lessons I take from maintaining a boat. You don’t normally wait ten years and then decide to do all the maintenance at once. You continually inspect, repair and improve things. Sometimes they’re small jobs. Occasionally they’re large ones. But the intention is to prevent all those small problems arriving at the same time.
There is a useful technology lesson in that.
Regular, relatively small interventions can prevent today’s irritating workaround from becoming tomorrow’s urgent replacement programme.
But even that isn’t enough, because managing technical debt doesn’t necessarily mean you’re managing value.
From technical debt to value debt
You could have supported software, current versions, excellent documentation and a technically sound environment and still not be getting enough value from it.
That’s why I think any review of technical debt should eventually move beyond the technology itself.
Ask what the investment was originally supposed to achieve. Is it still doing that? Have the needs of the business changed? What capabilities are you paying for but not using? Where have processes developed around limitations in the technology rather than the technology supporting the way you want the business to work?
Most importantly, ask what you would do if you were making the decision today.
If you didn’t already own this system, would you buy it again for the same reasons?
The answer doesn’t automatically tell you that something needs replacing. But it can provoke a very different conversation.
Perhaps the system itself is fine but the business needs to use it differently. Perhaps years of customisation could be simplified. Perhaps people need better training. Perhaps the business has acquired several tools doing overlapping jobs. Or perhaps the original investment really has reached the point where further spending on it is simply throwing good money after bad.
Those are business decisions, not IT decisions.
And that’s why I increasingly think that technical debt needs to be discussed in the context of value.
The useful boardroom question isn’t:
“How much technical debt do we have?”
It’s:
“Where is technical debt preventing us getting the value we should from the technology we’ve already paid for?”
Is your technology still earning its keep?
You don’t need a major technology review to begin answering that question.
I’d start with three much simpler ones:
- Which workaround would surprise a new starter if they found out about it?
- Which system do people use, but only because they have to?
- If you were buying it again today, would you choose it for the same reasons?
If you can’t answer one of those quickly, that’s worth knowing.
The underlying principle is simple. Technology isn’t a one-off investment whose value is fixed on the day it goes live. Like any other business asset, it needs attention if its value is to be maintained.
That doesn’t mean constantly buying new technology. In fact, quite the opposite. Sometimes the greatest opportunity is simply to get more from what you already have.
Perhaps that’s the real lesson from technical debt.
The objective isn’t to keep everything new. It isn’t even to make sure nothing ever breaks.
It’s to understand what you have, look after the things that matter, consciously accept the compromises that make commercial sense and keep asking whether your investment is still doing enough for the business.
On a yacht you learn fairly quickly that maintenance never really finishes. You inspect things, fix the problems that matter, improve things when you can and try to spot the next problem before it leaves you somewhere inconvenient.
Technology probably deserves much the same attention.
Because by the time something finally stops working, you’ve usually been accumulating the debt for quite a while.
