Don't let Technical Debt sabotage your product roadmap - Part 2

Introduction

In the first part of this blog series, we explored the hidden costs of technical debt, revealing its impact on development teams, businesses, and customers. We saw how low code quality leads to slower development, increased defects, and unpredictable delivery timelines, ultimately hindering innovation and jeopardizing product roadmaps. We also discussed the ripple effects of technical debt, causing customer dissatisfaction, missed business opportunities, and decreased employee morale. The alarming statistics from research by CodeScene and Stripe further underscored the urgency of addressing technical debt, with developer inefficiency leading to a staggering $300 billion annual loss in global GDP and unplanned work consuming 23-42% of developer time.

In this second part, we shift our focus from identifying the problem to solving it. We will explore approaches to build a compelling business case for refactoring, empowering you to convince your management that investing in code quality is not just a technical necessity but a strategic business imperative. We'll cover key components of such a business case, including quantifying the impact of technical debt, translating technical jargon into the language of business, and addressing common objections to refactoring.

Let's resist the urge to immediately open our IDE and engage in random refactoring, only to succumb to pressure and return to feature development after a few hours. Instead, let's take a different approach to secure management buy-in this time.

Step-by-step towards a compelling business case to get rid of your technical debt

The goal isn't just to refactor for cleaner code; it's about strategically aligning your technical efforts with your business objectives. In an ideal world, the decision to increase technical debt would be consciously aligned with a clear plan on how and when to pay it back. We see similarities in financial markets: you don't get a loan (financial debt) for real estate without negotiating the conditions for repayment. In practice, we're not quite there yet in software engineering and product development.

Unlike the fixed terms of financial obligations when buying real estate or an expensive car, software development, and business models are in constant flux. Hence, it's crucial to take extra steps and build a compelling business case that resonates with your management and paves the way for a healthier, more productive codebase given your product's and business's current situation.

Step 1: Understand your current business goals

Why can't we just start refactoring? Shouldn't this be self-evident within a modern IT company? Perhaps it should be, but every company needs to decide how and where to invest their time and your precious skills as an engineer to achieve business goals. Here, you face a constant conflict balancing short-term ROI by implementing new features against long-term ROI by modernizing or cleaning up your code.

I once described it to a team this way, asking one of the engineers:

Imagine you are our CEO and you have 100$ to spend making our business more successful. How would you decide?

The answer was - and now we are talking:

I would decide based on value for my company.

What constitutes value for your company? Where does your company want to go in the next two or three years? What are the key business goals that your software is supposed to support? Is it about increasing revenue, improving customer satisfaction, or entering new markets?

It's crucial to understand the bigger picture – your company's strategic objectives – to create a solid argument for how to invest your $100. The scope of reducing technical debt heavily depends on what your business wants to achieve today and in the future. Keep in mind that markets, customers, customer problems, and markets change constantly – so too must the foundation and argumentation for reducing technical debt (as with building features) be evaluated continuously.

Step 2: Quantify the current impact of technical debt

To build a compelling business case, you need to quantify the current impact of technical debt on your organization.

An anti-pattern in quantifying the current impact is abstracting too much information. If you simply argue, "Our app is too slow, we have to make it faster," your business case lacks a solid foundation. Put yourself again in the shoes of your CEO. Would this information be enough to justify investing your current budget of $100? You could do this, of course, but the risk is high that you'll never see a return on that investment.

Your initiative to reduce technical debt will always compete with product enhancements. To increase your chances of winning this competition, I encourage you to shift gears and bring your argumentation to the same level as business stakeholders (ideally) use to convince management to invest in product enhancements. Gathering data and using it to demonstrate the tangible costs of inaction will help you put your refactoring on the product roadmap. The kind of data you need to collect and analyze highly depends on what you want to achieve or the current areas of improvement you see. Here are some examples:

• Measuring Unplanned Work: Start by tracking the amount of time your team spends on unplanned work, such as bug fixes, hotfixes, and firefighting. Tools like Jira can help you gather this data. The "Accelerate" research suggests that a baseline of 15% unplanned work is a good target for high-performing organizations. If your team is spending significantly more time on unplanned work, it's a clear sign that technical debt is taking a toll.

• Calculating the Cost of Delay: Estimate the financial impact of delayed features or missed opportunities due to technical debt. This could involve calculating the potential revenue loss from a delayed product launch or the cost of losing customers to competitors due to slow feature development.

• Calculating the Cost of Failure: Issues with outages, scalability, or efficiency come with a cost. What is the potential revenue loss when your product discovery page is not responding or a response takes more than 3 seconds? What is your loss of engagement if teaser images can't be rendered in time?

• Assessing the Opportunity Cost: Consider the potential value of new features or products that your team could be developing if they weren't bogged down in managing technical debt. This can be a powerful way to illustrate the missed opportunities caused by technical debt.

This is your chance to anticipate and counter common arguments against investing in refactoring, such as "We can't afford it" or "It's not a priority." Use data and real-world examples to demonstrate the long-term benefits of addressing technical debt. Highlight the potential cost of inaction, including lost revenue, decreased market share, and employee attrition.

Step 3: Pitch your initiative using the language of your Business

Once you have a clear understanding of the business goals, you can start to align your refactoring efforts with them. Instead of arguing that your current solution does not follow SOLID or clean code principles, is poorly modularized, or is tightly coupled, show how reducing technical debt can directly contribute to achieving business goals. Some examples:

• Faster time-to-market: By streamlining your development process and reducing the time spent on bug fixes and unplanned work, we can deliver new features and products to market faster, gaining a competitive edge. We expect that this will bring us 100,000 more users per month, worth $20 million per year in additional revenue.

• Improved customer satisfaction: By eliminating bugs and performance issues, we enhance the user experience and increase customer loyalty. This could improve retention by 5% and reduce customer churn by 25%.

• Increased innovation: By freeing up our developers from the burden of maintaining legacy code, we can empower them to explore new technologies and develop innovative solutions that drive business growth. This will remove current constraints and bottlenecks, making product features possible that were previously impossible to implement.

As you know your business and your company best, you can be as concrete here as possible. Try to inspire your management by showing them the potential for the business that lies beneath the surface of your refactoring efforts. When presenting your case for refactoring to management, it's essential to speak the language of business. Avoid technical jargon and focus on the business implications of technical debt. Highlight the potential cost savings, revenue opportunities, and risk mitigation that refactoring can bring.

Trust me, this is how you get your management to listen, increasing the chance of getting strong buy-in from your management.

Step 4: Prioritize and measure progress and results

Congratulations! You've achieved buy-in from your management, and your technical refactoring is part of the roadmap for the upcoming two quarters. Now it's up to you to deliver measurable results. Measure and monitor the impact of your effort on unplanned work, customer satisfaction, or time-to-market of new features.

Depending on your argumentation and current situation, you might have several areas of improvement in mind. Prioritize the most critical areas of technical debt based on their impact on business goals and consider refactoring as an incremental and iterative process. It's unlikely that your initiatives to reduce technical debt will be the only item on your roadmap. Find a way to balance ongoing feature development while doing your refactoring.

I've seen teams implementing a mechanism I call "Technical Debt Rotation." On regular iterations, one engineer of the team will work on reducing technical debt while the others continue with feature development. After two iterations, they change roles within the team so that knowledge is shared. Other approaches focus on allocating defined time for all engineers to pay back technical debt, with great results.

I also like the approach of the Wall of Technical Debt to make progress and increase transparency on your actions.

Whatever approach works for you: discuss, measure, and adapt. This will help you find solid argumentation for your next roadmap cycle when you have to update or revisit your current refactoring business case.

Conclusion

I hope this two-part series has shed light on the often-underestimated impact of technical debt. It's not just about messy code; it's about missed opportunities, frustrated developers, and a real threat to your business's bottom line: a potential $300 billion annual loss in global GDP due to developer inefficiency, and organizations wasting 23-42% of their development time on technical debt. These aren't just numbers on a page; they represent real-world consequences that can hinder your company's growth and success.

As technical leaders, we have a responsibility to make code quality a business concern. It's time to move beyond vague statements like "We need to refactor" and start building data-driven arguments that resonate with management. By quantifying the impact of technical debt and showcasing the potential ROI of refactoring, we can shift the conversation from a purely technical one to a strategic business discussion.

In this series, we explained the hidden costs of technical debt, and its ripple effects on customers and the business, and touched upon the potential impact of AI coding assistants. We outlined a step-by-step guide to crafting a compelling business case for refactoring, empowering you to advocate for the changes your team needs to thrive.

Every modern business is a data business. Tackling technical debt is not just a matter of good coding practices; it's a data-driven decision that can unlock significant value for your organization. Take the insights from this series, gather your data, and start building your case for refactoring today. Your team, your customers, and your business will thank you for it.