You are currently viewing You Probably Have Technical Debt. Here’s What to Do About It.

You Probably Have Technical Debt. Here’s What to Do About It.

My colleague Oshri Cohen mentioned his views on a concept called technical debt in an article on LinkedIn a few years ago and reshared his thoughts in a recent post. I agree with his assessments and, in this article, I’d like to share some practical experience from my clients of how technical debt occurs and what to do about it.

In his article, Oshri makes the point that just like consumer debt (a house mortgage versus credit card debt), technical debt can be classified as good or bad depending on whether it moves the organization forward or backward. There are three key points Oshri makes about managing technical debt that are spot-on:

1. Pay down “bad” technical debt as much as possible. Bad technical debt is the debt that actively causes an issue – it causes work to be seriously stunted and leads to lots of wasted effort on manual or workaround processes.

2. Keep track of all technical debt. You wouldn’t willy-nilly borrow money from someone without keeping track, so keep track of your technical debt, too. One of the first things we do in a transformational engagement is figure out what are all the different pieces of technology in your stack and see where those things are.

For example, a manufacturing client we’re currently working with has an intellectual property management software that hasn’t been updated since 2014.   They’re about 6 iterations behind on the software, and that’s not a good place to be. I don’t suggest upgrading your software to the latest and greatest every year (it’s generally costly and unnecessary), but a two-year cadence is usually great unless a version comes out with killer functionality you’ve been wanting for a while.

Upgrading — like from their 2014 software to the current software – without the proper infrastructure in place and a well thought out plan for testing and implementation can be catastrophic. After going through their painful upgrade, one person at the organization wants to upgrade every year going forward. Their IT guy is balking, and I agree – both because they don’t have the proper infrastructure in place and because they won’t get a lot of bang for their buck. It’s better to upgrade every two years unless there’s something you really need. If so, you need to have the infrastructure and plan in place to do so.

In the case of yearly upgrades, it doesn’t make sense to pay down debt sooner than you need to. Figure out a cadence that works for you and your infrastructure.

3. Pay debt down regularly. Think: monthly credit card payments. Time-wise, we can think more in years than months but the principle stands. One of the first things we do in a transformational engagement is take stock of all the different pieces of software/technology out there, see where those pieces are at currently from a debt perspective, and figure out what needs to be upgraded first (and figure out order of operations for the rest).

I’m currently seeing a lot of folks on LinkedIn and CIO magazine talk about how Microsoft came out with Windows 11 and technical executives feel they don’t have to worry about it for two years. Conventional wisdom says don’t buy the first model of a brand new series of car because the bugs haven’t been worked out and the second year of the vehicle is usually better. Windows is no different – but that doesn’t mean you should never upgrade. Some places are just getting off Windows XP when Windows 10 has been around for 4 years, and that’s way too long. That becomes a security issue as the tech becomes more and more insecure.

Keep track of what version of software you’re on, what your upgrade path is, and what sort of testing you need to do in-house so that, when it comes time to migrate, people are ready.

The real hard work with technical debt

Remember the manufacturing company I mentioned above? They’re successful, small, and have under 50 employees. Through a series of decisions occurring over the past 30 years, the technology at that company hadn’t made the 5 or 10 year leaps it needed to make over those periods to be caught up. Some of the processes they had in place were still very similar to the ones used in the late ‘80s and early ‘90s when the company was originally formed.

In some cases, a lot of the old paper-based processes have been replicated through the use of copious amounts of manually typed excel sheets and creative use of Microsoft Access databases.

This sort of thing was common in the 1990s and early 2000s in businesses. When they wanted to scale, it was often a large transformational project to move off of manual, not-quite-paper-based-processes, and many companies in the early 2000s and 2010s spent significant capital to do this.

In many cases, a lot of small businesses didn’t necessarily have the operating capital or the technical leadership to make these transformations, so they never did. These businesses may have been successful in their niche and, because of that success, they didn’t feel the need to change.

But now as they’re starting to scale and build upon what they did successfully for years, they’re running into growing pains because their processes are painfully manual and prone to error. These processes are often overly complicated with a lot of manual steps required. There’s an initial documenting of processes that needs to happen to make the leaps in scalability and efficiency that are needed. And implementing the processes and getting them to stick? That’s where the real hard work comes in.

If you’re able to establish quick wins along the way by just tweaking existing processes, people can see the gains to be made and it’s easier to get them on board.

And listen, I know I wrote this article on why I f!cking hate lean but there’s a super important concept in lean that needs to be part of these processes: getting everyone involved and hearing everyone’s feedback.

The best way to do transformational change is hearing the pain from all the employees doing the work and documenting what their part of the process is so you can involve them when you’re making the transformational change.

They can tell you how to make it better, and you can give them options through technology so they can do better work, easier. Getting them on board is just as important as going through the process and implementing. Listen to your workforce to see what’s working well and what isn’t so you can a) fix it or b) work with that person until they’re comfortable with the new process. Often, it’s just a learning curve. People can change, it’s just a matter of how to manage that internally. Remember: your people will do better work if they feel comfortable and don’t feel like they’re screwing up all the time.

How we attack technical debt at StarSpring

Technical debt is super common on these engagements with small to medium-sized businesses that need help from a fractional CTO. I want any CEO from one of those businesses to understand you’re not alone. This is a common problem and it’s not necessarily anyone’s fault. Here are some ways we’ve attacked the problem and would attack it for your business if you decide you need our services:

  • Track all the different pieces of tech you’re using, see where they’re at, and decide what needs to be upgraded first.
  • Analyze and pay down debt that’s actively causing an issue.

Remember: technical debt isn’t your fault

Technical debt happens at businesses no matter what. Most people don’t keep track of their technical debt so the fact that you haven’t either is nothing to feel bad about. But it is something to start working on now.

On every engagement, we give you a plan that outlines how to attack the most high-value debt to pay down and what things can be saved until a little later. Whenever a business goes through a transformational change, technical debt is bound to be part of it and, if you engage StarSpring on a transformational change project, this will be one of the several exercises that occurs. So call us for fuck’s sake and let’s get you back on track!