The Developer Advocate's Guide to Getting Buy-In  ## Metadata - Author: [[theworst.dev]] - Full Title: The Developer Advocate's Guide to Getting Buy-In - Category: #articles - Document Note: ## Summarize: This article discusses the concept of "buy-in" in the context of developer advocacy. Buy-in refers to the process of gaining support from decision-makers for proposed changes or ideas. For developer advocates, this means advocating for changes to a company's products and software based on feedback and friction experienced by developers in the community. The article emphasizes the importance of building trust, effective communication, empathy, patience, and persistence in the process of getting buy-in. Skills such as clear communication, relatable problem framing, and understanding the goals of stakeholders are crucial for success. The author shares tactics to initiate change, including collecting quantitative and qualitative data, recording user experiences, building desired outcomes, and aligning proposed changes with existing initiatives. The overall goal is to ensure that when seeking commitment from decision-makers, developer advocates have the right people on board who understand and champion the proposed changes. ## Bullet Points: - **Buy-in in Developer Advocacy**: - Developer advocates seek to advocate for changes to a company's products and software based on community feedback and friction experienced by developers. - Buy-in is the process of gaining support from decision-makers for proposed changes or ideas. - The act of getting buy-in involves building trust, effective communication, and creating champions for the proposed changes. - **Skills for Getting Buy-in**: - Communication: Clearly stating the problem, presenting solutions, and providing sufficient context and supporting information for informed decisions. - Empathy: Building relationships with stakeholders, understanding their goals and metrics, and showing how proposed changes can benefit them. - Patience: Acknowledging that change can be slow and being aware of product roadmaps and engineering timelines. - Persistence: Continuously seeking alternative approaches and reassessing the efficacy of proposed changes over time. - **Tactics for Initiating Change**: - Collecting Data: Gathering quantitative and qualitative data related to stakeholders' goals and the areas of change. - Recording Experiences: Using empathy to help others understand user frustration by documenting experiences with pain points. - Building Desired Outcomes: Creating prototypes or demonstrations to allow decision-makers to experience the benefits of proposed changes. - Look for Alignment: Finding opportunities to align proposed changes with existing plans or projects. - **Conclusion**: As developer advocates, it is essential to thoroughly understand the changes being proposed and provide compelling evidence for them, ensuring the right people are on board to champion and support these changes. ## Paraphrase: 1. One significant challenge for developer advocates is gaining "buy-in," which means obtaining support from decision-makers for proposed changes or ideas. This process involves building trust, effective communication, and having advocates who can champion the proposed changes. As developer advocates, their role is to advocate for changes to a company's products and software based on feedback and issues experienced by developers in the community. 2. To be successful in obtaining buy-in, developer advocates need to possess certain essential skills. These include clear and concise communication, where they can articulate the problem, present possible solutions, and provide relevant context and supporting information for informed decisions. Empathy is also crucial, as it helps build strong relationships with stakeholders, understand their goals and concerns, and demonstrate how proposed changes can positively impact them. Patience is necessary because change can take time, and developers should be aware of product roadmaps and engineering timelines. Persistence is key as well, as they may need to explore various approaches to obtain buy-in, and reassess the efficacy of their proposed changes over time. ## Conclusion: Developer advocates play a vital role in advocating for changes to improve products and software based on feedback from the community. The process of gaining buy-in requires building trust and effective communication with decision-makers, ensuring they understand the proposed changes and have the right people supporting them. Skills such as clear communication, empathy, patience, and persistence are essential for developer advocates to succeed in this process. By using tactics like collecting data, recording user experiences, building desired outcomes, and seeking alignment with existing initiatives, they can increase the likelihood of obtaining buy-in for their proposed changes. ## Questions: 1. How can developer advocates effectively communicate with decision-makers to gain their support for proposed changes? 2. What role does empathy play in the process of getting buy-in, and how can developer advocates build strong relationships with stakeholders? 3. How does patience impact the success of obtaining buy-in, and how can developers handle situations where changes take longer than expected? 4. What tactics can developer advocates use to initiate change and demonstrate the benefits of their proposed ideas to decision-makers? 5. How can the use of quantitative and qualitative data enhance the chances of obtaining buy-in for proposed changes? 6. In what ways can developer advocates align their proposed changes with existing initiatives to increase the likelihood of getting buy-in? 7. How can persistence and reassessment of proposed changes over time lead to successful outcomes, even in cases of initial rejection? ## Auto-tagging: developer advocacy, buy-in, decision-makers, communication, empathy, patience, persistence, data collection, user experiences, desired outcomes, alignment, proposed changes. ## Index Creation: - Buy-in: 3 - Definition: 3 - Importance in developer advocacy: 5 - Skills for Getting Buy-in: 4 - Communication: 6 - Empathy: 7 - Patience: 8 - Persistence: 9 - Tactics for Initiating Change: 10 - Data Collection: 11 - Recording Experiences: 12 - Building Desired Outcomes: 13 - Look for Alignment: 14 ## Table of Contents: 1. Introduction 2. Buy-in in Developer Advocacy - Definition - Importance in developer advocacy 3. Skills for Getting Buy-in - Communication - Empathy - Patience - Persistence 4. Tactics for Initiating Change - Data Collection - Recording Experiences - Building Desired Outcomes - Look for Alignment 5. Conclusion 6. Thought-Provoking Questions 7. Key Themes and Topics 8. Index 9. References 10. Future Research and Hypotheses 11. Methodology 12. Implications 13. Logical Validity ## References: No sources were explicitly cited in the article. ## Future Research: - Investigate further how clear communication and problem framing can influence decision-makers' perception of proposed changes. - Explore the role of empathy in building successful relationships with stakeholders and how it impacts their willingness to support proposed changes. - Conduct research on the ideal balance between patience and urgency when seeking buy-in for changes, especially in fast-paced industries. - Examine how different types of data (quantitative vs. qualitative) can be leveraged effectively to strengthen the case for proposed changes. - Investigate the impact of aligning proposed changes with existing initiatives and its effect on decision-makers' willingness to commit to the changes. ## Hypotheses: 1. Hypothesis: Developer advocates who effectively communicate the problem, propose feasible solutions, and provide supporting data are more likely to gain buy-in from decision-makers. 2. Hypothesis: Demonstrating empathy and understanding stakeholders' goals can lead to stronger relationships and increased support for proposed changes. 3. Hypothesis: Patience and persistence are positively correlated with the likelihood of obtaining buy-in for changes, with long-term efforts being more successful. 4. Hypothesis: Utilizing both quantitative and qualitative data can enhance decision-makers' understanding and acceptance of proposed Abstract: Thi - Document Tags: [[devrel]] - Summary: 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. - URL: https://theworst.dev/developer-advocates-guide-to-getting-buy-in 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. 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. 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. 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. 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! 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. 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. 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. > > 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. 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! 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. 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](https://graphiql-test.netlify.app/) 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. > > 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. 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., The Developer Advocate's Guide to Getting Buy-In, theworst.dev, 01gtw72n3zb47rnfw9wf01tkca.