First, let’s review — what’s tech debt?
Essentially, tech debt is the off-balance sheet cost of reworking systems, processes and pieces of technology that can hold your organization back. Think of it like personal debt. If you have a significant amount of credit card debt that you're trying to pay down, it wouldn’t be advisable to spend a lot of money on something new. It’s a similar situation when you have a lot of tech debt — it impacts your ability to move forward with certain business and technology decisions. You can also think about tech debt as the cost of reworking a limited solution. Needing to rework a solution is often the result of taking intentional or unintentional shortcuts.
Many of us automatically think about tech debt as that “creep up” factor where we look around and realize that everything is old and we're going to have to upgrade to keep pace with modern business needs. But it's more than that. Sometimes it's incurred intentionally and can be leveraged in a positive way. Think of it again like personal financial debt. You can incur debt to get something you couldn't get without it. Sometimes rushed solutions that incur tech debt are necessary to address a certain need in the business or an opportunity in the market. For example, if the development team rushes writing code to launch a product faster, this creates tech debt because that code will need to be fixed or reworked down the line. However, the decision to write speedy code allows the product to launch faster, addressing the business’s immediate need.
Tech debt across the business
In a recent Insight survey on LinkedIn, we asked, “When you think about tech debt, what's your main area of concern?” The responses varied: 39% of respondents said licensing, 26% said hardware, 26% said software, and 8% said other.
It’s interesting that licensing took first place here. In recent years, licensing has become more complicated and more expensive. It used to be true that you would not make a technology choice based on licensing. But these days you don't get very far off the whiteboard before needing to bring licensing into the picture and to weigh decisions based on licensing costs. Tech debt from licensing could mean that you’re not licensing appropriately based on where you want to go or that you’re not getting the most value out of what you have licensed.
Although licensing topped the list in our survey results, hardware is probably the most used example when it comes to tech debt. When you’re in this industry long enough, you realize that everybody has that story about one dusty legacy server you can't turn off because you don't know what it does, but the last time you turned it off, everything stopped working. Plain and simple: That’s bad hardware tech debt.
We already touched on tech debt from software with my earlier example of a development team rushing code. Here’s another example: A business with thousands of end users will typically employ hundreds of different software applications. While some organizations have strategic vendor management teams focused on key suppliers, there may still be a large contingent of unmonitored and unmanaged software publishers that hardly ever come under strategic consideration. In this case, tech debt is created by the added security and compliance concerns linked to this unmonitored software.
How tech debt can thwart business goals
Many of my client conversations are about evaluating what their journey to the cloud would look like. Often, conversations around migrating to cloud will come up with clients because they are up against a renewal or a large capital expenditure. They say, "we're going to move these systems to the cloud,” or “we're going to move to Azure because we think it's a good fit." But then they dig deeper and start looking at the underlying systems attached to this decision. That's when they realize, oh, here's something that's been on the floor for 28 years. Nobody knows what it does. This forces them to hit the brakes on their migration project to deal with all these things that haven’t been patched, fixed or replaced in over 20 years. That’s why it’s critical to keep a running list of where you have tech debt, so you’re not caught off guard in the middle of a modernization effort.
Something else to consider — a lift and shift to the cloud without any real strategy to it is unlikely to relieve you of any tech debt. It’s more likely that you’d just be moving that tech debt somewhere else and perhaps even making it more expensive.
It’s worth the extra time and effort to carefully plan out these migrations. Figure out what must move and what can be left out. After all, if you migrate all your critical systems and all your junk, you’ll be spending valuable resources on low-value efforts. Think about it this way: When people move houses, they box up all their belongings, and then, when they get to the new house, they unbox the important stuff. If eight months go by and there are still unpacked boxes, clearly those boxes weren’t so important to move. I’m sure you’ve heard stories of people who move a completely unopened box a second and third time. Is that what you want to do with your business? Probably not.
Let’s talk about compartmentalization. Especially in a large organization, this is probably one of the biggest hurdles to overcoming tech debt in a profound way. This happens when organizations upgrade small components of a solution, but they're not completely getting rid of any tech debt because it's not the full solution that they're upgrading. In effect, you’re most likely just squeezing some tech debt out into another area. To stamp out tech debt, you need to look at the bigger picture and take a step back to consider the full solution.
Of course, there is a skill set aspect here that can’t be overlooked. Organizations will get an ingestion of technology, software, hardware, whatever that happens to be, and then expect operations to implement all this new tech perfectly, 100% accurate with all the bells and whistles enabled at the front end. The reality is you're likely to have some features that don't get fully implemented or things that might cause an outage, issue or some type of degradation. As a result, you may make a quick fix to “fix” something — but you never actually properly repair it, allowing that tech debt to grow and compound right under your nose. This is one reason why many organizations turn to strategic partners to support their modernization efforts, which I’ll discuss a bit more later in this blog.
One thing to keep in mind is that you’re always going to have tech debt to some degree, just like you're always going to have a bottleneck. You're always going to have that component that is the slowest part of your system. For example, ERP systems are often like tech debt juggernauts because while other parts of an organization’s environment might be able to move rapidly, these typically do not.
The best way to start off managing tech debt is simply by keeping track. Every time you buy something for your IT environment, you're basically committing to a certain amount of time that you're going to leverage it. Keep a list of your systems and where they are in their lifecycle. Think of this as your tech debt roadmap: Awareness of what you have, what needs updating now and what will need updating later is one of the best ways to safeguard against running into bumps in the road with tech debt down the line.
Knowing how to skillfully approach tech debt takes expertise and practice. But the reality is that some organizations simply lack the internal strategic and/or technical resources needed to effectively address tech debt. Leaning on an expert partner like Insight for tech debt mitigation not only covers those gaps but can help free up internal resources so teams can get back to focusing on innovation. A strategic partner like Insight can assess and understand your current environments, priorities and business goals to remediate tech debt and optimize spend.
Success story: See how we helped this veterinary firm plan a strategic modernization to address tech debt across 900+ locations and refocus on transformation.
