What is developer relations?

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.

Why developer relations

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:

• Adoption: the organisation wants more developers to use their product.
• Product building: the organisation relies on a community of developers to build their (probably open source) technology.
• Product-market fit: understanding developer needs and desires is necessary to the product’s success.
• Developer enablement: providing the education, tools, and infrastructure that developers need to use a product once their employer has adopted it.
• Developer perception: the organisation considers current developer perceptions to be a potential barrier to the success of their product.
• Hiring: the organisation wants to improve its employer brand in order to be more attractive to the developers they need to hire.

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.

The four pillars of developer relations

Four pillars of developer relations cycle

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:

• Developer marketing: understanding who the target developers for a product are then making sure they have the information and tools to make a decision.
• Developer enablement: providing everything that developers need to be successful with the product.
• Developer advocacy: acting as a champion for and conduit between developers and the organisation.
• Developer community: creating and maintaining an ongoing process in which developers can pursue a common goal in relation to your product or organisation.

Each of these works together to enhance the relationship between an organisation and the developers it values most.

Developer relations responsibilities

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:

• Who instigated the relationship with developers?
• Is the company developer first (i.e. developers are the primary end user of their product) or is it developer plus (i.e. developers are a supplemental audience)?
• Are developers buyers (i.e. bottom-up adoption) or primarily implementers of someone else’s technology choice?

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:

• Vertically integrated DevRel: a single department or team takes care of every aspect of a developer’s engagement with the company, only collaborating with specialist departments (such as engineering or marketing) when there’s a beneficial overlap.
• Core DevRel: the developer relations department takes care of those functions that wouldn’t happen otherwise, such as developer community, but leaves other aspects to specialised teams (e.g. engineering, marketing, product).
• Company-wide DevRel: there isn’t a specific team or department for developer relations but, instead, DevRel happens throughout the company.

Regardless of where in the company DevRel people find themselves, what do they actually do?

Developer relations tactics

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:

• Developer marketing:
  • Content creation, placement, and distribution
  • Events: sponsorship, speaking, attending, organising
  • Advertising and other paid campaigns
  • Competitive and market research
• Developer enablement:
  • Developer education: documentation, tutorials, videos, guides
  • Developer experience: API design, SDKs, reference apps, sample code
  • Support and developer success
• Developer advocacy:
  • Acting as the public face of the technology
  • Interacting directly with developers on social media, in forums, at events
  • Speaking at events
  • Twitch streaming, video production, podcast production
  • Acting as a feedback loop from developers to the company
  • Creating promotional and educational materials
• Developer community:
  • Providing and moderating forums, chat, and other channels for direct developer communication
  • Running champions programmes and other ways to incentivise/reward participants
  • Setting the standards and tone of interaction
  • Creating a process that enables people to meet their needs one working towards a common goal

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?