DEV Community

Cover image for Lessons interviewing 200+ engineers: the perfect process to manage tech debt
Alex Omeyer for Stepsize

Posted on • Updated on • Originally published at

Lessons interviewing 200+ engineers: the perfect process to manage tech debt

Over the last six months, I've learned how the best software engineers and leaders manage technical debt. I've interviewed more than 200 experts, to understand how tech debt is handled at growing software companies. I've discovered what many companies are missing and compiled my learnings into a simple but powerful framework, to share with you.

As part of the customer development work for our new Stepsize product, I needed to understand the differences between software companies that have their tech debt under control and those that don't.

Tech debt is an emotional topic and it gets people talking like nothing else-and it's a lot less controversial than politics. Just ask your local engineer about tech debt and you'll see. But you might want to clear your schedule first.
Alt Text
In many–if not most-cases, tech debt accumulates until it creates problems that are impossible to ignore. So, you fix these problems and move on with your life. And you accept that maybe that's just how it's done.

But should we really accept the results of Stripe's research, which find that, at the average company, 'engineers spend ~33% of their time dealing with technical debt, which crushes team morale and costs companies ~$85 Billion/year'? Shouldn't we do something?

Gartner and many others have already shown us we should. Their research has revealed that organisations who actively manage tech debt will ship at least 50% faster.

I don't know a single software company that doesn't want to ship 50% faster.

Luckily, I did meet companies with solid tech debt management strategies. There were many light-bulb moments in these interviews. One of my favourites was when James Rosen, Engineering Manager at Everlane, told me:

Consider how much time PMs spend curating the set of features to work on. Now compare this to the amount of time and effort engineers dedicate to making the business case for tech debt. Is it that surprising that close to zero engineering capacity gets allocated to tech debt?

I must admit that nope, it isn't.

However, I also met plenty of teams that spent a lot of time and effort managing tech debt and still went nowhere.
All my research points to a simple fact. Companies that successfully manage tech debt have developed appropriate processes that are fully integrated into their usual Agile ceremonies and have become habits.

These engineering teams are in control of their tech debt. They ship faster and more predictably. Their engineers are happier, their customers are happier-heck, they're all winning.

It really doesn't take much to get there. You just need to be clear on how you'll deal with small, medium, and large pieces of tech debt.

How to handle small pieces of debt

This is the type of tech debt that can be addressed as soon as the engineer spots it in the code and it's within the scope of the ticket they're working on. It might be something as simple as the refactoring of a function, or renaming some variable. Try to follow Robert C. Martin's boyscout rule:

Always leave the code better than you found it.

These small jobs don't require any kind of planning and every engineer should feel empowered to fix this kind of debt without anyone else's approval. We've already written about the one cultural characteristic you need for a healthy codebase, but ensure it exists in your engineering team. If it doesn't, take measures to address it now.

There are many tools to help you on this front. Our very own Tech Debt Metrics extension for VSCode will give a code-quality score and breakdown, directly in your editor. Other code-quality tools, like Code Climate or Codacy, which you can include in your CI pipeline and code review process, are great for this too.

How to handle medium-sized debt

This type of tech debt can be addressed within a sprint. It should go through the same sprint planning process as any feature work and be considered just as rigorously. That's where most engineering teams fail-remember James Rosen's comment:

Is it that surprising that close to zero engineering capacity gets allocated to tech debt?

Businesses rightly prioritise work that delivers value to the customer. And, at first glance, getting rid of tech debt doesn't do that.

But tech debt hinders your capacity to deliver value to the customer.

To explicitly demonstrate how this occurs, identify debt that gets in the way of crucial initiatives, or costs the business dearly in terms of engineer productivity, or is the cause of bugs that impact the customer experience.

Documenting tech debt and quantifying its cost allows you to prioritise the debt that, if addressed, will deliver value to customers - just like new features do. The engineering organisation owns tech debt. It is their responsibility to address it and ultimately make the business case for it.

Unfortunately, this is where our current tools have so far failed us.

Jira is a great place to manage projects, but a terrible place to track and monitor tech debt.
Jake Peyser, Lead Engineer at Unqork

Code-quality tools are helpful at surfacing one facet of tech debt, but they don't catch most of the others.

Fortunately, that's exactly what our new product is for.
Engineering teams have limited time to deal with tech debt and they need to make that time count. Stepsize helps them capture and track tech debt from their workflow, so they can quantify its cost to the business and ultimately prioritise the most important debt.

Each engineer can report tech debt and its cost directly from their workflow (including editors, pull requests, and Slack). These reports all go to the Stepsize website where they are collated into 'tech debt items', describing and documenting issues in the codebase. Finally, each Jira ticket gets decorated with relevant tech debt items that may be addressed to more effectively deliver value to customers. No more lonely refactoring tickets that are never prioritised-tech debt and business value become truly aligned.

We advise that engineering team leads assume responsibility for managing this process. They're the right individuals to stay on top of tech debt in those parts of the codebase their team owns, and to interface with the PM when it's time to address the debt.

How large pieces of debt should be handled

This is the tech debt that cannot be addressed immediately or even in one sprint. The best companies I've interviewed have quarterly technical planning sessions in which all engineering leaders participate. Engineering managers are tasked with highlighting the large pieces of tech debt reported to them and making a business case for those they judge to be the most important.

This process, which sounds laborious, becomes very easy for Stepsize users. Their individual contributors have already been reporting debt from the frontlines regularly. This data is consistently reviewed and groomed by each team and their leaders, who relay the large pieces of debt - along with the data necessary to understand what they've cost the business - to their engineering managers. Stepsize even surfaces tech debt for each of your Jira epics. Leadership can then use their understanding of the company's broader priorities and vision to sequence large pieces of debt accordingly.

Once each large piece of debt is approved, it can be scheduled onto the roadmap, just like feature work. Engineering leadership then has all the data they need to monitor progress on each tech debt project.


Any modern software company should be able to apply this process for small, medium, and large pieces of tech debt. However, one thing will differ between each company: business objectives.

Managing tech debt properly means addressing the debt that gets in the way of your business objectives. If your business is built on uptime and reliability, nuke any debt that puts them at risk. If velocity is your competitive advantage, get rid of any debt that wastes engineering time or makes it hard for new hires to understand the code. If you want to reduce customer churn, address the debt causing quality issues.

Be clear about the business case for addressing each piece of debt. Because when you are, you'll ship better software, faster-and you'll keep your engineers happy.

Top comments (0)