What if you had no idea how much debt you had? It would be an uncomfortable position to be in, not knowing how much it was costing, or to what degree it was preventing your company from making operational improvements. And what if anyone in your organisation could rack up debt without approval?
This is what happens with technical debt. It might sound like bad governance, but it’s actually quite common in businesses. This kind of “debt” does not come in the form of the traditional financial approval processes that we’re more familiar with. Instead, it has a more stealthy approach.
Technical debt is like financial debt – it can be good or bad
Originally a term coined in the programming community, technical debt has become useful in considering the strategic and cost implications of technology decisions.
In simple terms:
Technical debt is the cost and loss of agility to your company because of earlier decisions to save time or money when implementing new systems or maintaining existing ones.
It occurs when systems aren’t integrated correctly, or code is complex and difficult to maintain. A variety of factors might be behind these decisions such as inefficiencies, time to market considerations or running outdated versions of software.
How is technical debt incurred?
When financial debt is incurred, a formal approval process and sign-off usually happens. However, technical debt is stealthier, and it usually occurs in one of two scenarios:
Time constraints that lead to compromises
Time to “go live” is everything, and implementing new technology is faster when it can be done on a stand-alone basis. Unfortunately, this means that other systems are not fully synchronised with the implementation. Nowhere is the impact felt more than in implementing ERP systems which, by their nature, are complex and mission-critical.
Technology that isn’t properly integrated results in business processes that don’t work together and multiple versions of the truth. And the longer a problem is left unresolved, the higher the ultimate magnitude of the effect.
The temptation of short-term cost savings
Delaying software updates – Sometimes the cost and effort of implementing a software update can result in it being delayed. And sometimes this goes on for years. We’re all guilty of disabling Microsoft AutoUpdate when it appears at inconvenient times.
Also, when systems end up being well behind their current version, newer software that must integrate with it… simply cannot.
Delaying hardware replacement – As businesses grow in complexity, the sheer effort of synchronising hardware update cycles can become overwhelming and costly. This results in hardware being stretched to the extreme, with implications for productivity and hardware/file compatibility between systems.
The real costs of technical debt
The cash costs are very real, and there are also important soft costs.
Cash costs
Headcount
- More staff needed to maintain existing systems
- More development time for new capabilities
Overheads
- Delayed realisation of acquisition (M&A) synergies
- Remediation costs or fines resulting from security breaches
- Sales
- Lost sales due to system outages or inability to properly service customers
Working capital
- Increased requirements, particularly for businesses with high inventory
Soft costs
Market intelligence and insight
- Inability to adapt quickly to opportunities or changes in the market
- Reduced ability to convert data into information to make better decisions
- Multiple versions of the truth
Productivity
- Lower staff productivity due to systems outages
- Less productive staff who spend more time extracting and fixing data than using it
- Derailing senior management’s time and attention if a major security breach occurs
Strategies for handling technical debt
Step 1 – Assess how much technical debt you have
Don’t over-complicate this process. At some point, you are going to want to get to a top-to-bottom assessment, but you don’t have to start there.
Start with your mission-critical systems. What technical debt do they have? Then look at the wider system—what technical debt between your systems is causing expenses?
Get your top 10 and put them into a 2×2 matrix: easy/hard to pay off on one axis and degree of benefits on the other. Then drill in to test your assumptions about the size of the prize and the effort.
Step 2 – Decide what to do
You could “Leave it as is” — For some debt that is considered to be “small” or with a “low interest rate,” it might be okay to just leave it. There could also be advantages to this approach. Being one version behind with Windows is usually fine and sometimes has the advantage of getting the bugs in the initial releases worked out before they hit you.
You could “Pay it off” — Paying back or reducing technical debt can involve replacing systems and taking the cost hit. This can be done immediately or over time through a process of gradual improvements. As with financial debt, there are creative ways in which you can “refinance” technical debt with outsourcing the maintenance being one approach.
Conclusion
Don’t get overwhelmed by the cost of reducing your technical debt when considering your options, and don’t try to pay it off all at once. This would be an ambitious exercise that could overwhelm an organisation of any size.
In finance terms, debt can be good when it is used to fund investments that will provide a greater return than the cost of the debt. But debt is bad when it becomes an expense that drags down cash and profits and limits flexibility. Tech debt must be measured and managed in a similar fashion.
If it allows your company to get to the market ahead of the competition, it is very likely worth it. And taking on tech debt to mitigate a potentially serious security vulnerability is probably worth it too.
But if you delay an upgrade several times to hit your short-term financial targets then technical debt becomes ugly, leading to business inefficiency and inertia.
