Founder of Hoopy, the developer relations consultancy. Need help with your developer relations? Get in touch.
Table of Contents
Table of Contents
Dev rel, 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 dev rel 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 dev rel can vary significantly. Company X, for example, might do dev rel 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 dev rel strategies, tactics, and definitions of success. In fact, understanding why your organisation needs developer relations acts 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 dev rel. Including adoption, most companies invest in dev rel because they want to affect:
In practice, organisations do dev rel 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 dev rel, 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 dev rel 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 dev rel:
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 dev rel 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 dev rel 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.
In a future article, we’ll look more closely at this division of responsibilities and the roles that you’re likely to find in a developer relations team.