I walk past the CEO in the hallway. “Hey Jean, it’s been awhile. What are you working on these days?”

Scenario one: I reply, “Oh I’m working on this big refactoring project. It’s taking a few months, but we had really accumulated a lot of technical debt.”

Scenario two: I answer, “I’m working on a large project to make product development a lot faster for existing engineers, and to make onboarding the 5 new hires starting in the next two weeks a lot faster.”

Same project, different perspectives, and probably two very different reactions.

In the first scenario, my manager might get flak about why are engineers always refactoring? We don’t have time to refactor. We just need to ship features, so that we can get closer to product-market fit. There’s no time for engineers to re-organize the codebase just to please their aesthetic sensibilities! Let’s make sure the PMs really break down everything into very granular tasks so we can make sure engineers don’t get distracted by refactoring again.

In the second scenario, the CEO and any other execs might walk away trusting the team more, even when they don’t have visibility into engineering projects. They trust the team more and they trust me more because we are working towards business goals — shipping faster, higher productivity, focusing on impact.

Communication is important, and communicating about impact is even more important — particularly when it comes to reducing technical debt.

Most engineers can refactor things as they come across them, open up pull requests, merge the changes, and there doesn’t need to be an explicit conversation about it. Successfully getting buy-in for larger projects that require more time and staffing to reduce technical debt requires two key ingredients. The first is taking a hard look at the project and making sure it is indeed impactful. The second is communicating the impact effectively to get buy-in.

Assessing the Impact of Reducing Technical Debt

A few years back, I was confused that we were just letting technical debt pile up, with no major projects underway to attempt to pay it off. In an engineering meeting, I raised the issue, and asked the head of engineering if it made sense to start some projects to pay it down.

I remember his response vividly: “We’re still looking for product-market fit, so the communication from the leadership team is: it’s fine if we’re bleeding a bit, but let them know when we’re gushing out blood.” This gory analogy provided powerful clarity that now was not the time to spend a lot of effort getting the codebase in tiptop shape — though if things got really bad and productivity suffered heavily, we should raise a flag.

Before we spend large amounts of time on technical debt, we need to make sure that what we’re doing is indeed impactful and can be justified alongside other team priorities. Doing this honestly sometimes requires an uncomfortable level of introspection. We all get caught up with pet projects or things we’re really itching to do. Having the discipline to take a step back, assess the impact of a project, and then decide if it’s worth prioritizing is difficult. But it also models for the rest of your team how to think critically about priorities and focus.

To assess the impact of a technical debt project can be non-trivial. It may require asking questions such as:

• What sort of product changes are we expecting to make in the next few months?
• What are the top priorities for the engineering team right now? What about the company?
• What does our hiring pipeline and plan look like for the next quarter or two?
• What does success look like for this project, and what would be the impact on the engineering team?
• What’s the impact the current status quo has on developer productivity, engineer on-boarding, code reviews, etc?

If you ask all these questions, and your conclusion is that the project isn’t a current priority, your effort doesn’t have to go wasted. Write up a proposal with what you’ve learned, and clearly state what has to be true for the project to be worthwhile. Perhaps it’s the next time there’s a big hiring surge, or the next time the project area requires a major change in business logic. Clearly communicating these thoughts, and having the discipline to say “no, not right now, but here’s when we should seriously consider it” will instill an impressive amount of trust in you from your teammates.

If you and your team would like to proceed with the project and still require buy-in, proceed to the next step.

Communicating the Impact Effectively

Ok, so you’ve decided that this project is worth it. Now, you still may have to convince other people — whether it’s your manager, your team lead, or someone else in the company — that it is.

As engineers, we’re sometimes hesitant to “market” or “sell” our work. Marketing feels dirty, as if we’re putting a spin on things. In reality, the more distant that our audience is to the mechanics and the goals of our work, the more important that communicating about impact becomes.

Impact is the common language that slices across teams and functions.

You can follow the thread of impact to fine-tune the messaging for whoever you need to communicate with. For example, say you’re refactoring some code relating to a user service. Ask yourself:

• What is the impact of this project? UserService.js will be in the new format, so 9 out of 15 service files will be converted.
• What’s the impact of that? We’ll have increased clarity around how new features should be built.
• What’s the impact of that? We’ll spend less time discussing these issues in code reviews (What are we supposed to do in this case again?), and we’ll be able to onboard the next 10 new hires much faster.
• What else? New features for the upcoming launch can be built much more quickly and cleanly and with much less discussion.
• What’s the impact of that? By taking a few days to do this, we’ll be much more likely to hit our target launch dates with fewer unexpected roadblocks.

Following this thread of questions, continue until you reach a set of impacts that you feel will be a no-brainer for whoever you have to sell it to. When talking about expected impact, clearly state an expected timeframe upfront.

Also, focus on the impact that your audience would be most likely to understand. Ask yourself, what is this person most concerned about? If it’s your Tech Lead, the first technical impact (getting closer to full conversion to a new convention) may be fine. If you need to justify this project to a product manager who is not familiar with the codebase, the last few product impacts will probably be better. If you’re talking to a business person, any impact on revenue or sales will matter more.

The more clearly that you can articulate your impact, the more successful you’ll be at getting buy-in.