The number of companies looking to build developer relations teams is on the increase. But what developer relations means to each company tends to differ; some hire advocates and some hire evangelists, some are looking to market to developers and others see devrel as key to capturing feedback and to the success of their product. How do you know the roles and activities that will work best for your company? What’s the difference between these job titles?

What developer relations should mean to a company really depends on what the company’s goals are. For illustrative purposes let’s refer to the Google and Twilio developer relations mission statements, but please remember that a small statement can’t fully reflect everything that their teams actually do.

Google and Twilio missions statements suggest different approaches to developer relations:

At Google:

Developer Relations’ role is to create a vibrant ecosystem of 3rd party developers, by being the interface between those developers and your platform’s product, engineering, and design teams.

Source: What is Developer Relations? - from Why Do We Pay These People Anyway*?

At Twilio:

Our job is to inspire and equip developers to build the next generation of amazing applications. This means understanding what they are trying to do, pointing them to tools and training and generally helping them be successful.

Source: Devangelism at Twilio - from Twilio Heroes

Google’s use of “the interface between” suggests two-way communication between product decision makers and developers using the product. Twilio’s approach suggests more of a one-way educational role in order to help developers use Twilio products.

Michael Mahemoff recently wrote Developer Relations: A Five-Level Maturity Model. In the article he provides a set of levels of maturity for developer relations at a company; from having no devrel through to being able to fully quantify the value of their strategy.

In the context of defining a company’s approach to developer relations we can make a few adjustments to Michael’s definitions:

• None - No promotion, support or product feedback capture
• Informal - some developer relations handled by other functions. PR may be promoting the platform, business development may be partnering with and supporting developers. Developers may give technical talks in the community.
• Partnerships - often stealthy, relations with prized partners (i.e. large, established, companies or those with sufficient resources to build showcases for new features).
• Evangelism - Promoting, explaining, and supporting the platform at scale via conferences, partnerships, and online media.
• Advocacy - A 2-way relationship in which the platform’s own staff sees themselves as not just advocating for the platform, but as advocating for developers using the platform. Feedback on bugs and feature request, and building supporting tools to improve the developer experience.

Based on the above - and again for illustrative purposes only - Twilio may approach developer relations as Evangelism and Google as Advocacy. Michael flags¹ that the right approach depends on the company’s goals for their devrel programme and this is clearly correct. For example, if a company wishes to focus on promotion and awareness, or potentially keep costs down by participating in fewer activites, then they may decide to focus on evangelism. If a company prioritises gathering product feedback from developers then advocacy may be the better approach.

Developer relations has the potential to help in many areas of the business, so it’s important to determine what goals you have for your strategy. Dave McClure’s AARRR metrics can be used as a basis to indicate where and how a devrel strategy can help.

However, I’m going to suggest we make two changes to this:

1. Since developer relations also raises awareness of a product to developers, in a more traditional marketing sense, an additional “A” has been prefixed to this acronym.
2. In some cases developer relations activities may cross over with what some may consider product. To indicate this involvement in product a “P” has been added as a suffix.

These additions result in a new AAARRRP² acronym. Instead of thinking of these as just metrics (although how they can be measured should be taken into consideration - see What’s the ROI of Developer Relations) think of them as potential goals for your developer relations programme:

• Awareness - awareness of the platform and what it does
• Acquisition - sign-up/download/install
• Activation - actively using the platform in an application
• Retention - continue to use the platform, use of new/additional features and use in new apps
• Revenue - pay to use the platform
• Referral - tell others about the platform
• Product - involvement in building and getting feedback on product

There are a wide and varied set of activities that may fall under developer relations. Each of these may align with one or more attributes of a programme that fulfill one or more AAARRRP goals.

• Writing documentation (acquisition, activation, product)
  • Reference
  • Guides (How to)
• Library development (activation, product)
• Quick start apps (activation, product)
• Blog posts (awareness, acquisition, activation, retention)
  • Tutorials
  • Hacks
  • Thought leadership
• Webinars (awareness, acquisition, activation, retention)
• Event sponsorship (awareness, acquisition)
  • Meetups sponsor
  • Conference booth
• Talks (awareness, acquisition)
  • Meetups
  • Conferences
  • Societies
• Support (activation, retention, product)
  • User support system e.g. Zendesk
  • StackOverflow
  • Other forums e.g. Laracasts Discuss
• Pre-sales technical discussions (acquisition, activation)
  • Calls
  • Email
  • Support
• Dedicated forum e.g. Google Groups or Discourse e.g. SmartThings Community (activation, retention)
• Alpha/Beta programmes (retention, product)
• Office Hours (activation, retention)
• Capture developer feedback (retention, product)
• Help company recruitment (awareness)

Successfully undertaking any of these activities results in having a positive impact on somebody, relationships will be forged and trust in the company representative and company itself will increase. This can then increase the likelihood of referral. But these relationships will take time to build.

Revenue is an obvious omission from any of the above activities. Revenue is likely related to the level to which a developer uses a product. Therefore it relies on pricing structure. This can’t be generically fed into the above list of activities, but it certainly can help you focus on the activities or target developers that are likely to provide a larger ROI.

Although I personally don’t believe that anybody is defined by their job title, a job title in developer relations can help clarify what a company and other developers can expect of a person in a devrel role.

So, based on the most common job titles what activities do these different roles take part in?

• Developer advocates may undertake all of the above activities as part of their developer relations programme. In particular see activities marked with product or retention.
• Developer evangelists may focus much more on activities that result in acquisition such as docs, blog posts, event sponsorship and talks. See activities flagged to help awareness and acquisition.

Summary

So, how do you define developer relations and what’s the best approach for your company? Here’s my suggestion:

1. Define the goals that you have for the developer relations team based on AAARRRP (Awareness, Acquisition, Activation, Retention, Revenue, Refferal and Product)
2. Determine the activities that best align with those goals
3. From those activities you can determine whether you’re looking for Developer Evangelists or Developer Advocates

As an additional way of helping myself and others clarify - or at least suggest - an approach to this ongoing role naming debate I’ve built the DevRelOMeter. Based on the activities you wish your developer relations team to undertake it will suggest whether they will be practicing Evangelism or Advocacy.

DevRelOMeter

Are you practicing - or considering practicing - Developer Evangelism or Advocacy?

You can see a standlone DevRelOMeter and the DevRelOMeter code is also on GitHub.

Footnotes:

• ¹ "Any maturity model immediately makes you think companies should be ascending to the top level, but that is not the case and not the intention here"
• ² Please let me know if anybody can think of a first goal beginning with Y. Would love the acronym to be YAAARRRP (it's a Hot Fuzz, Simon Pegg movie reference).

</small>