Managing Tech Debt

Tech Debt is an IT concept that describes the long-term cost of work that has been deferred or scope has been reduced. The work reduction usually reduces the overall effort so that the team can achieve an earlier delivery date. Sometimes the work is deferred until a future release and the business can limp along. Other times, the work is completely skipped and the business can go on with a less efficient solution by manually working around it. Just like financial debt, the business pays interest on the tech debt with the costs of working around the feature. And at some point, the tech debt has to be paid off when the feature is added or the system is replaced.

Most people are very familiar with financial debt. Financial debt (just like tech debt) can be used wisely and poorly. Buying a house with a mortgage can be a great use of debt. Buying a car with a loan and investing the money into a mutual fund can be a great solution for achieving a higher return on the investment. Paying for a car repair with a credit card is a good use of debt. Paying for a vacation or buying a new phone with a loan is probably a poor choice of using debt effectively.

People are educated about financial debt. They don’t always make the best decision but there is training and ways to talk about new debt. There are people who can help advise on taking on new debts. There are people who can help you get out of debt. When we start talking about tech debt, there seems to be a lot less discussion around it and definitely less educational resources. There are three areas that must be looked at in the same way as financial debt.

• Rationalizing when to take on tech debt

• Maintaining a balance sheet of tech debt

• Actively reducing tech debt

The strongest IT companies will manage their tech debt. We all have had projects where scope has to be deferred. Sometimes solutions need to go live to meet a mandatory date due to legal or compliance. Sometimes projects need to go live to take advantage of a market opportunity. Other times, the new solution is better than what is already in place. But sometimes, we move ahead just to meet a project date. Tech debt is necessary. It just has to be managed.

Understanding the reason to take on debt is really important. When I am looking at taking on new tech debt, I always want to make sure I understand the debt. I always go through a list of questions to make sure that I am making a wise decision. Some of the questions that I like to make sure that I can answer are:

• What does the debt allow you to achieve?

• How are you going to measure the benefit of the debt?

• How much are you saving compared to paying upfront?

• What is the interest rate of the debt? Is there a loss of efficiency? Is it going to be more expensive to fix later?

• What is your ability to service the debt? Does this debt prohibit you from meeting your commitments?

• Does the debt prevent you from achieving other goals? Does it limit you to deal with future surprises?

• Are you going to pay off the debt? Are you going to work it into plans? What happens if you are forced to fix it by compliance or legal?

I just completed a recent refinance of our house. During the process, there is a section on the application where all the debts get listed. It does a great job showing on a single page all of the financial debts that you owe. How many application teams keep a record of all the tech debt being accumulated by the application? Not many. I often see Information Security Offices maintaining a list of exceptions for an application. But I have rarely seen an inventory of deferred functionality. I think every system needs to keep a list of deferred scope. The inventory provides 3 key benefits:

1. Keeps a record of decisions and the reasons for the decision

2. Helps identify when the debt is greater than the benefit of the application

3. Provides a great set of requirements for a replacement system

Early on in my career, my wife and I set a goal of paying off all of our debt. We came up with a plan and actively worked on paying off a car loan and student loans. We worked really hard on cleaning up our debts and over a couple of years, we succeeded. Likewise, companies need to work on paying off their tech debt. Every release should try to address some the technical debt. Sometimes the feature that was earlier deferred is the release. This is really common in an agile process. Other times, the work just needs to get done. No one likes paying off debt but it is an important part of maintaining the system.

I was recently talking with a company about their application portfolio. They were modernizing one of their key platforms. The debt with their old systems had grown over time so that the system could no longer meet the need of the business. One of the managers said it was great because they could start fresh and they were able to get rid of all their debt.

One manager said that they were struggling to map all their work arounds that became part of their business process into the new system and they were sacrificing the benefits of the new system. The second manager had a more accurate assessment of the effect of the tech debt and realized the debts were only being transferred to the new application. Debt doesn’t disappear without working on it. Problems have to be resolved. Just switching platforms doesn’t solve all the problems of past.

Those problems have to resolved so you don’t recreate the same set of problems again. In the 2000s, many people would go into debt and refinance their debts into the homes. It was great. Debts were instantly solved. But the problems and behaviors that got you into debt in the first place were still there. And the process would repeat until the 2008 recession hit and it all came back to haunt them when the real estate market crashed. Switching to a new system is pretty similar. The new platform may make it easier and cheaper to service the debt, but without actual change, the new system will run into the same set of problems.

We as IT and business leaders need to be responsible about our debts. We need to make better decisions around when we should take on debt and eliminate debt. Debt isn’t bad. But it has to be managed or it will manage you. Tech Debt needs to be a regular discussion at the program level. It shouldn’t be forgotten but actively managed.