More and more developer service companies are investing heavily to build their own DevRel teams around their company’s products, services, APIs, etc.
However, different companies have different understandings of DevRel: some hire full-time “Developer Advocates”; some hire “Developer Evangelists”; some think DevRel is just “marketing to developers”; others see DevRel as the key to getting product feedback and promoting product success. How do you determine what roles and activities are most appropriate for your company? What’s the difference between different job titles?
What does “Developer Relations” mean for a company? It depends on what the company’s goals are. To illustrate, let’s quote the missions of Google and Twilio’s DevRel departments, but note that a short statement may not present everything a DevRel team actually does.
The role of Developer Relations is to create a vibrant third-party developer ecosystem through two-way communication between developers and the company’s platform products, engineering, and design.
Twilio
Our job is to inspire and help developers build the next generation of amazing applications. This means understanding what they’re trying to do, pointing them to tools and training them, and helping them succeed.
Google uses the phrase “the interface between”, indicating that DevRel is expected to build a two-way communication bridge between product decision-makers and developers (i.e., product users). Twilio’s attitude suggests that DevRel is more like a one-way “educational role”, helping developers use Twilio products.
Michael Mahemoff recently wrote an article “Developer Relations: A Five-Level Maturity Model”. In this article, he explains different stages of development for a company’s DevRel department. From having no DevRel department to being able to fully quantify the value of strategy.
In the context of “how to formulate your company’s DevRel strategy”, I need to make some adjustments to Michael’s definition:
- None - No internal mechanism to support developers or collect developer feedback;
- Informal - Other departments take on some DevRel roles, PR is responsible for brand improvement, BD takes on some developer support tasks, while product developers also have to do some community speaking;
- Partnerships - Relationships with precious partners, usually hidden (usually large companies with enough resources to build new product features);
- Evangelism - Large-scale promotion and support of company products through conferences, partners, and online media;
- Advocacy - A two-way relationship, not only participating in product development but also encouraging external developers to use company products, collecting bug feedback and new feature requests. At the same time, developing support tools to improve developer experience;
Based on the above analysis, the conclusion is: Twilio operates DevRel in an “Evangelism” way, while Google operates in an “Advocacy” way.
Michael points out: The right way to operate DevRel depends on the company’s goals for the DevRel program. For example, if a company only expects brand awareness improvement or participates in a small number of activities to reduce costs, then the company should operate DevRel in an “Evangelism” way. If the priority is to collect product usage feedback from third-party developers, then the “Advocacy” approach may work best.
In summary, investing in DevRel promotes all aspects of a company’s business. So, what are the goals of your strategy becomes particularly important. Dave McClure’s AARRR model can be used as a cornerstone for guiding DevRel strategy.
However, I suggest we make two modifications:
Since DevRel can increase developers’ awareness of a product, according to traditional marketing habits, add an ‘A’ before the AARRR acronym;
DevRel team’s daily activities may involve developer feedback on products, to indicate this, add a ‘P’ after the AARRR acronym;
This creates a new model: AAARRRP model. Rather than just treating this as DevRel metrics, it’s better to treat them as potential goals for your DevRel program (although “how to measure these metrics” also needs to be considered, see: What’s the ROI of Developer Relations):
- Awareness - Product platform awareness
- Acquisition - Registrations, downloads, installations
- Activation - Platform usage activity
- Retention - Continued use of platform, use of new features
- Revenue - Payment for platform
- Referral - Telling others about the platform
- Product - Involves building and collecting product feedback
There are various forms of activities in DevRel daily operations. Each type of activity corresponds to one or more DevRel metrics, thus achieving one or more AAARRRP goals, for example:
| Activity | Related Goals |
|---|---|
| Writing documentation (reference cases, getting started guides, etc.) | Acquisition, Activation, Product |
| Library development | Activation, Product |
| Quick start applications | Activation, Product |
| Blog posts (tutorials, tips, thought leadership, etc.) | Awareness, Acquisition, Activation, Retention |
| Webinars | Awareness, Acquisition, Activation, Retention |
| Event sponsorship (Meetup sponsors, conference booths, etc.) | Awareness, Acquisition |
| Speaking (Meetups, conferences, communities, etc.) | Awareness, Acquisition |
| Product support (Zendesk, StackOverflow, other forums, etc.) | Activation, Retention, Product |
| Pre-sales technical discussions (phone, email, support, etc.) | Acquisition, Activation |
| Dedicated forums (Google Groups, Discourse, etc.) | Activation, Retention |
| Alpha/Beta programs | Retention, Product |
| Office hours | Activation, Retention |
| Collecting developer feedback | Retention, Product |
| Helping company recruitment | Awareness |
Successfully ensuring the results of these behaviors will have positive significance for developers, and the company’s reputation will be improved. This increases the possibility of “Referral”. However, such a relationship between developers and the company takes time to build.
Revenue: Obviously omitted from the above behaviors. Revenue depends on the extent to which developers use the product. Therefore, it heavily depends on the product pricing structure. Therefore, revenue cannot be simply added to the above list, but it is certain that: temporarily not considering revenue can make you focus more on activities and target developers that are likely to bring large ROI.
Although I personally don’t agree with defining a person by job title, job titles reflect how the company or other developers position their role in the DevRel team.
Therefore, based on common job titles, let’s see what activities different roles participate in?
Developer Advocates: Take on most of the above responsibilities as part of DevRel work, especially responsibilities related to product or retention;
Developer Evangelists: May focus more on user acquisition-related activities, such as: writing documentation, publishing blogs, sponsoring events, speaking. See more activities related to “awareness” and acquisition.
Summary
How to define DevRel? And which way is most suitable for your company? Here are my suggestions:
- Formulate your expected goals for the DevRel team according to the AAARRRP model;
- Choose activity forms that best match these goals;
- Based on these activity forms, determine whether to recruit Developer Advocates or Developer Evangelists;
As another way to help myself, or at least a suggestion. For this ongoing debate about job titles, I created a DevRelOMeter project - based on the types of activities you expect the DevRel team to carry out, it will suggest whether you should do evangelism or advocacy?
DevRelOMeter
Are you participating in or considering participating in the developer relations career?
https://leggetter.github.io/devrelometer/
Author: Phil Leggetter
Original: Defining Developer Relations
Compiled by: Jack Jin
Reprinted with permission: Developer Relations »
