How These Austin Companies Measure and Manage Technical Debt

by Alton Zenon III
October 16, 2019

Ask any senior engineering leader: managing technical debt requires collaboration between teams and a detailed plan for both accrual and elimination. Technical debt doesn’t impact just one team — its effects ripple throughout the entire business. And if it isn’t paid back properly, it can lead to wasted time and effort. 

There is such a thing as “good” technical debt, however, and we got the inside scoop from tech leaders at Austin’s Bright Health and Cerity to learn more about how they manage theirs, and ultimately, make it work for the business.

 

Bright Health team working in conference room
Bright Health

Having friends that “get” you is a wonderful thing. Bright Health’s engineering and product teams work together so closely that Chief Technology Officer Brian Gambs said “the trust is built into the relationship.” This allows the teams to openly discuss how to best tackle technical debt together in a way that benefits them both, and the business as a whole.

 

What is technical debt and how does your team define it? 

To us, technical debt means less-than-ideal choices in software design, development or coding. Technical debt can be good or bad. A team takes on good technical debt when it deliberately takes shortcuts, puts hacks in place, or uses quick-to-implement but non-scalable approaches in order to “fund” higher velocity work or put more focus on what is most important. A team takes on bad technical debt when it cuts corners without purposeful intent — things done by accident or not for a deliberate purpose. 

The use of vendor systems is an example of where we have incurred technical debt over the last four years. While we know that we will need to replace many of those systems in order to achieve our ultimate goal, we never could have built all that technology from scratch in such a short time.

A shared belief that the quality of the software matters and requires investment to maintain makes it easier to manage technical debt.”

 

When technical debt does occur, what process does your team use to measure and manage it?

Our approach to managing technical debt is based on a strong partnership between the engineering and product teams. Together, we work with the rest of the company to define our shared priorities. We are fortunate to have a working relationship with a product team that understands that protecting the quality of our software is important to the long-term velocity of the engineering team and thus to the success of our business. So, when we plan our roadmap, we can have honest conversations about the tradeoffs that occur when we take on technical debt. The trust built into the relationship, and a shared belief that the quality of the software matters and requires investment to maintain, makes it easier to manage technical debt and use it for leverage against velocity rather than only as a nagging burden.

 

What proactive measures does your team take in minimizing technical debt?

The most important thing that we do to minimize technical debt is to be thoughtful about our overall product development process and technical roadmap in order to control how and when we take on “good” technical debt. In our engineering process, we build in mechanisms that allow us to avoid bad, unintentional technical debt. For example, our check-in, merge and pull request process includes code review, and we have a culture of collaborative architecture and design that helps all of our teams make good engineering decisions at critical moments along the development path. That helps us avoid rework, which is one of the primary sources of technical debt.

 

Cerity team in group photo
Cerity

Technical debt at Cerity is handled through a detailed set of principles, according to company President Tracey Berg and Director of Engineering Tim Smiser. The leaders at the workers’ compensation solution provider describe a formulaic approach to compiling and disposing of technical debt that is surprisingly simple: solution architecture.

 

What is technical debt and how does your team define it? 

Berg: Prioritization is a daily activity in any company. It is impossible to do everything we want at the time we want to do it; trade-offs are almost always necessary. Sometimes, time to market is more important than implementing the ideal technical solution. Other times, budget constraints may limit an organization from implementing the preferred approach. In these situations, a less-than-optimal solution is put into practice and technical debt is created. Historically, it was common to leave this sub-optimal solution in place. This results in long-term maintenance, flexibility or usability issues. If not managed, the amount of technical debt can grow so large that it seems insurmountable to address. 

At Cerity, an example of technical debt is our portal login process. While most of the user experiences in our applications are custom developed, we leveraged the user interface provided with our authentication technology. It works and does what is needed from a security perspective, but the screen is not consistent with the look and feel of the rest of the application. We chose to leave it this way temporarily because our front-end development team had higher priority work to do. In doing so, we created technical debt. It was the correct priority choice at the time but it is important we prioritize fixing it at some point in the future. 

Technical debt needs to be worked as a priority alongside other priorities.”

 

When technical debt does occur, what process does your team use to measure and manage it?

Smiser: Technical debt is managed in the same way as other work — it’s put into our work management system and prioritized in backlog discussion. It’s easy to let technical debt operate outside of the work that is customer-driven. The result of this approach is incomplete technical debt resolutions and frequently late delivery on other commitments. Technical debt needs to be worked as a priority alongside other priorities. And just as any other work effort has a plan for delivery along with associated measures for delivering, the same approach needs to be applied for technical debt to ensure its completion.

 

What proactive measures does your team take in minimizing technical debt?

Berg: The most important approach to minimizing technical debt is to understand when technical debt is being created and create a plan for addressing it, and there are some important steps in doing that. 

A solution architecture is a critical part of understanding when technical debt is created — it should outline the ideal technical solution. Technical debt is created when the “ideal” is not fully implemented. The creation of this solution architecture enables these tradeoffs to be identified and discussed.

When a decision is made to go forward with technical debt, the decision-makers need to understand the implications of their decision. What manual workarounds will need to be in place? How much throw-away work will be done as a result of this decision? What flexibility or speed to market are we gaining or losing? What additional risks is the organization taking on as a result of this decision? Then it’s necessary to immediately put the technical debt into the work queue for prioritization and ensure there is an allocation of resources to address high priority technical debt.

 

Jobs from companies in this blog

Austin startup guides

LOCAL GUIDE
Best Companies to Work for in Austin
LOCAL GUIDE
Coolest Tech Offices in Austin
LOCAL GUIDE
Best Perks at Austin Tech Companies
LOCAL GUIDE
Women in Austin Tech