- Why Make an Impact as a Developer Advocate?
Tips for Making an Impact
- Team and Management
- Understand Expectations
- Cultivate a Strong First Impression
- Identify What the Company Cares About
- Use the Product as a Beginner
- Document Your First-Time Experiences
- Create Fun, Memorable Demos
- Integration with Widely Used Frameworks, APIs, and Tools
- Make It Practical
- Listen to Developers
- Thought Leadership
- Teach Your Company
I find it hard to engage in discussions about my strategy for building a following and driving content engagement. While I never shy away from amplifying my content on social media, discussing these topics fill me with imposter syndrome, so I usually respond with, “I don’t know. I just do it.” Additionally, for me to answer questions coherently, I need space to think and organize my thoughts. However, beneath these discussions lies a more profound question: How can a developer advocate genuinely leave a lasting impression?
As much as I would like to deny it, I think it’s evident that within almost two years working as Developer Advocate at GitHub, I’ve made a significant impact both within the company and across the developer community. Instead of being bashful, I’m choosing to embrace my influence and share my knowledge in a blog post.
Keep in mind:
- These strategies worked for me, but developer advocacy is not one size fits all because every company and developer community has different needs and goals.
- This blog post is tailored specifically to Developer Advocates and may not directly apply to the broader spectrum of Developer Relations roles. Roles such as community managers, technical writers, and developer marketers have different objectives and responsibilities.
- It's completely fine if your aspirations don't align with creating a sweeping impact. Your focus can be on diligently executing your role, and that's perfectly valid. I’m not asserting that you must do this; rather, I’m aiming to provide insights for those who wish to explore that path.
- I’m primarily a content focused Developer Advocate with coding and community engagement forming complementary facets of my role.
People like to deny it, but Developer Advocates are influencers. I don’t say influencer in the sense that we’re on Instagram taking pictures with flat tummy tea, but we influence the developer community and our companies.
Sometimes, the impetus driving one toward developer advocacy originates from a sense of disillusionment with the world of software engineering. This pivot opens doors to:
- Exploring and experimenting with new technologies.
- Supporting fellow developers and having fun.
- Establishing a public presence and engaging in meaningful conversations.
- The opportunity to travel and connect with communities worldwide.
While we do get to do these things, companies don’t pay us 6 figures to have fun. Many companies hire Developer Advocate to spread awareness, and ensure their products thrive, leading to increased revenue. We can achieve this through community engagement, conference talks, hands-on coding, and compelling content. The trust established within the developer community directly translates into a willingness to embrace our company’s products. The ultimate goal is to create a ripple effect where the knowledge you share with developers inspires them to educate others, thus amplifying the reach and impact.
But, our job goes beyond promoting a tool. You don’t want to encourage people to try out a technology that’s not actually good or serving them. That’s inauthentic and irresponsible. Our role includes providing honest feedback to our colleagues – whether it's product managers, engineers, or leadership – on areas that need improvement. When you've nurtured strong internal relationships and your impact is recognized within your company, it’s easier to guide the direction of the product.
While Developer Advocacy isn't a popularity contest, nor does it involve forcing people to use your company's technology, your goal is to cultivate relationships and establish a sufficiently strong reputation within both the developer community and your organization. This enables you to best serve developers with integrity and bring value to your company.
Your job is to make an impact that reverberates.
Working with a team and manager that sets you up for success is key.
Stay away from managers that:
- Place blame
- Constantly change expectations
- Aren’t invested in your success
Lean into managers and teams that:
- Regularly give positive feedback
- Occasionally give you constructive criticism, so you can improve
- Find opportunities for you to grow
- Positively mention your name in circles that you’re not in
My personal experience
I’m grateful that I had good management throughout my tenure at GitHub because it helped lay a foundation for success. I had the opportunity to do activities like speak in the GitHub Universe Keynote because my colleagues and managers advocated for me and supported me.
You can gain insights and make a good impression as early as the interview. (I’m not great at this, but I do see how impactful it is when people are good at this). During the interview phase, get an understanding of why the company is hiring and the strengths and weaknesses of the team you'll be joining. People struggle to get dev advocate jobs because they don’t understand why the company is trying to fill the role.
It’s important to understand what the company expects from you because you do not want to work at a company as a developer advocate with misaligned expectations. For example, if you are hoping to maintain and build the community, but they’re hoping you’re mostly going to be writing code, you will be very unhappy and so will the company.
Ask yourself the following questions:
- What’s the company excelling at?
- What do you excel at?
- Do those align?
Jason Lengstrof made a video where he talks about the key to getting a job in Developer Relations is knowing what the company is looking for. I agree with this sentiment because it also helps you determine how you’re going to shine.
I’m not great at first impressions because I get super anxious. I believe there are several moments to change people’s minds about you. However, first impressions help set the trajectory of your time at the company. When you make a positive first impression, it’s easier to get buy-in from colleagues and support from the developer community.
My personal experience:
After I got my offer, I made my first contribution to open source, and I wrote a blog post called “Conquering the fear of contributing to open source”. I tweeted the blog post on the first day of my job at GitHub.
Beyond views and retweets, I was asked to do a keynote at All Things Open on this topic. And I turned this into a talk for other conferences. I didn’t write the blog post in hopes of speaking at a conference. I was just over eager about the job, but it helped to craft my brand as authentic, vulnerable, approachable, and passionate about open source.
This showed my team my work’s caliber and resonated within the developer community, placing me on their radar.
Check out my tips on starting your first DevRel job to learn more.
By identifying your company's goals and aligning your efforts accordingly, you can ensure that your work resonates with the company's strategic direction and contributes positively to the developer community's understanding and adoption of key tools. Read your company and team goals occasionally because those goals will evolve over time.
Here are some helpful questions to ask yourself:
- Does this product make the company more money?
- Did they invest heavily into this product?
- Are they talking about this product a lot in meetings?
- Does it seem like this product aligns with industry trends?
- Is the company and its customers still learning how to use this product and how this product could be valuable?
My personal experience:
For me, GitHub Copilot seemed like something I should invest my time in. When I started working at GitHub, I initially focused on open source and GitHub Pages, but as the company's focus shifted to tools like GitHub Copilot and GitHub Codespaces, I realized I needed to approach my job more strategically. GitHub Copilot received substantial investments from GitHub, Microsoft, and OpenAI. However, throughout the developer community there were mixed reviews and miseducation about how GitHub Copilot worked. It was also evident that AI pair programming tools and generative AI were an industry trend. At the time, GitHub was still experimenting with how developers could use GitHub Copilot, and developers were still trying to learn how to use it too.
For me, this was a serendipitous time and opportunity to learn about GitHub Copilot. I wanted to figure out: Were the developer complaints valid? If yes, I would try to work with my coworkers to meet their needs. Were they misinformed? If yes, I would figure out how to educate them. And if it was both, I would do both.
One effective strategy for aligning yourself with your company's goals and deepening your impact as a developer advocate is to fully immerse yourself in the products or tools you're promoting – from a beginner's perspective. It's common for companies to grant early access to developer advocates and other staff members before a product is made available to the general public. Use this as an opportunity to transition from a state of relative unfamiliarity to true expert before the product's official launch.
My personal experience:
When GitHub Copilot came out, I experimented with it. I was skeptical at first. My initial impression: So is GitHub Copilot autocomplete that sometimes doesn’t autocomplete? What’s the point?
As developers started to question the validity of the product and even direct questions towards me, I increased my usage and began to dig into how the tool actually worked. I wanted to confidently and knowledgeably respond to their inquiries.
Over time, I went from skeptic to enthusiast. It's easy to dismiss an innovation at first glance, but using the product to gain my own perspective enhanced my ability to authentically advocate for the product.
Many times, we prefer to wait until we have an elaborate, complex implementation of a tool, but some products need “getting started” or “hello world” examples.
My personal experience:
At first, I couldn’t get GitHub Copilot to reproduce anything. It would only do something for the first time and never do it again. I finally found success in promoting GitHub Copilot to write a binary search algorithm. I took that example and wrote about it.
Keep in mind, the product you advocate for doesn’t have to be new or groundbreaking. it’s new to you, and it’s new to someone else, so your perspective on getting started is valuable. Sometimes, I would even tweet out my excitement when I got GitHub Copilot to do something that I didn’t expect it to do! Knowledge sharing before you gain ultimate expertise is super valuable for anyone who is a beginner user of that product.
People may argue with me about this, but if you’re trying to create awareness about a product, all of your demos don’t have to be practical. It’s okay to create a few demos that are eye-catching or fun to make people curious about the product. To make it fun and memorable, try integrating trending pop culture phenomena, emerging technologies, or both.
The first time I realized the value in small, but creative demos was when I saw Lizzie Siegle do a presentation about Twilio. In her demo, she calls and messages people in the audience, then they get “rick rolled.” Out of all the talks and demos that day, Lizzie’s demonstration stood out. Here are a few developer advocates who I believe are also great at producing creative demos: Colby Fayock, Salma Alam-Naylor, and Hassan El Mghari. One of Hassan’s most popular demos is RoomGPT, which uses AI to redesign rooms.
Reuse that content – take your demo and turn it into a blog post, a conference talk, a webinar, a workshop, a tweet, and a TikTok.
My personal experience:
“I wrote this tweet with Copilot” became almost a meme for me. Every time I presented about GitHub Copilot, I did a demo where I would write a comment prompting GitHub Copilot to generate the code that calls the Twitter API to post a tweet that said, “I wrote this tweet with Copilot and I’m at x conference right now.” True, nobody would typically use GitHub Copilot to publish tweets, but that’s not the point. The goal was to spark awareness of GitHub Copilot. As a result, the tweet:
- Piqued people’s interest: At the time, the developer community was popping on Twitter and I wanted people to wonder “How could GitHub Copilot write tweets? Should I check out this product?”
- Community engagement: I saw other people tweet, “I wrote this tweet with Copilot” meaning they tried out the demo too.
- Invitation from conferences: Some conference organizers invite me to do the talk at their conference because they wanted me to post that I wrote a tweet with Copilot, and I was at their conference.
- Some practical utility: Even though the demo is silly, it showed that GitHub Copilot can help you interact with an API in a language that you are unfamiliar with.
When you build with and use a product you're advocating for, you become an expert in it. However, you don’t just have to keep the product within your company’s ecosystem.
Here are my reasons for integrating other technologies with your product:
- It helps you become aware of the limitations of the product
- It makes it easy for developers to integrate the product into their daily workflow. For example: If they’re often using TypeScript, but your demos are only in Python, they may not realize you can use your company’s product with TypeScript.
- You may catch the attention of people who built those frameworks or build with those frameworks, which presents an opportunity to collaborate.
As a result, you can introduce a novel avenue to an entirely fresh audience.
My personal experience
I realized the importance of building examples with other frameworks when people would ask me, “Does this work with React or Astro?”, but I didn’t know the answer. People would also ask me things like does GitHub Copilot work better if you’re using it in a new project or using it in a large codebase with legacy code. I could try to ask other developers for their experience, but with a product so new, I felt more confident saying yes or no if I’ve tried it out on my own.
So, I started to build little projects with different frameworks. I also used GitHub Copilot when contributing to large open source projects. Now, I can confidently answer, “Yes, and here’s how you do it.”
As you build and integrate the product into your daily workflow, the use cases of the product become more evident. Start taking notes and creating content around these use cases. It’s helpful to lean into your developer community to figure out how they are using the product, too. There may be experts among your users that you can feature and collaborate with.
My personal experience
My team and I helped people see the value in GitHub Copilot by showing them that you can leverage GitHub Copilot for:
- Adding code snippets to documentation
- Syntax recollection
- Unit testing
I believe this encouraged developers to adopt GitHub Copilot because they realized it was more than just autocomplete.
As you’re creating content, take a look at the questions and confusion developers have about the tool you advocate for. You may find their inquiries on social media platforms or your company’s discussion board. You can create content answering those questions. I also suggest maintaining a periodic session where you meet with product managers to express the pain points of users and you all can work together to figure out how to solve them. This way you can improve the overall developer experience through content and product improvements.
My personal experience
I often saw development teams wonder if it was worth it to purchase GitHub Copilot for Business. In turn, I wrote a blog post called, “Can GitHub Copilot be a valuable investment for my team?”
I also saw many people complaining that GitHub Copilot’s suggestions were inadequate and distracting. I empathize with that experience. However, I had a ton of tricks for getting optimal results for GitHub Copilot, so I wrote a blog post called, “A Beginner’s Guide for Prompt Engineering with GitHub Copilot.” To my surprise, my CEO shared this blog post with customers to improve their experience with GitHub Copilot. Writing that blog post strengthened my impact on the company internally.
There is merit in going beyond how to use the product by providing your thoughts on how the product can transform the industry. We can start productive discourse by challenging our industry leaders.
My personal experience
When people argued that GitHub Copilot could limit learning, I wrote a blog post called, “How I’m using GitHub Copilot to learn p5.js”, where I talk about taking an intentional and strategic approach to learning a new programming language alongside an AI pair programmer. At the Microsoft Ability Summit, I spoke about using GitHub Copilot to provide psychological safety.
I also wrote blog posts and delivered conference talks about how GitHub Codespaces and other cloud-based IDEs are catalysts for diversity, equity, and inclusion.
Like I mentioned earlier, we are influencers and we have the power to invoke a paradigm shift, challenge norms, and start conversations that can reshape the tech industry.
Ask yourself the question: How can we leverage this developer productivity tool to ethically improve our society?
Developer Advocacy is even more effective when other people in the company are advocating for the product. You’re not the only one who needs to be knowledgeable about your company’s developer tools. Some technologists within your organization like to speak at conferences and write blog posts, too! There are individuals in customer success, support, product, engineering, legal, and leadership who may need to know more about how the product works, so they can successfully do their job. As a developer advocate, you may have the most experience using the product, so share that experience internally.
My personal experience
As GitHub and Microsoft have been focusing more on artificial intelligence and GitHub Copilot, my coworkers have been looking to increase their knowledge on the product, so they could best do their jobs. Some people may have initially been on different teams, but now they’ve moved to a Copilot-focused team. To assist in the knowledge transfer, I shared slide decks and repositories with Microsoft and GitHub, so that anyone can feel confident speaking about GitHub Copilot. I also did presentations:
- Introducing Customer Success managers at Microsoft to GitHub Copilot.
- My coworker, Juan Pa encouraged me to teach our GitHub Campus experts on how to talk about GitHub Copilot, so I did.
- I refined the talk for GitHub’s Day of Learning, then I delivered a presentation to my company on how talk about GitHub Copilot.
In essence, I’m creating more knowledgeable advocates for the product.
The beauty of this is now I won’t be one of the few people at my company that can speak about GitHub Copilot. Other people can, too! Less work for me, haha.
By embracing authenticity, cultivating expertise, and engaging with tools from a beginner's perspective, you're not just advocating products – you're shaping the narrative of innovation itself.
As you code, create, and collaborate, remember that your influence extends beyond the immediate. It's in the connections you foster, the solutions you inspire, and the conversations you initiate. I believe developer advocacy isn't just about tools; it's about catalyzing change and leaving an indelible mark on the tech landscape.
So, step into your role with confidence. Your journey is a beacon, guiding others through the ever-evolving world of technology. Embrace the power of your impact, and know that your dedication will echo through the codebase, the community, and the future of tech.
The blog post was filled with my opinions, but it’s not the only way to do developer advocacy. What approaches do you take to help you make an impact within your developer community and within your company?
Please note: I used ChatGPT to write my conclusion because I am not great with writing conclusions.