RDEL #15: How do engineering teams manage technical debt?
This week we review how different teams handle technical debt, and consider a research-backed framework for technical debt management.
Hello and welcome to RDEL - each week, we pose an interesting topic in engineering leadership, and apply the latest research in the field to drive to an answer.
This week we look at everyone’s favorite thing to gripe with… technical debt. Whether you’re a small startup cutting corners, or a large enterprise with decades of reminders of past engineering decisions, know that every team deals with technical debt and its consequences. One thing is certain - there is no “perfect” way to handle technical debt. With that in mind, we ask, how do engineering teams manage technical debt?
The context:
Technical debt is the work that comes as a result of the shortcuts an engineering team makes to prioritize short-term outcomes over long-term outcomes. It is a very important part of software development, and one that cannot be avoided. There are many reasons why teams might accrue technical debt:
As a startup, you might be looking for product-market fit and need to experiment quickly to get there. A strong infrastructure won’t help you get customers (usually), so you may skip a few steps with the intention to build a more resilient system later.
As a larger company, you may have chosen to deprecate a piece of a product, but not have the resources to remove all of the code until a later date. You might also have software for your best-selling product that was written a few years ago, and needs to be updated to the latest version. All of this is work you want to do, but are prioritizing this against the product features that need to happen now.
Unfortunately, every team eventually suffers consequences if they don’t “pay down” technical debt - slower software, longer development time, and in some cases, a complete rewrite of the product. (As someone who had to rewrite a core product feature and communicate the 3mo impact to the product team, I don’t wish that experience on anyone.) Managers are often wondering what the best way to manage technical debt is to avoid catastrophic repurcussions. In this study, we’ll look at a research case study on 8 different engineering teams and where they overlap or differ.
The research:
A team of researchers performed a case study of eight technical teams to identify the different ways teams manage technical debt. The eight software teams included 4 product teams, 1 platform team, 2 integration teams, and 1 internal tooling team. Every team was asked about how they identify, measure, monitor, prioritize, communicate, and prevent technical debt. Through this, the team came up with a technical debt management framework, that categorizes the different styles of how teams manage technical debt.
After studying each of the eight teams, researchers noted that every team had their own process of managing technical debt. Using their experiences, they put together a framework to understand the various styles of technical debt management across different activities.
The researchers noted the following:
Teams can be in different levels of maturity for different categories. For example, they can be “organized” when it comes to repayment, but “unorganized” in their documentation.
Some development teams only focused on two or three technical debt activities, while one team conducted all eight activities. The team’s focus ranged significantly.
The most commonly used activity in tech debt management was communication, specifically the gap between technical and non-technical stakeholders. The most rarely used activity was measurement - few teams measured technical debt in a way they felt confident (most teams used JIRA points or SonarQube, and felt it was only an approximation at best).
The biggest challenges teams mentioned in managing technical debt were lack of tools, shared understanding of priorities, adopting a good mindset, and managing the time commitment.
The application:
This paper adds evidence to a perspective that has been commonly felt in the industry - there is no “perfect” way to manage technical debt. There are many imperfect ways that can hurt an organization’s overall velocity, but doing technical debt mangement “well” requires striking that balance of being thoughtful about the baggage your team carries, and communicating it well.
A few tactical action items from this study can be applied as a reminder to any engineering team:
Communicate your technical debt. Engineering teams often carry the weight of technical debt more than other teams. If product stakeholders don’t know about this weight until things have reached a significant level, it will be much harder to get the necessary time and energy to pay it down in due time, and risk delaying the product roadmap.
In leveraging the TDM framework, you can be “received” or “organized” across categories, but avoid being “unorganized” in any category. Technical debt is a balance of being aware of how much you have and having a plan to manage it. It doesn’t necessarily mean always giving 30% of your sprint capacity to working on it, but it does mean avoiding making tech debt a fire-fighting exercise.
Measure so you can improve. Without knowing how much debt you have, you can’t create a cohesive strategy to pay it down. A few ways to measure include tagging technical debt tasks in project management tooling as well as pulsing developers on a semi-regular cadence to learn more about how technical debt impacts the team on an ongoing basis.
You will continue to accrue technical debt. It is a natural, healthy part of a maturing organization. You can’t control that it will happen, but you can control how you manage it.
Hopefully this post will ignite some backlog grooming and interesting conversations. Wishing you a wonderful week, and a happy Research Monday!
—
Lizzie
From the Quotient team