What I've learned from 6 years as a developer advocate

I’m about to reach six years as a developer advocate at Amazon Web Services. Two years ago I shared a retrospective look at my first four years as a developer advocate and many people have told me that article was helpful for them. In this article I’m going to share my top learnings from working six years in “this incredibly interesting role, at one of the most interesting companies in the world, on some incredibly interesting technology.” The content of this article is adopted from an internal lightning talk I gave for Amazon employees earlier this year.

What is a developer advocate?

When I interact with developers at conferences, its not uncommon for them to ask me “What do you do as a developer advocate?” or “How can I become a developer advocate?” At the same time there is a lot of demand for developer advocates. My inbox is always full of companies who are looking to recruit someone to be a developer advocate in their organization, or even help build out their first developer advocacy team.

When startups or even established companies think about hiring a developer advocate they often imagine they are hiring a specialized marketing expert to help them reach developers.

They are right! A good developer advocate is a specialized expert at marketing to developers. But they are also much more.

The public facing persona of a developer advocate is usually the first thing you will see:

• That person standing up there at the conference giving a talk
• That person with all the followers on social media
• Blog articles and documentation with their name on it, or sample code on their Github
• Maybe you’ve watched their Twitch streams or YouTube videos.

But developer advocacy is more than just outbound content creation and marketing. The other side of developer advocacy is arguably the more important, defining aspect of the role:

• Gathering feedback from social media posts
• Monitoring Github issues on open source repositories
• Customer meetings and internal business review meetings
• New product or feature design meetings
• Empathy workshops and onboarding training for new employees who will work on the product
• Prerelease bug testing and validation
• Roadmap prioritization
• Mentoring new developers and product managers

A developer advocate is there at the boundary between external customers of a product, and the internal folks who are building a product. The role of a developer advocate is to create and accelerate the free flow of useful information in both directions: existing and potential customers want to know more about the product, and internal builders of the product want to know what they need to do to make existing and potential customers happier.

Traditional marketing is focused on pushing the target audience down a funnel towards a specific destination, starting from demand and lead generation, to getting someone to sign up and enter their credit card details. At this point most marketing folks will rightfully say “Mission accomplished… my job is done and now it is your turn”.

In contrast the work of a developer advocate is actually just beginning at this point. The developer advocate isn’t just concerned with getting someone to use a product or service. Are the users happy with the service? Are they unhappy? The developer advocate must care about this, and do work in response to either scenario.

At Amazon we like to build “flywheels”. The idea behind the flywheel is to build a process that generates an outcome. This process should feed back into itself such that each time the flywheel goes around it generates more of the outcome, and in the process it generates a bit more momentum and speed, so that it can produce more of the outcome even better.

Developer advocates at AWS are involved in spinning three flywheels:

• Service adoption: The DA identifies happy, satisfied customers, and helps amplify their voice and success stories to a broader audience. This then attracts additional developers to try the service, and when these new developers are also satisfied then the developer advocate amplifies them as well.
• Service on-ramps: Sometimes developers want to like a product or service, but it has a really steep learning curve that makes it frustrating to get started. Developer advocates make better on-ramps for new developers so that they can become satisfied faster or at least avoid becoming so dissatisfied that they give up.
• Service features: Developers may not like the product or service because it doesn’t meet their expectations. Features are broken, or the product can not be used without an additional feature that has not yet been implemented. A developer advocate helps internal teams figure out what needs to be done to fix these issues, and then when the service features have been adjusted the developer advocate makes sure potential customers find out about these fixes, so that they can give the service another try.

Together these three flywheels work in tandem to make sure that not only is a service monetarily successful, but it also makes developers happy, and builds a community around the product.

It is very important for a developer to educate their own organization on what they can accomplish for them. I think its very important to be part of the onboarding plan for new hires, especially if they come from companies that don’t have developer advocates, or who have developer advocate teams that are purely outbound marketing.

Developer advocates interact with product managers, engineering managers, and software engineers. It’s important to set the right expectations about what you can do for each of these groups as a developer advocate.

Be an active, effective voice

One of the factors that can hold developer advocates back from being an effective voice in their engineering orgs is imposter syndrome. I remember when I first joined AWS it was a bit intimidating to be joining such a large company with so many great engineers. I thought to myself: “I know I have some good ideas for the product, but surely with so many smart people working at AWS they must have already thought of everything that I can think of.”

The reality is that although AWS as a whole is a collection of brilliant people, there is no single person who has all the knowledge. My knowledge may overlap with the knowledge of many other people, as their knowledge overlaps with my own, but I have unique knowledge that they don’t, just as they have unique knowledge that I don’t yet know.

One of the leadership principles at AWS is “Hire and Develop the Best”, and it’s important not to forget the “develop” part of that. AWS has employees that are actual legends of the industry with decades of experience. It also has interns and junior developers fresh out of college, who have barely worked on production systems yet.

No matter what level you are at you have something to offer. Junior folks bring in fresh outsider perspectives, and relevant experience living life as a customer. They might be more in touch with the latest popular trends and tools. Meanwhile senior folks have tons of knowledge from practical experience and application, which gives them insight into best practices and tradeoffs that a newer engineer may not know yet.

Knowledge flows in both directions, from junior to senior, and from senior to junior roles. You can help in both cases.

But it’s hard to help from a passive position. Let’s look at some examples of steps along the path from being passive to being an active voice.

Becoming a proactive developer advocate usually starts with a thought, something like “I wish customers were happier with the product”. You’ve noticed a problem, which is good because it means that you aren’t oblivious, but at this point it’s just a wishful thought, no action. It’s also ambiguous:

• What are customers unhappy about?
• How can it be fixed?
• Who can fix it?"

Last but not least, things are currently asynchronous. There is no timeline or plan about how to make the wishful thought into a reality.

The next step is what I think of as the “vent in Slack” phase. And if you work with me you might know that I do this from time to time… Maybe I drop into the #product-feedback channel in Slack and say “I just heard someone complain about this recurring problem with the product”.

So this is making some progress, and it takes the first step towards action, but at this point it’s just amplifying a one time reaction in the moment. It’s also still ambiguous. Who should care about this piece of feedback? The developer advocate is relying on other people’s initiative to read the #product-feedback channel, understand it, and make the plan. Worst of all it’s still asynchronous: no planned next steps, no timeline.

For the next step perhaps the developer advocate writes up a document summarizing the trend in customer feedback and complaints. The document gathers up feedback from multiple sources, and synthesizes that feedback into a useful collection. The developer advocate shares this document in the #product-feedback channel once again.

Once again, this is getting better. It’s gone from no action, to a reactive action, to a proactive action that isn’t just a point in time thing. However, this is actually still ambiguous. Who was supposed to read this document that was shared to the general channel? What stakeholders would be most interested in this document and why? And this is still an asynchronous ask. When should someone read the document? Everyone is busy with something they are working on, so are they actually going to take the time to read your document?

Next step: the developer advocate takes the document that they wrote up, and direct messages a principal product manager: “Hey I noticed this trend in customer feedback and wrote up a summary. I wanted to schedule some time with you to read it and discuss how to get something on the roadmap to fix this issue. Is this calendar slot tomorrow okay?”

Now we are starting to hit all three things that make a developer advocate into an effective voice:

• Proactive - A document has been written, a key stakeholder has been identified, and a meeting has been scheduled to discuss it with him or her.
• Specific - The asks are very specific. Rather than just shouting into the void the DA has brought a specific ask to a specific person with a specific objective: get a fix onto the roadmap.
• Synchronous - Rather than the DA asking someone to find their own free time to read the document the DA has scheduled a specific time to read and review the fledgling document, and they can know that this will happen at that specific time.

Next: the developer advocate has partnered with the PM to write a Press Release (PR) and Frequently Asked Questions (FAQ), document or PRFAQ for short. He or she schedules a meeting with the product manager team to review this document and make a plan to get it on the roadmap.

• Proactive - This is no longer just an idle complaint. The developer advocate has identified the problem, gathered info about the problem, and proposed an actual solution to the problem.
• Specific - There is a specific suggestion about how to solve the problem, and there are specific proposed steps being taken: present to the PM team, and get the solution on the product roadmap.
• Synchronous - The next step is a classic Amazon style meeting: the first 15-20 minutes is spent with everyone reading the proposed document and leaving comments, and 45 minutes are spent discussing comments and next steps.

Hopefully this series of steps shows how you can be an effective voice inside your organization. It’s not always easy to do all these steps. Usually I myself just start out with a lazy Slack channel complaint message. But the best results for me have always come from pushing ahead into more proactive, more specific, and more synchronous work.

Find and handle feedback effectively

A large part of being an effective developer advocate is finding and handling feedback effectively. Let’s start with the first thing: finding the feedback.

There is feedback everywhere, but I like to organize feedback into internal and external feedback.

• External feedback is feedback that I am directly sourcing from talking to folks about the product online on social media, at events, from reading Github issues, etc.
• Internal feedback is feedback that comes through from other internal sources. Remember earlier when I mentioned that complaint in Slack? Often there are folks like solution architects or account managers who surface complaints from customers into internal channels, but don’t necessarily know how to take things the rest of the way from there. As a developer advocate you can help them with that.

One important thing to remember is that not all feedback is easy to get. Sometimes you have to look deeply beyond the easily visible feedback to get the feedback that you might have otherwise missed. There are three main types of feedback that you might miss, but which can still be invaluable feedback to gather:

• Feedback from folks who loved the product so much that they were willing to overlook some issues that bothered them. They still had these issues, but they suffered through them without complaining.
• Feedback from folks who were so confused that they just gave up without bothering to invest deeply enough to have real complaints yet.
• Feedback from folks who were so angry about their experience that they didn’t want to invest more time to writing up feedback.

Always make sure that you are getting the full set of feedback, not just the feedback that was easy to get.

As a developer advocate I like to look at the following sources of feedback in particular:

• New developers - If the product fails to attract new developers it runs the risk of becoming irrelevant to the next generation of developers, who will chose to use new tools instead.
• The Builders - You can only get so far by selling a product to VP’s and C-suite executives. If builders can’t actually build on the product it will fail in the long run.
• The Architect - Good VP’s and executives look to smart architects within their org to analyze important technical decisions ahead of time. What does the architect look at and what might have been missing or wrong, that caused an architect to reject this product?

At the same time there is a lot of feedback out there which is helpful to no one. I try to protect product and internal engineering teams from bad feedback and wasted time:

• The lazy person - Sometimes people just aren’t willing to put in any effort at all. They want all solutions handed to them, they refuse to read documentation or even try to understand fundamentals. They may be just trying to use you as their own personal Google. I handle this by asking “What have you tried so far?” This very quickly identifies whether the feedback giver has put in an honest effort and failed through no fault of their own, or whether they just didn’t try at all.
• The hater and The stubborn - Some people are just haters or extremely stubborn in their opinions. If their personal viewpoints are not compatible with the basic principles behind how a product works then sometimes you must filter out the feedback because it is just a waste of time for everyone. And someone who has nothing but insults without any constructive feedback is never useful to the broader team. They will do nothing but make everyone feel bad.
• The cheapskate - Some people want everything for free. The feedback of a person who never intends to become a customer can’t be valued as much as the feedback of an actual customer, or someone who actually wants to become a customer.

Once useful feedback has been located it is time to attach extra context to the feedback. This includes things like:

• Job Role - Who voiced this feedback and what was their role in their organization?
• Company type - Was this feedback originating from someone at a small startup or at a massive Fortune 500? Was it coming from someone working on a solo project, or an open source project?
• Experience Level - Was the feedback originating from someone totally new to this product area, or someone who was super experienced in this product area?
• Adoption blocker - What was their level of concern about this feedback? Was it a minor issue that annoyed them a little bit? Or was it a complete blocker that made them hate the product entirely?

It is very important to attach this extra context to feedback so that you can identify trends and areas of specific concern. For example maybe the product is working for one group of people, but missing a large part of the market entirely because of easily correctable issues.

The next level of feedback collection is to start to aggregating the feedback. Try to identify additional data points like:

• How long have people been asking for this?
• How many total asks? And how often do you hear asks for this?
• What is the total size of the addressable market for this ask? Is it possible that there are way more people out there who also want this?
• Last but not least, how often have you personally asked for this from the team? Is this the first time, or is this something you’ve asked for before?

Feedback rarely arrives at the perfect time. Customers who are asking for something tend to need it fast, while developers who would be able to work on this ask tend to have a backlog of work to do. The developer advocate sits at a critical place between the external customer and the internal team and needs to have compassion and empathy in both directions.

Sometimes its necessary for a developer advocate to find workarounds for customers because the service team can’t fully address the feedback right now. And sometimes the developer advocate has to compromise on the “ideal fix” to come up with realistic deliverables that the internal team can build in the short term.

The developer advocate earns the respect of both external developers and internal developers by having compassion and empathy for the needs of both groups. This is the single most critical contributing factor to being able to do the role effectively.

Conclusion

This article highlights some of my learnings working in the role of developer advocate at AWS for almost six years now, with a specific focus on the inbound side of developer advocacy. Everyone tends to understand the outbound side: what it means to be a social media influencer or public facing persona, but I find the inbound side of developer advocacy to be a bit more poorly explained and mysterious to most people.

I hope this is helpful to you if you are interested in becoming a developer advocate, want to build a developer advocacy team within your organization, or just want to better understand the developer advocates in your circle.

As always if you have any questions or comments feel free to reach out on Twitter: @nathankpeck