It's finally time for your meeting with the Product team, and you're excited to share some feedback you got from the community. Not only that, but you even have an idea of how to fix the issue! You sit down at your computer, fire up that Zoom call, give yourself a quick check, and join. Eventually, your turn comes around, and you explain the problem and the possible fix. Everyone is super excited to receive your feedback and loves your idea! Victory!

You follow up and ask when they think they'll be able to prioritize that work. You eagerly wait as the product team talks about timelines and current projects, eventually saying, "We want to do it, but we're focused on X until the end of this year. So let's circle back." Finally, the meeting wraps up, everyone says their goodbyes, and you leave the meeting feeling frustrated. You know this issue is essential, so why are they not prioritizing it?

There are many reasons that decision-makers may not act upon the feedback we deliver. Still, one thing we can always ask ourselves is, "did I get enough buy-in before I asked them to commit?"

In this post, I'll cover what buy-in is, how it applies to developer advocacy, what skills help the most when trying to get buy-in, and the processes I use.

What is buy-in?

Buy-in is an agreement to support a decision. So, when we are trying to get buy-in, we're trying to get decision-makers to support our ideas. So, the act of getting buy-in is a process that involves building trust, communicating your ideas well, and hopefully creating champions so that when you ask for a commitment, you already have the right people on board.

Buy-in & developer advocacy

You might often hear developer advocates say they advocate on behalf of the community, but what exactly do they advocate for, and to who?

Developer advocates advocate for changes to a company's products, offerings, and software based on friction experienced by developers in the community.

Getting buy-in as a developer advocate is a unique challenge. We usually are not the owners or even direct contributors to what we're trying to change. Instead, we represent this bizarre ephemeral thing called a "community."

Because of this relationship, we have to be extremely careful in our approach to initiating change. We have to go the extra mile and make sure we've built a relationship with the people we need in our corner.

We need to take the time to make sure we understand what they are currently invested in, what effect our changes would have on their plans, and the amount of work it would take to make it happen.

Skills to develop for getting buy-in

One thing you might have noticed is that getting buy-in is all about working with other people. As such, the skills that will show the most dividends will be the ones that help you interface with the most complex computers of all, people.

Communication

Getting someone to support your ideas will be difficult if you cannot clearly state the problem, present a solution (if you have one), and provide enough context and supporting information to make informed decisions.

A significant part of developer advocacy is helping people understand their problems with a given product/technology and providing solutions. Lean on that!

Make sure to explain the problem in a relatable way to whoever it is you are trying to educate. Make sure you're framing the problem so that they can see how it will affect their success. For example, are they tracking MAUs (monthly active users) for a particular feature? Will this fix increase that metric? Look for commonality!

Empathy

It's important to remember that initiating change requires consent from all involved parties. So we need to build relationships with the people we'll ask to help us and ensure that the relationship is mutually beneficial. We can do that by understanding what goals they are working towards, what metrics they are concerned with, and what plans they have for the future.

When we include these things in our conversations with them, it shows we've thought about what effect our changes will have on them and how it could benefit them and goes a long way towards building trust.

Patience

Change is slow! Sometimes it might take a significant amount of time to get the buy-in you need to push something through. Depending on the size of the company you work for, this could be months for things that feel like they should be quick.

Make sure you're aware of product roadmaps and engineering timelines—plan for changes to take a while if adopted at all. Also, have fallbacks and short-term fixes to help reduce friction until you can get a proper fix.

Persistence

You might do all the right things and STILL not get buy-in. It happens! It's essential not to give up and look for other avenues to get the buy-in to initiate that change. This process is a cycle, and you repeat it until you get the desired outcome.

Look for other ways to help remove that friction for users. For example, are there any intermediate steps you can take or content that you can create to help people work through it?

It's important to constantly reassess the efficacy of the change as time goes on as it may become obsolete.

Tips for getting buy-in

So you know the skills you need to improve your odds of getting buy-in, but how do you put that into practice? Here are some of the tactics I've used to initiate change.

Collect data

Want to get someone on board for a change you are proposing? Show them quantitative data related to their goals, and it won't take much of a conversation.

Collect as much qualitative data and quantitative data as you possibly can. Qualitative data is feedback provided by the community or findings from your investigations. Quantitative data is the metrics that relate to the area you want to change.

Quantitative data is more valuable but usually harder to connect directly to a pain point developers are facing. Qualitative data holds less value but is generally easier to collect. If you lack quantitative data, it's essential to gather as much qualitative data as possible!

Record experiences

We know that empathy is an effective tool for helping us better understand the needs of people we communicate with, but we can also use empathy to help others understand the frustration users feel when they experience a particular pain point.

By recording either our own or users' experiences with a given workflow, we can clearly frame the issue for others. In addition, sometimes, users will experience the same pain point across multiple workflows, which helps outline the severity of the problem.

At Apollo, we use friction logs to record experiences.

Build desired outcomes

Building desired outcomes is a technique I brought over from my time as a tech lead. Tech lead is another position that is constantly initiating change. One of the techniques I came to rely upon was building prototypes or desired outcomes so that decision-makers could experience the change.

A more concrete example is when I wanted to adopt GraphQL at Major League Soccer. I knew it would solve many problems for us, but I needed everyone else to understand that too. Our existing architecture consisted of REST APIs, and our product managers would often examine data from these APIs due to partnerships we had with other companies.

Because they wanted to explore the data, we would build an "API browser" or small client application that allowed people to interact with the API through a UI. Since we discussed rewriting the API and versioning it again, I knew that we would need to build these UIs again. Knowing that product managers rely on this, I showed them how we could get the same functionality from GraphiQL if we adopted GraphQL. The idea of getting that same result without any development effort was exciting to them.

It's much easier to decide on something when you can experience its benefits before you build it.

Look for alignment

Sometimes getting enough buy-in can be the result of aligning your changes with existing plans to change something! So stay up to date on the product roadmap, look for opportunities to include your changes into a current initiative.

I recently spoke with someone trying to get the buy-in to dedicate engineering time to their navigation component. The existing solution was requesting the navigation metadata on the client-side. Not rendering the navigation on the server prevents some SEO benefits you get by having navigation be crawlable.

They have wanted to implement this fix for a while and tried to get buy-in for it previously. However, it wasn't until a new project for the navigation came along that they were able to resurface the change and finally get the buy-in they needed as the work aligned with the project.

Conclusion

As developer advocates, we'll often face situations where the best way to help the community is through initiating change. However, because we're generally asking people to change things they are responsible for, we have to be sure we're doing our due diligence to understand the changes we're asking people to make. We have to provide so much compelling evidence for our case that not only do they support our ideas but champion them as well.