Digging Out From Technical Debt

Most of us are familiar with the concept of financial debt. It goes something like this:

1. We don’t have enough money to pay for things we need

2. So we borrow money

3. Now we owe interest on the money we borrowed

4. So we borrow more money

5. We have to pay more interest

6. And on and on

It’s a vicious cycle because we’re getting deeper and deeper in debt and the deeper we get, the harder it is to get out. Paying the debt keeps taking up larger and larger bits of our resources until we’re paying almost all we have just to keep up with the debt. 

Technical debt is quite similar. This year I have ten computers that I should replace with newer computers. The whole project will cost $15,000. I decide I don’t want to do it. Next year another five computers need to be replaced. That’s going to cost $7,500, but since I didn’t replace the ten last year, now I have $22,500 of “debt” I have to pay. The longer I put it off, the deeper in debt I get. 

The “interest” I pay on the debt is the money I have to put into maintaining all these old computers. Old technology breaks down more often. Old technology requires more maintenance. I might have to spend $5,000 just to keep the ten old computers working for that extra year. So now my total bill is up to $27,500 because $5,000 has been spent, in effect, paying interest on my debt.

Watch our webinar on technical debt to learn more!

But wait, there's less!

Financial debt can have all sorts of negative second and third order effects. 

Second order effect: Because I’m in financial debt, I can’t replace my old car. My car keeps breaking down and I have to borrow more money to repair it, getting deeper in debt and further away from having enough money for a reliable car. 

Third order effect: Because my car is so unreliable, I am constantly late for work. Eventually I am fired and have to find another job that’s further away and pays less. 

Technical debt can have similar second and third order effects.

Second order effect: Because our computers are so slow and unreliable, we have higher than usual staff turnover, creating additional costs in hiring and training new staff. 

Third order effect: One of our newly hired staff (who we were not able to train properly due to the increased turnover) opens a malicious attachment in a phishing email. Because their computer was not properly updated, the computer was vulnerable to the malware in the attachment. The combination resulted in our organization suffering a major data breach. 

The Vicious Cycle of Technical Debt

Technical debt, just like financial debt, creates a vicious cycle that gets harder and harder to escape.

1. You lack sufficient resources to do things to a high standard, so you continuously select the lowest-cost solutions, even if they are inadequate

2. Your inadequate technology & services results in various problems

3. You have to pay money to solve these problems created

4. Leaving with fewer resources to invest in better technology & services

5. So you implement low-cost solutions that are inadequate

And round and round we go, except it’s more like a downward spiral.

The terrific nonprofit consultancy, Fíonta, has an excellent article about technical debt that focuses on software and CRM. They included this terrific visual describing the vicious cycle of technical debt. 

Source: Taming the Beast: Managing Your Organization's Technical Debt - Fíonta

The Fíonta article is terrific and well worth a read, but limits its scope to the traditional use of the term “technical debt,” referring only to software projects. In this article we want to broaden the use of technical debt to the entirety of your organization’s technology, including your infrastructure, systems, personnel and services.

Top Ten Signs You Might be in Technical Debt

How do you know if you are in technical debt? If you are, you probably know, but here’s my top-ten list of common types of technical debt:

1. You still have a whole bunch of servers in your office

   • They are running Windows Server 2008

2. Your staff computers are, on average, over 5 years old

   • When your staff went work-from-home due to the pandemic, they started using their own personal computers for work

   • They are still using them

   • They are running Windows 7

3. No one is using multi-factor authentication - on anything

4. When your staff went work-from-home due to the pandemic, they had to connect to the office via VPN (virtual private network) in order to work

   • They still do

5. Your technology personnel haven’t received any professional training or obtained new certifications in over ten years

6. You have one or more business-critical applications that went end-of-life by the vendor years ago

7. Your project management platform is Microsoft Excel

   • Your project management platform is email

8. You still have a T1 circuit - for Internet

9. Your staff still use physical desk phones

10. Your primary means of sharing files is a file server that’s in your office

    • Your primary means of sharing files is email

Digging out of technical debt

The title of this article promised help with “digging out of technical” debt, so let’s get to it.

Dave Ramsey is a famous financial “guru” whose radio show, books and seminars have helped millions of people improve their financial situations (and helped make Ramsey a cool 200 million in the process). Ramsey preaches relentlessly about the value of getting out of debt. One of his most famous ideas is the “debt snowball” method, which is his advice for people who have multiple debts to pay off. The most common financial advice for people with multiple debts is to pay off the highest interest debt first, which makes mathematical sense. Ramsey’s debt snowball math instead suggests paying off the smallest debt first, to get rid of it. Then the next smallest debt, and so on, creating a “debt snowball” of momentum that gives people wins to celebrate which sustains and builds motivation.

I like the snowball idea for getting out of technical debt too, but I’ll put a slightly different spin on it. I’ll suggest you do a benefit/complexity exercise at your organization. You can do the whole thing in an hour or so if you plan well and get the right people at the table. For those of you working remotely, we have made a Google Jamboard you can use for a digital version of this exercise.

How to do a Benefit/Complexity Exercise

If you’d rather watch a video explainer on this - we’ve got one! Otherwise, read on. 

To do a benefit/complexity exercise, start by gathering a group of interested stakeholders from your organization as well as one or more trusted technology personnel (in-house staff or consultants). 

Brainstorm a list of 5-10 projects that would help you dig out of your different types of technical debt. These could be relatively simple projects such as workstation replacements or a wireless networking upgrade or they could be more complex projects like a cybersecurity assessment or a database migration. 

If you are fortunate enough to be in person, get some post-its and posterboard and make a grid that looks like this (colors optional):

Now make post-its of all the projects you brainstormed and stick them up next to the grid - like this. 

Now, start talking. Grab a project and talk about how much benefit it brings to your organization. How much does it really help? This can be tricky, since something that addresses risk, like a cybersecurity assessment, may not bring obvious benefit, but the potential reduction in risk might be quite meaningful. This is where having a range of stakeholders and perspectives is critical. 

Also talk about complexity - how difficult will this project be to complete successfully? Complexity can take the form of costs in dollars, costs in human resources, or change management or technical difficulty or many of these. The more expensive, difficult and disruptive a project is, the more complex it is. This is where having people with a broad range of technology knowledge can be especially helpful. Complexity of technology projects is not always easy to estimate. 

After talking things over for a while, hopefully you will all have been able to reach a consensus as to where the projects belong. It might look something like this: 

Now we have a plan we can work with. Our highest priority projects are the ones closest to the upper-left corner - the projects that provide the most benefit and are the easiest to do. Those are the first snowballs we’ll get rolling to get some momentum. Then we’ll head to the right and take on high benefit projects that are more challenging. 

If there is a project that has a lot of benefits (like replacing 20 workstations), we might try to break it down into smaller pieces we can start on right away. In this example, we’ve decided to replace five of the most critical aging workstations right away, and start planning on how we will manage to replace fifteen more before the end of the year. A first step that you could put in the “Do” box for a Salesforce migration project might be to draft a RFP for distribution. 

The Next Best Time is Today

I won’t pretend that digging your way out of years of technical debt is easy. It’s not. To borrow an old saying, the best time to have started reducing technical debt was years and years ago. 

But the next best time is today. Hopefully this article not only gives you the motivation to start, but a useful framework to do so. 

And if you’d like help reducing your technical debt, we are here for you.