In this post I’ll explain the difference between evangelism and advocacy
For 5 years, I had the job title “Technical Evangelist” it was an interesting title and frequently resulted in questions and comments. Developer evangelists and technical evangelists were popping up at a number of high tech companies. But, over the past 3 years or so a new job title has emerged: “Developer advocate”. What is the difference?
Dictionary Definitions
Let’s start by looking at the definitions.
Evangelist
According to Merriam Webster an evangelist is:
- “A writer of the 4 Gospels” (definitely not the definition that applies here)
- “A person who evangelizes”. (That’s not very helpful, so need to look up their definition of evangelizing… here we go: “to preach the gospel to”; “to convert to Christianity”.)
- “An enthusiastic advocate”
It’s that third definition that seems to fit the spirit of the technical or developer evangelist role. However the other definitions are still very much entrenched in most peoples psyches. In fact, if you look up the definition of evangelist in the Oxford dictionary you only see two definitions:
- The writer of one of the four Gospels (Matthew, Mark, Luke, or John)
- A person who seeks to convert others to the Christian faith, especially by public preaching
The Oxford dictionary doesn’t recognize any non-religious definitions of evangelist. This is likely why I heard so many jokes about trying to convert people to Microsoft or preaching the word of Microsoft. Fortunately, I just had fun with this and would occasionally do my best tele-evangelist imitation “All hail the mighty Microsoft! I shall cleanse your soul from the clutches of Google” and then stop to explain that my real job was to help developers understand how Microsoft technology could help them.
Let’s return to the 3rd definition in Merriam Webster: “An enthusiastic advocate”. Technical and developer evangelists are enthusiastic. They have passion for the technologies they represent. They share that passion by delivering workshops, writing tutorials, and presenting at user groups and conferences.
Advocate
According to Merriam Webster an advocate is:
- “One who pleads the cause of another”
- “One who defends or maintains a cause or proposal”
- “One who supports or promotes the interests of a cause or group”
All three definitions emphasize that an advocate acts on behalf of the group, promoting their interests, pleading and defending their cause. A developer advocate should support developers not preach to them.
Advocates perform similar activities to evangelists: delivering workshops, writing tutorials, and presenting at user groups and conferences. But, a true advocate always does so with their customer in mind first instead of the company.
Whether I am an advocate or an evangelist, If I work for a particular company, I am going to be promoting their products!
Having said that, let’s make one point clear: Whether I am an advocate or an evangelist, If I work for a particular company, I am going to be promoting their products! But, there is an expectation that an advocate does so in a way that puts the developer or customer first. Good evangelists do this as well, but the shift to advocacy from evangelism is an done to emphasize a customer first focus.
An Advocate and an Evangelist walk into a conference…
Let me give you a specific example. An evangelist might go to a conference and deliver a session called “Introduction to facial recognition APIs”. This presentation teaches you all you need to know to implement the API.
An advocate would be more likely to deliver a session called “How to leverage facial recognition to improve security”. This session teaches you how facial recognition is useful for security applications and how to leverage Facial recognition APIs to do it.
Both presentations can be very effective. Both presentations could be amazing sessions to attend. Both sessions provide the same core content: How to implement the company facial recognition API. But, the advocate’s presentation puts a different spin on it, the title itself tells you this session will help you with security. In designing content and talks an advocate should always ask themselves how does this presentation help my audience? How does this support them?
Evangelism vs Advocacy
Inbound vs Outbound communication
Because the advocate is seen as someone who pleads and defends the cause of their customer they may also take on an additional responsibility: collecting feedback from customers and sharing it with product teams.
The evangelist was generally an outbound role, they presented and shared what they knew. There job is to drive awareness and adoption of the product.
The advocate role should be outbound and inbound
The advocate role should be outbound and inbound. In addition to presenting and sharing what they know with others, they should also collect feedback from the community and represent the customer needs back to the product teams.
Preparing for inbound communication collected by advocates
Many product teams are starving for real customer feedback and appreciate the opportunity to get feedback through the advocates.
I’m an advocate presenting at a conference. A developer comes up to me after my talk and explains they tried to use the API but there’s a parameter missing that makes it difficult to use. Fantastic, this is exactly the sort of real world feedback we want to collect, but you need to put some thought into what you do with that feedback after it’s collected otherwise it can get lost.
How will advocates provide feedback to the product teams?
Feedback may be provided to the advocate verbally, through social media, or by email. How do you want the advocate to physically share that feedback with the product teams? There are a number of options: Email; Feature request forms; Create an item in the backlog; Reporting in meetings or stand ups; The advocate could also point the developer to a community feedback form where the developer can provide feedback to product teams directly.
How frequently will advocates provide feedback?
Customer feedback does not follow a schedule but your product teams probably do. Do you want to develop a rhythm for your advocates to share feedback with the product teams or will they share it ad-hoc as it comes in?
How will you prioritize feature requests from advocates?
Customer feedback collected by advocates is just one input into your requirements. The product team has a constant backlog of requirements, bugs, and feature requests from the product roadmap; paying customers; beta testing; focus groups, and more.
How much weight or priority do you assign to feedback from your advocates? The answer is the ubiquitous “it depends”. Priority is usually based on some combination of effort, urgency, and impact. You would likely assign a different priorirty for feedback from someone actively using and paying for the product than you would for feedback from someone just trying it out at a hackathon.
You may need your train your advocates to collect enough information to prioritize feedback appropriately.
Communication and expectations
If a customer provides feedback through an advocate, what are their expectations? Will they ever know if their product feedback was shared with the product team? Will they know if their feedback was considered but is not feasible at this time or whether it resulted in a new feature request? Who is responsible for following up.
If the advocate forwards the feedback they received verbally in an email to the product team is their work done? Is the advocate responsible for following with the product team to find out if the feature requested is already in the backlog, or that the error message reported is in fact just an error you receive if you are using the incorrect Python library.
If a product team member has additional questions about the feedback “What version of Python were they using when they encountered this error?” is there a way to reach back to the customer? Does the product team member reach out directly or is communication done through the advocate?
Adding the inbound feedback to the responsibilities of an advocate can result in a lot more work, but it could also result in a better product for your customer!
Summary
Having evangelists or advocates can benefit your company hopefully this post helped you understand the difference in philosophy between them.
If you found this post helpful you may want to read additional developer relations posts. If you are looking for help with your developer relations work or you are interested in having me speak at your event, reach out on Twitter or LinkedIn.
HockeyGeekGirl 