Why Creating Tech Debt Is a Necessary Evil

Always building state-of-the-art solutions will cripple how you innovate.

Tech debt is something that used to drive me nuts. Developers pressured me to give them room to handle tech debt. They claimed everything could collapse if I didn’t listen to them. Meanwhile, demanding stakeholders wanted more output and didn’t understand why dealing with tech debt mattered; unfortunately, I didn’t understand it either.

Does this scenario ring a bell? No worries, you’re not alone, and there’s a way out of that once you learn what to do and what not to.

I used to hate the term tech debt. I got so tired of it that I wanted to avoid all discussions related to this topic. It took me a while, but I understood my ignorance was getting in the way of helping teams become value maximizers. 

There’s no better teacher than painful experiences. And that I faced a lot of those in my journey.

Today, I see many ways of dealing with tech debt, but most will piss off developers and create a worse problem: mistrust. But when you learn how and when to use tech debt, you have a higher chance of delivering value faster and avoiding investing in pointless initiatives.

By the end of this post, you will know why tech debt is a powerful tool when used wisely. I will also share approaches that don’t work and why you should avoid them. I hope you can benefit from these insights and apply them from here on out.

Screwing Up With Tech Debt

Maybe you invest 20% of Sprints into reducing tech debt or dedicate whole Sprints for it. Perhaps you ignore it and put all your energy into shipping new features. Teams make these common choices to handle tech debt, and that’s where a bigger problem is born.

Before I elaborate on why such approaches often fail, we should understand what causes tech debt and what’s that at all. The cause is usually simple—to speed up delivery of features by lowering code quality, e.g., scalability and maintainability. When Product Managers want to learn from real users, they push teams to create tech debt and address it later. What generally happens is that later becomes never, and the tech debt pile grows higher and higher, creating several side effects:

• Legacy Code: Only those who worked on the feature can extend it and fix issues. Others would take too long to understand the code or be against working on it.
• Low Motivation: Developers slowly get demotivated as the code quality deteriorates and feel powerless to change it. If nobody listens to them, sooner or later they will search for something else.
• Bugs: The more corners the team cuts, the more issues they will have. Bugs pop up, and the team gets busy fixing them and potentially worsening the tech debt situation.

Tech debt cannot be managed passively. It has to be done actively.

Teams struggle with tech debt when they react to issues instead of dealing with them proactively. Many developers write poor tech debt items and get angry with Product Managers when they refuse to get that into a Sprint. Don’t think that reporting an issue and putting it in your Product Backlog is enough to guarantee you will solve it later. 

Bad Tech Debt Description

The following examples will convince no Product Manager to prioritize them:

• Refactor recommendation engine
• Move feature X to NoSQL
• Rework on the Partner API

Good Tech Debt Description

If developers want tech debt to be addressed, they should help Product Managers understand the consequences of not doing them. For example:

• Scale recommendation engine: The current solution was built to support ten thousand products, and now the shop has fifteen thousand. That slows down recommendations and increases page load time by three seconds. The conversion rate is potentially endangered.
• Redesign Partner API: The partner API isn’t market standard. It was created a year ago and has not been touched since then. Partners take around a week to integrate with our platform, and this time could be reduced to a day with a simpler API that would allow partners to offer their products faster to our clients.

Storytelling is key to handling tech debt.

Mastering Tech Debt

Almost every team I know faces the dilemma of building it right from the beginning of hacking, vs. fixing it later. Both sides have advantages and disadvantages.

Considering the team invested proper time into finding a solution that solves a meaningful problem. With solid evidence, the team is ready to implement the feature, and you can take a waterfallish approach—build everything right from the beginning and release it to your audience. 

When you opt to build it right up front and luck is on your side, you will have a great solution and won’t even bother with tech debt. However, we all know that no plan survives contact with real users. Things will go wrong. When that happens, you’ll find that you may have invested too much upfront, and adapting your solution will be costly and slow. 

By building it right up front, you might not have to worry about tech debt, but you will find yourself with high losses when things go wrong.

You can use tech debt as a tool to validate your solution. Even with solid evidence, you can only be certain that something works when end-users benefit from it. Here is my approach:

1. Build to learn: Hack a solution as quickly as possible. The goal is to confirm that the solution is valuable to your audience.
2. Release to a small audience: Put your hacked solution live for a small percentage of your audience. Generally, a small part of your audience is enough to gain insights. Choose according to your customer base size. Keep in mind: the goal is learning.
3. Measure and decide: Based on your insights, evaluate whether the solution is prominent or not and decide on improving and scaling or killing the initiative.
4. Gradual release: Increase the reach as you gain confidence.
5. Pay off created debt: After you prove your solution creates the expected value, Work with your team to evaluate the investment required to make the solution sustainable. Do the math and decide whether you pay the debt or drop the initiative. You should not keep a poor solution alive—either do it right once you have enough confidence, or dismiss it. This is the most challenging part because you’ll always find something that will make it better. I recommend teams timebox their investment in comparison to the potential outcome. Be mindful and try to address what’s relevant and necessary. For example, don’t invest in supporting millions of users if you only have a couple of thousands. Scale gradually. I keep an 80/20 ratio: 20% of our time to create 80% of the result, while it’d cost 80% of the time to address the remaining 20%. Reflect on whether this investment is worthwhile. Balance is key to pay off the debt.

Whenever I present this approach to developers, they argue because they feel I’m trying to fool them. Their previous experiences don’t let them accept creating tech debt because they fear it will never be addressed once the expected business value is created. They are right. Most times, Product Managers jump to the next initiative once the result kicks in, though that’s not how you make a sustainable product. I do my best to gain their trust, and then it’s on me to walk the talk.

In my experience, the more you invest upfront, the more losses you face. This is obvious, but people ignore it. I encourage teams to be wise about tech debt. Remember: the goal is to create value faster and to do it, you must speed up your learning time. 

The weaker the evidence, the smaller the investment. Use tech debt as a tool to validate value instead of an issue that limits your product growth.

Final Thoughts

Collaboration is the best way to handle tech debt. I don’t think developers must beg Product Managers to prioritize tech debt issues. I believe everyone should have a single goal: improving people’s lives. When the goal is clear, you can evaluate how your actions contribute to it.

One of the biggest traps with building it right the first time is the illusion that everything will go as planned. More often than not, Murphy’s law is at work, and if something can go wrong, it will go wrong.

Don’t let a plan illude you. Work as a Venture Capitalist, increase your investment as the evidence strengthens, and stop investing when expected results become unachievable.

‍