What Is Technical Debt?
- Technical debt is defined as: the incremental cost and loss of agility to a company as a result of prior decisions that were made to save time or money when implementing new systems or maintaining existing ones.
- An example would be having an ERP system that is in a vicious circle of being so old and customized that it can't be upgraded, as it would be a messy "rip and replace" effort.
- Unlike a "bug," technical debt is not a visible defect and, thus, may not be detected so easily.
- Financial debt is a term that CFOs are well versed in, yet technical debt can have similarly crippling consequences due to the hidden loss of sales and costs that it can incur.
Why Does Technical Debt Occur?
- Often, the first step toward technical debt is a time constraint that leads to a compromise being taken. This can often be forgotten.
- The temptation to save costs also can result in a tech debt situation. This is often related to forgoing software updates or over-extending hardware replacement cycles.
How Can You Address a Current Technical Debt Problem?
- As with financial debt, in order to manage your technical debt liabilities, you first need to know what they are, how much they are, and their payment terms.
- To initially figure out what debt you have, brainstorm with your stakeholders what current issues exist and how the year would have played out better if they were all fixed.
- Use a 2x2 matrix that can assess the ease of resolution versus the potential impact it would have. This allows you to focus on the high-impact projects first.
- Deciding what to then do can take many forms. The debt can either be ignored or paid off, but then the middle ground would be outsourcing the resolution either to a specialist organization or using cloud services.
- Creating a payment plan allows you to look at the cash flow implications of the various scenarios that you are facing. This will assist budgeting and visualizing the trade-offs that exist.
What Steps Can You Take to Mitigate Technical Debt Going Forward?
- A loan disclosure statement is a popular tool used to manage and set standards for financial debt. Implementing similar processes for technology projects can be a first step to increasing awareness of technical debt.
- Working with the IT team to set thresholds of acceptable levels of debt will also provide them with the necessary boundaries within which to operate.
- Coordinating with and introducing the change management team into new technology projects earlier will ensure that changes and issues are communicated quicker and more clearly to the organization.
What if you had no idea how much debt you had? It would be an uncomfortable position to be in, to not know how much it was costing or to what degree it was preventing your company from making operational improvements, reacting to market changes, or even transforming the business completely.
Moreover, what if just about anyone in your organization could incur debt without seeking permission? For example, your head of real estate could quickly enter into a multi-year lease with a low year-one rent but with significantly escalating rents in the out-years—without anyone disclosing it other than conversationally.
This all sounds like imprudent governance, but it’s actually quite common in businesses. The catch is that this kind of “debt” does not come in the form of the traditional financial instruments that we all know so well.
Technical debt has all of these characteristics.
Debt in its simplest form is borrowing today with the intent and promise to repay in the future. Debt makes sense when today’s borrowing will lead to a better tomorrow, e.g., borrowing for college or buying a house. Debt is generally bad when borrowing today will lead to a worse tomorrow, e.g., going out for an expensive dinner and putting it on a credit card that you won’t immediately pay off.
In corporate terms, debt can be good when it is incurred to fund investments that will provide a greater return than the cost of the debt. It may also make sense if you plan on selling the business long before the debt is due. The downside of debt is that it has a very real expense that drags cash and profits, restricts flexibility, and can become so burdensome that it could ultimately lead to bankruptcy.
Up to now, the metaphor that we are alluding to is about financial debt, yet another form of debt—technical debt (or “tech debt”)—has many similar characteristics and must be measured, managed, and entered into in a deliberate fashion. If it allows your company to get to the market ahead of the competition, it very likely is worth it. Similarly, taking on tech debt to mitigate a potentially serious security vulnerability is probably worth it too.
However, technical debt has its downsides, leading to inefficiency and inertia—such as when one department doesn’t want to use another’s software, or if you delay an upgrade several times to hit short-term financial targets.
So, What Is Technical Debt?
Technical debt is a term that has been used primarily within the technical community since Ward Cunningham, a computer programmer, coined the phrase in 1992. Its usage has taken off recently and taken center stage with the proliferation of agile programming. The technical debt discussed in this article is not about programming methodology but rather the strategic implications of its existence.
In simple terms, technical debt is the incremental cost and loss of agility to your company as a result of prior decisions that were made to save time or money when implementing new systems or maintaining existing ones. It occurs when systems aren’t integrated correctly or code is overly complex. This is due to a variety of reasons, such as inefficiencies, time to market considerations, or running outdated versions of software, amongst many others.
Some clear examples would be:
- Using old versions of Windows that prevent you from using new software or applying a security upgrade
- ERP systems in a vicious circle of being so old and customized they can’t be upgraded, as it would be a “rip and replace” effort
- Similar systems that have overlapping functions in different parts of your organization
The diagram below is a useful graphic for framing how tech debt differs from other technological implementations that can be made within a company’s tech stack. Often mistaken for being a bug, technical debt is far different in that its presence might not be blatantly obvious. Therein lies the danger, as the longer it is left untouched, the higher the magnitude of effect will be in the future.
As a CFO who has both worked within IT and had IT report to me in highly-leveraged enterprise companies, it struck me how similar technical debt is to traditional debt. It also struck me by how opaque and risky it is. Those from a financial background are well-versed in the mechanisms of financial debt—it’s tangible and easy to calculate. Yet not so for technical debt, which is often misunderstood or mistakenly assumed to be someone else’s problem.
What Exactly Are the Costs of Technical Debt and Are They Real?
The short answer is that the cash costs are very real. There are also some important soft costs that should be identified as well as separately measured and managed. I will elaborate below on some examples of these costs:
Technical debt is as real as interest payments. However, it usually manifests itself on the P&L in a more indirect way than a simple “interest” line expense, such as in the following ways:
- More personnel needed simply to maintain existing systems
- Additional developer time to bring about new capabilities
- Delayed realization of acquisition integration synergies
- Remediation and fines emanating from security breaches
- Lost sales due to system outages
- Less efficient marketing spend
- Increased requirements, particularly for businesses with high inventory balances
While hard costs have actual dollar amounts associated with them, there are also soft costs which, despite being harder to quantify and realize savings on, have an absolute drag on your business results. These include:
- Inability to quickly adapt to opportunities or changes in the market
- Reduced ability to convert data into information to make better decisions
- Multiple versions of the truth
- Lower staff productivity due to systems outages
- Less productive staff who spend more time extracting and massaging data than analyzing it
- Derailing senior management’s time and attention if a major security breach occurs
Looking at a comparison of technical and financial debt, one of the key differences is that the former has no formal control. With financial debt, there are usually credit committees, asset and liability management teams, and treasury staff that monitor levels like a hawk. With technical debt, however, very few of these controls exist in traditional businesses.
How and Why Technical Debt Is Incurred
With traditional debt, the board, along with the CEO and CFO, typically set the capital structure, i.e., how much equity, how much debt, and what type of debt (revolver, asset-based, or vanilla unsecured). The cap table is even explicit as to what debt will be paid off and when. Once this is all formally decided, a structured process is launched to raise the debt.
Lenders look at an entity’s capacity to pay back debt via assessments of the history of paying back debt, credit ratings, and the quality of collateral backing it up. Yet, none of this formal process, quantification, and sign-off happens when technical debt is incurred. Let’s take a look at how and why this is through the processes in which technical debt is incurred:
Time Constraints Lead to Compromise
Time to market is everything in business. Implementing new technology is much faster to do when it can be done on a stand-alone basis. Unfortunately, the implications of this are that other systems are not synchronized with the implementation. For lean organizations with a simple tech stack, this may not seem that bad.
It becomes problematic, though, as system configurations multiply in their complexity. In the end, technology automates processes and captures data that gets transformed into information. Technology that isn’t integrated results in business processes that don’t work together and multiple versions of the truth.
When time is sacrificed for speed, established testing protocols can be ignored or given a waiver. This usually results in “bugs” down the road that manifest themselves into some form of system degradation and distraction of developer time to fix them.
If we look at the effect of tech debt over time, the longer an issue is left untouched, the higher the magnitude of the effect. What starts as a small code refactoring exercise can snowball into an entire modernization and replacement effort down the line.
The Temptation of Short-term Cost Savings
Let’s face it—executive teams are under constant pressure to hit the numbers. Holding off on spend today can help you to make the quarter but, like borrowing, you have to pay it back at some point. Here are some ways that companies save money in the short term but end up resulting in technical debt:
At times, the cost and trouble of implementing a periodic software update can result in it being delayed. Sometimes, this goes on for years. We’re all guilty of force-quitting Microsoft AutoUpdate when it appears at inconvenient times.
When systems end up being well behind their current version, newer software that has to integrate with it simply cannot. What’s more, upgrading several versions at once is usually more expensive and almost always more time consuming than keeping up.
As organizations grow in complexity, the sheer effort of synchronizing hardware update cycles can become overwhelming and costly. This can result in current hardware being stretched to the extreme and large disparities existing between the quality of hardware amongst teams. Some teams get frustrated, buy new hardware, and just expense it through their desk budget instead of waiting for IT to instigate the upgrades.
This disparity has implications for productivity and hardware/file compatibility for collaborative exercises.
Tactics for Addressing a Technical Debt Situation
Instead of just talking about problems, let’s now apply some proactivity and prescribe some solutions for resolving technical debt.
For that, we can call upon the techniques used to manage financial debt. In order to manage your liabilities, you first need to know what they are, how much they are, and their payment terms. Let’s now work through this for technical debt.
1. Figure Out What and How Much Technical Debt You Have
Financial debt comes in tranches which are defined by the seniority of each piece (e.g., senior, mezzanine, or revolver), which in turn shows which gets paid back first. Technical debt has a similar pattern of seniority; to begin with, you must start with your mission-critical systems. What technical debt do they have? Then look at the wider ecosystem—better put, what technical debt between your systems is causing expense?
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. Have your head of IT pull your management team together with this homework:
If we had completely cleared up all of our technical debt a year ago, how might this year (or this coming year) have played out better?
Get your top ten ideas and put them into a 2x2 matrix: easy/hard to pay down on one axis and degree of benefits on the other. Hopefully the visual will help you figure out where to start.
|Benefits of Resolving ►||Strong|
|▲ Effort to Pay Down|
From there, drill in to validate your assumptions about size of the prize and effort. Neutrality is key here, so be wary of software vendors that offer to conduct a “free assessment.”
2. Decide What to Do
Once you know what technical debt you have, you now need to decide how to deal with it. There are many options to take.
It may ultimately be best to do nothing. For debt that is either assessed to be “small” or with a “low interest rate,” it may be optimal to just leave it—likewise, if there is significant “prepayment penalty” of paying it off early. There could also be strategic advantages too. Being one version behind and staying there is usually fine and sometimes has the advantage of letting kinks get worked out on someone else’s dime.
Paying back or reducing technical debt will involve replacing systems and taking the cost hit. This can either 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 such way. This ultimately may cost more to resolve, yet can be spread out to lower the immediate cost hit and, through the principles of the division of labor, delegates the task to a more specialized entity.
The advent of cloud-based software and hardware services also brings in a comparison to the popularity of lease-based finance. Using cloud services is also an effective tool for reducing technical debt, both in removing CAPEX requirements and shifting the development focus onto the cloud provider.
3. Create a Payment Plan
Don’t get overwhelmed by the cost of reducing your technical debt and don’t try to pay it off all at once. This would be an ambitious exercise that could overwhelm an organization of any size or balance sheet.
Again, going back to the financial comparisons, have a mentality of paying off the credit card with the highest interest rate first. This simply means attacking high value/low effort activities first.
In the previous section, I discussed the various ways of tackling technical debt. When assessing the cost of each, it’s best to undertake a comparison exercise. Ranking the cash flow cost of each potential outcome can enable the stakeholders to have a clear view of the trade-offs and benefits of each path. An example of such a visual is included below.
This comparison shows the trade-off that exists between a theoretical resolution and the stark contrast between resolving the problem and doing nothing (“existing baseline”). In this example, moving to a cloud, SaaS-based solution would be the most economical option for the business to take.
Managing Technical Debt Going Forward
Once you’ve established your baseline and plan of attack, you are going to want to both preserve that visibility and prevent new debt from creeping in. Think of the exercise as a fresh start and a chance to implement best practices to prevent issues from ever escalating again in the future.
Implement a Loan Disclosure Statement
Most technology projects have a formal approval process complete with an executive sponsor, high-level objective, anticipated benefits, schedule, and of course, costs. This is a great place to flush out new technical debt that will be incurred and the justification of it.
Set Borrowing Thresholds
Don’t go too overzealous with setting new standards. Just as you issue corporate credit cards with preset limits, you don’t want to over-manage technical debt. A lot of technical debt is small and related to code writing that will quickly be paid off. This is particularly true with agile development. Trust your head of IT to set and monitor this threshold.
Re-Train Your Underwriters
In bigger companies, IT has a process called “change management.” Before new software goes live, it typically goes through change management. In simple terms, change management’s job is to ensure that new changes to the company’s technology system don’t impact other systems. They do this by ensuring that the new system complies with standardized methods and procedures. Consider using this process to prevent or at least identify new debt from being introduced.
Technical debt is a real cost of doing business and a real cause of systems outages and drag on overall company agility. It does not have to be an ongoing burden, though, and smart CFOs will know how much tech debt their organization has and what it will take to optimize it.
Understanding the basics
Hard costs represent tangible expense incurred on the income statement. These could include headcount, rent, and material. Soft costs are intangible costs that are not directly expensed, relating to trade-offs and opportunity costs that exist—for example, labor working longer hours due to suboptimal equipment.