It’s common knowledge that technical debt needs to be eventually paid off and in a timely manner. But in practice, working with a problematic, legacy codebase isn’t easy, or much fun.

On October 18th, GitPrime hosted a panel discussion to hear about strategies and lessons learned in Working With Technical Debt, Not Against It. The panel included founders and CTOs from Meetup, CircleCI, and Corgibytes — and was moderated by Marcus Blankenship.

Below, you’ll find the 8 key takeaways from the discussion (plus, a few handy resources for further reading).

To re-watch the full discussion on Working with Technical Debt, go here.

The conversation started with everyone explaining how they define “technical debt” — and everyone’s definition revolved around “friction” in the development process.

“Technical debt is anything that creates friction between the developer and delivering their work,” said Goulet. That could mean getting their dev environment up quickly. It can be that you don’t have tests. In fact, we usually define it as anything that prevents a developer from being completely in a flow and productive.”

Pasqua added, “We look at things that slow engineers down as well as reduce quality.”

Rob agreed with those definitions. He also said, “These things are often noticed first by engineers, but the problems are more in the ‘death by 1,000 paper cuts’ area and not an individual engineer going, ‘Oh yeah, I’ll fix that whole thing right now.’ But if you’re looking at these problems from a slightly higher level, hopefully, you have the kind of metrics and data to be able to say, ‘Wait a second — every single team is doing this thing and it’s slowing them down. And as a whole, it adds up. So as an organization, there’s a need to invest.’”

In summary, technical debt could certainly be code-based, but it also could mean a lack of automation, a lack of observability, or a lack of context. Rob even included “cognitive load” to that list, which is often caused by code complexity (or vague requirements, in some cases) and is visible through delay (in regards to time).

While the actual process of cleaning up or fixing technical debt may not be as a clear as a number in a bank account, the panelists agreed that it does help to think about managing the process in the same way as you would managing financial debt. Here’s why:

It can be leveraged
Technical debt can be important for the business to leverage in the same way capital is.

Step one is to “cut up the credit cards”
When “paying it off,” Zuber said, step one is to cut up the credit cards. “If you’re in this tailspin of tech debt, don’t be piling more on top. You’re certainly never going to dig your way out if you continue to follow the same behaviors and practices you’ve been using in the past. So the first step is to find a way to stop.”

Pay it down one paycheck at a time
Just as you would pay down debt a little at a time, with every paycheck — and you wouldn’t allocate an entire paycheck just once a year toward your debt — technical investments need to be integrated in every sprint. It’s not something you should just allocate a bit of time toward once a year and then forget about.

Especially when you’re deliberately sacrificing quality for speed (to any extent), make sure everyone (including Product) is on-board with the trade-offs that are being made. For example, you can either get the functionality to market today, and then invest additional time to make it great or stable later. Or, you can invest the additional time to make it stable now and get the functionality to the market later. It’s a trade-off, and it’s Engineering’s responsibility to be very clear and articulate about what those trade-offs are. (It’s in Engineering’s best interest to do so, too.)

“That’s where the real responsibility is. It’s on Engineering to be very clear and articulate about what the trade-offs are that we’re making in order to meet these requirements or these objectives,” Zuber explained. “We all need to sign up for this together, because we’re going to have to make the investment after. Otherwise, it becomes this ‘Oh, now Engineering is off cleaning up the mess because they couldn’t figure out how to build this thing properly in the first place.”

On a high-level, Goulet recommends teaching empathy to individual contributors for management (their managers, CEOs, CFOs, etc.) and vice versa. (She actually considers Indi Young’s Practical Empathy a required read.) “We define empathy as ‘proactive perspective taking and problem-solving.’”

Why teach empathy? She says, “the thing that we’ve found is there’s a high correlation between ‘empathy’ and the amount of technical debt.” Goulet relates it to Conway’s Law, which is the law that says your codebase will mirror the communication structures across your organization. “If you want to fix your legacy code,” Goulet says, “you can’t do it without also addressing operations, too. That’s the missing link that so many people miss.”

Creating empathy will ultimately support your long-term focus on Continuous Product Health. And as an added bonus, it’ll also elevate the quality of conversations around prioritization.

When you’re making the case to allocate resources toward technical debt, start by identifying the highest impact projects (or the “highest interest rate credit cards”) and pay those down first. You can identify the highest impact projects by time spent on technical debt (or ‘lost’ due to overhead), and frame that in dollar terms, or by measuring the impact it has on the customer.

Either way, being able to bring that kind of data to the table will help you make a more convincing case.

Plan for technical debt and technical investments with the same level of energy and focus that goes into planning a product strategy or roadmap. And, Pasqua offered that it’s important to always relate those investments in back to the company’s larger initiatives.

“Whether we’re planning our product strategy monthly, quarterly, or bi-annually, we plan for that and technical investment hand-in-hand,” said Pasqua. “We plan for technical investment in the same way and with the same level of visibility as we do product strategy.”

The panelists recommended rewarding those engineers who complete technical debt projects — and those who are in the habit of “cleaning as they go” throughout each sprint. In GitPrime, for example, you can identify these work patterns and see which engineers are working hard on technical debt, so you can celebrate those activities.

Meetup actually rewards people with trophies. Goulet also mentioned that having a Slack channel for “ShoutOuts” has worked for them.

Pasqua offered a strategy Meetup has used, which is to remove the term “technical debt” and replace it with “Continuous Product Health”. She said, “When we talk about ‘technical debt’, it’s as if everyone’s shoulders slump. So we tried calling it continuous product health, and it’s helped us so much to get people thinking and talking about it as just a healthy, happy part of what you do every day. Just the name alone really helps.”

Goulet added that her team considers this long-term strategy as “self-care,” because it resembles a long-term focus on health — for example, going to the gym, or eating healthy. You don’t just do “healthy” two weeks out of the year — it’s an everyday habit.

Technical debt will happen. What works for your business now may need to be changed to work for your business in the future.

“It’s fun to look back and say, ‘oh, I can’t believe that we did this or that we did that, and it’s a source of so many problems for us.’ But the truth is that it wasn’t a source of problems when we had 3 servers and 10 customers. What mattered then was that we got those 10 customers and turned that into 20 and turned that into 40…. It’s easy to say we should have built these microservices from the beginning. The difference is there would be no business. We did what was right for our business then, and now we have to make changes in order to scale.” — Rob Zuber