How to convince people to deal with tech debt

Apply these lessons and you too will be able to understand which debt you should address first. They will help you unlock the resources you need by enabling you to convince your colleagues—especially senior management—that this is the right move.

I started on this journey determined to find the shared characteristics of engineering teams who have tech debt under control. But something else struck me along the way—even at those companies where tech debt was well managed, not all of it was addressed.

These companies were confident to leave some debt sitting there, while other pieces of debt were immediately scheduled into the next sprint. And that makes sense. Let me explain.

I’ve written before that you should address the debt that's in the way of your roadmap, but the best engineering teams I interviewed were so clinical and confident in their choices, there was clearly more to it.

I realised that I had to find the shared characteristics of tech debt that got addressed, and contrast them with those left unattended.

That's how my most interesting interview question was born—'What is the difference between tech debt that gets addressed and tech debt that doesn't?'

Once you understand the answer to that question, you'll never feel bad for leaving some debt unattended. And you'll be able to back up your passionate pleas for addressing another piece of debt with a real business case.

You don't need an MBA, and it's a lot simpler than the words 'business case' make it sound.

How to make the business case for tech debt

Once you've established whether the tech debt you're considering is small, medium, or large, ask yourself the following two questions.

1. Is this debt in the way of a key feature?

Review your product roadmap and figure out whether the debt you're considering will impact the delivery of key features. For example, the way you currently query your databases might not allow you to show live data on the dashboards in your SaaS product. This is a simple issue, but it needs the expertise of an engineer with appropriate knowledge of the codebase to fix it—probably a team lead.

If this debt would indeed cause problems with shipping a feature, make a note. This is crucial data to include in your tech debt item report and discussions with the relevant Product Manager.

As Will Ellis (SVP of Engineering at Soundcloud) told me, there's a particularly perverse effect of tech debt that you might need to dig deeper to uncover:

Are some features missing from your roadmap because existing debt has made them impossible to deliver and people have given up on the idea?

It happens more often than you think. One common culprit is debt in your data models at the foundation of your application that has ossified over the years. This prevents you from making modifications further down the line.

For example, you may have built your application on the premise that only one unique organisation is allowed for each account in your B2B software. And then some giant multinational comes along and tells you they have a portfolio of 50 companies for which they'd like to aggregate all the data—suddenly, your data models, based on your existing premise, are no longer appropriate. But now, it's too late because you can't change them without rearchitecting your whole application.

2. Will this code get modified a lot in the future?

If none of the engineering work on the product roadmap touches the code where the debt lives—and if this debt isn't the root cause of any bugs or other quality issues—you should probably leave it alone. You can deal with it later; you'll almost certainly find other, more pressing, debt to deal with first.

However, if you’re planning a lot of work on this code, try to estimate how much engineering time has already been wasted in the past due to the debt. Once you have that datapoint, extrapolate—how much time will this debt have wasted by the time you ship the feature? If this number is significantly larger than the time it would take you to fix the debt, it's a no-brainer: fix the debt.

Similarly, figure out if this debt was the root cause of specific bugs, outages, UX issues, or past customer complaints. Once again, extrapolate to estimate how much it will have cost the business by the time you're done working on the code. If these quality issues will be costly to the customer—and therefore the business—you can argue that the debt should be fixed before anyone introduces more problems by working on the code where the debt lives.

These are tough questions to answer, especially for a single engineer without the right tools. For example, how would you find answers for debt that spans multiple parts of a giant codebase? No single human could be expected to do this alone.

How can I explain technical debt to non-technical stakeholders?

One of the tricks to convince managers to deal with technical debt is to speak their language. As Nicolas Carlo points out, try to explain that you don’t want to address technical debt for the sake of it, but because you want to deliver features faster. Instead of “We want to reduce our TTM (Time-To-Market)”, try “We could reduce our turnover if we invest some time in code quality”. Talk about productivity in lost hours, costs of lost hours, and customer satisfaction.

A tech debt item template for you to follow

Stepsize is a game-changing product designed to help engineering teams manage technical debt. One of its key features is tracking, bookmarking, and labelling issues directly in your code editor.

Stepsize is the only tool integrated into engineers' workflows, so they can report on debt and its cost to the business without leaving their editor, GitHub, or Slack. They can feed the tech debt they wish to address directly into their sprint in Jira. That's how you can prioritise your issues in the web app:

‍Learn how to get started with Stepsize here. It works with Visual Studio, VS Code, JetBrains.

Moral of the story

Debt that gets addressed is backed up by a solid business case. You cannot expect tech debt to make it through all the filters in your organisation and land on your roadmap if it isn't. It's that simple, and it's the way it should be.

Importantly, going to the trouble of making a business case for tech debt isn't just about convincing people. It's about making the right decisions to propel your business forward. We're engineers, we love 'perfect'. But perfect is the enemy of ‘shipped’. Don't get caught in that trap, and don't get upset next time the tech debt that triggers your OCD is deprioritised in favour of other debt that’s more important to the business. Its time will come.