Avoid Technical Debt Bankruptcy

October 22, 2024

Written by Mike Martin, Chief Strategy Officer


I am fortunate to have the opportunity to speak with a lot of IT executives. In those conversations, there is one topic that almost always shows up on their list of top concerns: technical debt.  

This consistent theme is not surprising. Technical debt – the accumulated liability of past technology investments and decisions – is a substantial burden. Industry analysts estimate that it consumes 20-40% of a large organization’s total IT budget. Technical debt is also an ultra-complex, multi-faceted problem, making it extremely difficult to manage. This is especially true in large enterprise IT, where the challenge is so vast and complex that it can feel almost entirely unsolvable. For that reason, it is not surprising that many IT leaders either choose to defer efforts to address technical debt or are unable to secure adequate budget for such a substantial challenge. 

Given the multi-layered complexity, talking about technical debt challenges at a summary level doesn’t accomplish much. Instead, we need to get detailed and specific, in both defining the problem and building a precise plan to attack it.  

Okay, sure – sounds good, right? But how?  

As it turns out, some debt management best practices from the world of personal finance can provide a useful framework to get us organized and on track to avoid technical debt bankruptcy.  


At a Glance: 

  • Technical debt is inevitable. However, a smart plan can indeed manage and mitigate it.  

  • Personal finance best practices can provide an organizing framework to help analyze core technical debt problems and create an action plan.

  • Start by defining the specific technical debt “accounts” in your portfolio.

  • Identify the “high interest” accounts that are creating the greatest cost or efficiency drag on your organization.

  • Select a specific “debt elimination strategy” that makes sense for your environment and align your work plans accordingly.

  • Keep score, demonstrate progress, and adjust as needed along the way. 


Technical Debt: How Did We Get Here? 

Technical debt is a term often discussed but rarely precisely defined. It is sometimes characterized as the byproduct of shortcuts or sub-optimal decisions, often made as a trade-off necessary to deliver a technology solution in an accelerated timeframe. These “kick the can” scenarios certainly do contribute to an organization’s technical debt. However, even the most thoughtful decisions or optimized technology investments will age over time and eventually require maintenance or updating. Therefore, in reality, technical debt is the accumulated liability resulting from all past technology decisions and investments. This is worth noting because it confirms that technical debt itself is fundamentally inevitable in your IT environment.  

Technical debt is also a general umbrella term, a convenient shorthand for a diverse variety of specific challenges and issues. Unique sources or types of technical debt include designs, software code, applications, testing frameworks, documentation, infrastructure, processes, configurations, integrations, security, and more. Each of these categories can contain multiple different issues or factors that create technical debt liability for the organization. 


Lessons Learned from Personal Finance
  

Since it is not possible to avoid technical debt entirely, every IT organization must have a plan to address it. However, technical debt is a complex, multi-faceted problem and as such, many organizations struggle to formulate a logical, organized game plan.  

We can seek guidance from the world of personal finance, where plenty of work has been done to help people organize and manage the burden of personal debt. Yes, aging IT infrastructure or legacy software code presents a different level of complexity than a home mortgage or a personal credit card. However, some of the guidelines and best practices from personal finance can be helpful to frame thinking and to provide a clear and straightforward approach to technical debt. 

For instance, one key personal finance principal is: “not all debt is created equal.” In fact, not all debt is inherently bad. Certain debt, such as a low interest, fixed-rate home mortgage, is quite healthy. Conversely, other types of debt, such as a high interest credit card, can be extremely expensive and if not managed properly, can lead to financial strain or ruin.  

The same is true with technical debt – it is not all created equal. Certain types of technical debt can be fairly benign, while others drive outsized cost and penalty to the organization.   

Defining Your Technical Debt “Accounts” 

 Albert Einstein once said:  

“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” 

How well do you truly understand your technical debt? Have you dedicated the time required to fully understand the underlying causes? Unfortunately, in trying to address technical debt, many organizations do the exact opposite of what Einstein suggests, spending too much time thinking about solutions without fully understanding or even defining the underlying problems. The result is typically a disjointed set of ad hoc initiatives that rarely resolve the technical debt challenges that are most burdensome to the organization. 

Put simply, we cannot afford to skip the deep problem analysis. One way to force this discipline is to define the specific technical debt “accounts” on your IT balance sheet. Review your current pain points, do the deep technical analysis to understand the underlying core issues, and define them precisely. Next, look for ways to group or categorize them. These categories represent the discrete technical debt “accounts” in your portfolio.  

With an initial set of technical debt accounts defined, you can drill down further by defining sub-accounts with a lower level of detail. For instance, an “outdated infrastructure” account might include “server” and “storage” sub-accounts. Or you may elect to use more specific sub-accounts, such as “Unix servers” and “SAN storage,” to more precisely define the source of technical debt in your environment. 

Identify Your “Bad Debt” Accounts 

Once you have clearly defined your various technical debt accounts, the next step is to confirm their size and determine the impact each one is having on your organization.  

First, what is the approximate size of each technical debt account? Specifically, try to estimate the “principal” balance – the investment needed to “pay it off” completely. 

Next, we want to determine the “interest rate” of our technical debt accounts. For each account, consider the different types of impacts it has on the organization. This could be in the form of financial cost (capital, operational, and/or labor), speed or agility limitation, degraded reliability, reputation risk, or any other factors that make sense for your business. For each of these adverse effects, do your best to quantify an estimated resulting cost to the organization (e.g., dollars per year). 

One of our main goals in this process is to identify the “high interest” accounts. These are your “bad debts,” driving the most expense and overall negative impact to your organization.  

To be clear, properly assessing the impact of technical debt is not a trivial exercise. The cost of some technical debt is fairly straightforward – for instance, an extended maintenance contract for a hardware or software product beyond the end of standard support. Other impacts are more challenging to quantify, but these can’t be ignored because they often drive substantial cost and disruption. For example, introducing a change to complex legacy middleware integrations may require outsized cost and delay, even when implementing relatively minor updates to an environment. The resulting, ongoing drag on an organization’s ability to deliver efficiently may present an extremely “high interest” cost in terms of excess labor effort, lost opportunity, and damaged reputation.  

Although the effort required can be significant, confirming both the size and impact of each technical debt account enables you to confidently locate your most concerning “bad debt” and make smart decisions on next steps for debt elimination.  

Choose a “Debt Elimination Strategy” That Works for You 

With a better understanding of your technical debt, it’s time to outline a plan for attacking it. Once again, we can learn from personal finance, reviewing proven, common strategies for eliminating household debt. For instance, common examples include: 

  • Debt Avalanche Method. This approach focuses on paying off the highest interest debt first. For many organizations, this is a logical strategy to apply to technical debt, since it focuses efforts on the most costly and painful technical debt accounts most quickly. However, if those “high interest” technical debt accounts are also the largest, it can take significant time and investment to see measurable results.  

  • Debt Snowball Method. This approach focuses on paying off the smallest debts first. This approach can make sense for technical debt when it is important to demonstrate immediate progress. Attacking the smaller technical debt accounts enables us to close them out and book some quick wins. Of course, the downside of this approach is prioritizing the smaller accounts allows larger “high interest” accounts to persist longer, extending the negative impact to the organization.  

There are many other debt elimination approaches that are relevant to consider for technical debt elimination strategies, including: debt consolidation, balance transfers, debt management plans, credit counseling, etc. While some may not be directly applicable, each has a degree of relevance that can be helpful in formulating and explaining your plan for attacking technical debt.  

There is no single strategy that will be ideal for everyone. Select the approach, or combination of approaches, that makes the most sense for your organization (supports your current environment, goals and priorities). What is most important is to conclusively select and state your strategy – it provides clarity to the organization on the specific approach you are pursuing and why.  

Once you have selected your strategy, ensure that your detailed work plans are aligned accordingly. A clearly stated strategy will help align efforts and prevent random, haphazard initiatives that don’t support your top priorities. As work progresses, track and measure the progress you are making in “paying down” your technical debt accounts and the associated benefits to the organization. Periodically revisit and review your technical debt account profile, and adjust plans as necessary as your environment, goals and priorities inevitably change over time. 


Suggested Next Steps   

As you consider your current efforts to manage and eliminate technical debt in your environment, these self-assessment questions can help identify appropriate next steps for your organization: 

  • How well do I understand the specific root causes of technical debt in my environment? Have I defined a set of technical debt “accounts” to organize the various types? 

  • How well do I understand the “interest” that each technical debt account imposes on my organization, in terms of financial cost, inefficiency, and/or risk? 

  • Do I know what my “highest interest” technical debt accounts are? 

  • Have I committed to a technical debt elimination strategy? Does it address my “highest interest” technical debt accounts? 

  • Am I tracking results and demonstrating progress eliminating technical debt? Am I clearly communicating the value that provides to the organization? 

If you answered “no” or “it’s not clear” to any of the above questions, you are not alone! Windval works with IT leaders to answer these questions and develop a game plan for technical debt that is tailored to the unique circumstances and needs of the organization, so they can start making immediate and meaningful progress. 

Technical debt is inevitable, but with a strong plan to define, understand, and address it, you can take control and avoid technical debt bankruptcy.  


Previous
Previous

Broadcom Acquisition of VMware – Know Your Risk

Next
Next

Beginning with the End in Mind: Thinking About a “Cloud Exit” Strategy