DevRel, developer advocacy or developer evangelism teams are a part of almost every recent developer-services success. Many DevRel people are hired for their functional responsibilities (we need someone to do X), rather than how they fit into the business.
Clarifying this can be especially hard, as DevRel tends to be most prominent with high-volume, low-touch services. For these types of services, DevRel should provide three key values: zeroth customer, demand generation and scaled customer success.
Zeroth Customer
Zeroth customer is the shorthand term for a set of behaviours coming out of Google DevRel. It means DevRel teams engaging with products as if they were an external customer, and having the skills to clearly and effectively communicate what’s good and bad.
As the product matures, this should expand to user testing and other forms of developer feedback: DevRel can both facilitate this and ensure that the product is maximising the information learned from developers, through adding context and clarifying. This work overlaps with other groups, like UX research.
Where DevRel teams go wrong is not tracking and systematizing this work. Ensuring the product is fit for purpose and has an appropriate developer experience is as important as quality assurance. The process of understanding, reflecting and communicating is vital to everything that comes after.
Demand Generation
Creating leads or inbound traffic is often the purview of marketing, and referring to DevRel as marketing can irritate DevRel folks who come from an engineering background. Other than some general bias, I think that is largely because the image of marketing most engineers have is the “large corporate branding” sort from the consumer world.
A great deal of modern marketing is instead creating and collecting interest through putting out content that people want to engage with, particularly educational materials. Many DevRel teams excel at this kind of thing: conference sessions, blog posts, live streams, video tutorials and more.
Even teams that produce great output don’t consistently have great results, often due to these reasons:
-
Not being clear on the goal of a piece of content when creating it
-
Not having a way of turning interest into a real usage
-
Not measuring effectiveness
Not being clear on the goal is a problem that many marketers don’t face — they tend to know that they’re building a campaign in order to get more developers to sign up for a free trial, for example. DevRel content serves many masters, however. Technical credibility and authenticity are vital, and sometimes that means producing content simply because there is a need in the community. Acknowledging that is important, as is acknowledging when a piece of content should be driving inbound interest. The important thing is to identify what the intended goal is before creating the content.
Turning interest into action can be deceptive. Balancing authentic developer content with a clear drive towards product use is a fine line: there is nothing that will make a developer tune out faster than being overtly “sold to”. There are often strong calls-to-action in DevRel content (“try the service”, “get some credits”) — but that can lead to a dead end where a developer gets the sample or quickstart to run, but doesn’t really see how the product addresses problems they have. Getting that first experience right is vital so that more developers can understand the value of the product. This is also where it can be useful to tie into traditional marketing approaches, such as email drip campaigns, that can help engage.
Not measuring effectiveness is more than just a reflection of not having goals. Many valid and worthwhile outcomes are either hard to measure, or not sensible to optimize around. For example, the various positive results from events or conferences are not well covered by the metrics most people track on them, such as attendance.
The approach should be defining up-front targets for inbound interest over a period (say monthly or quarterly) or a segment (say country or platform) and using those targets to drive the specific mix of engagements from the DevRel team. While it can be hard to measure the effectiveness of an individual activity, that doesn’t mean you can’t measure the effectiveness of the broader approach.
(Scaled) Customer Success
The single biggest driver of new customers is happy existing customers. Developer communities are deep, and word of mouth makes a real difference to adoption. In a high touch situation, having dedicated customer success people proactively checking in on new users and providing guidance helps improve the odds of a happy outcome. In a low-touch world with higher volume (and usually lower prices), the approach needs to vary.
DevRel provides a presence in the community of developers — wherever that community happens to be — and has an opportunity to help developers implement the product better, and get better results. This happens at many scales:
-
1:1, but seen by others. Stack Overflow, mailing lists, forums and chat
-
1:Many. Workshops, tutorials, and training. Often in person
-
Broadcast. Documentation, blog posts, tutorials, guides, walkthroughs and how-tos
There is a large amount of work, theory and experience that goes into managing even one of these properly — from Information Foraging Theory type approaches for documentation to community management and social dynamics in groups of developers. Each of those is worthy of its own discussion, but in terms of positioning DevRel within the business, there are some clearly identifiable problem areas:
-
Not tracking retention and satisfaction
-
Not understanding the developer’s desired outcomes
-
Conflating success with lack of dissatisfaction
Not tracking metrics related to customer success is common. The right metric will be specific to the product and type of developer served, but there are some broadly useful measures. A satisfaction score like CSAT, NPS can track broad trends. Retention rates, in whatever group is the primary target for the product, can be used on both the company level and the revenue level. As before, goals around these should be guiding the mix of DevRel activities rather than measuring individual ones.
Not understanding the developer’s desired outcomes can be due to a focus on the solution, rather than the problem. DevRel teams have a deep appreciation of the technical aspects of their products, particularly if they were involved in launching them, and often focus on those aspects. A lot of really good developer products are broad brushes that can be applied to many problems but can equally be used for toys and never taken into production.
Discovering the triggers that get people to deploy them, and then what actions differentiate those that have a great experience with those that have a bad one is a key part of the story. DevRel can help fill this in — but not alone. Understanding and refining what need the product addresses is a job of the whole company.
Conflating success with lack of dissatisfaction is often driven by the availability of metrics: unanswered Stack Overflow questions, support tickets and so on. There’s truth in there — developers assess community when making product decisions for example, but doing well in those numbers only shows an absence of dissatisfaction, not evidence of real success.
DevRel should be prioritising materials, outreach and interactions that help developers really succeed with the service, and go from just using it to loving it. This also opens up great opportunities to connect the product management and engineering to customers, particularly if the service is still finding its niche.
Aside: Larger companies & high-touch
It’s worth noting that the job does not always stay the same. As companies reach a certain size and complexity, and as businesses move up-market to higher value (and higher touch) buying processes, the demands on DevRel change.
Zeroth customer, demand generation and customer success continue to be valuable services. At scale some other aspects come into prominence such as a reputation management and developer branding. These are always part of the job of DevRel teams, but require a certain size before they can be tackled organizationally — and both topics deserve a separate discussion.