DevRel, or developer relations, is a process for nurturing mutually beneficial relationships between organisations and software developers.
In other words, it’s a collection of strategies and tactics that help companies to work better together with software engineers. Exactly what developer relations teams do and why they do it depends on what their organisation needs.
So, what is it that developer advocates and other DevRel professionals actually do? And why do companies invest in developer relations?
Let’s start with the why.
From one company to the next, the strategic reasons for pursuing DevRel can vary significantly. Company X, for example, might do DevRel to drive adoption of their API, whereas the Y Corp team might be tasked with improving the company’s ability to hire software engineers.
Those differences in the why lead to different DevRel strategies, tactics, and definitions of success. In fact, understanding why your organisation needs developer relations acts as a key to everything else you need to know. It helps you know what to do, who to engage, and how to measure your efforts.
So, what are those strategic reasons for developer relations? Most developer relations programmes today are focused on encouraging adoption of a product, such as an API. However, there are at least five other common reasons for DevRel. Including adoption, most companies invest in DevRel because they want to affect:
In practice, organisations do DevRel to satisfy some mix of those strategic drivers. For example, it’s likely that a company that needs to drive adoption will also want to make sure its products have good market fit.
Despite the variety in why companies do DevRel, how they do it draws on a similar set of skills and tactics that we’ll call the four pillars of developer relations.
If you’ve had only a passing acquaintance with DevRel then you might think of it as beer, branded swag, and blog posts.
However, just as marketing isn’t all about advertising, there’s more to developer relations than building awareness. While not everyone agrees on the naming, there are four complementary areas of DevRel:
Each of these works together to enhance the relationship between an organisation and the developers it values most.
Let’s look at it from a slightly different perspective. In a typical organisation, what are the responsibilities of the developer relations team? The answer depends on a few things:
For some companies, developer relations is a collaboration across the entire company. For them, developers are usually both the users and buyers of the product, so everyone focuses on how to engage them. But consider a 300 year old bank that is forced by law to offer open banking APIs. For that bank — in fact, in most organisations — developers are just one audience and, importantly, an audience whose work, motivations, favoured channels, pain points, and culture can seem unusual to non-developers. In the case of such a bank, it makes sense to have a team dedicated to the relationship with developers.
Those considerations lead to three broad models for how companies tend to divide developer relations responsibilities:
Regardless of where in the company DevRel people find themselves, what do they actually do?
The what of developer relations depends entirely on the why. However, there is a common toolkit of tactics that DevRel practitioners tend to use. Here’s an entirely non-exhaustive list of some of those tactics:
As you can see, there’s overlap. Precisely what one person, team, or department does will differ from company to company. However, even though developer advocates, developer educators, and developer marketers produce content, for example, their strategic reasons for doing so are quite different.
For more detail on developer marketing, read our article What is developer marketing?