The Core Competencies of Developer Relations
Building a team that can change the world
An effective Developer Relations team is made up of a diverse group of credible engineers with superlative communication skills, who aren’t selling anything, who feel the same pain as their audience—to which they listen and respond to continuously. And they have to do all of that in a way that can scale to an audience north of 20 million developers.
In Why Do We Pay These People Anyway? I wrote that a thriving developer ecosystem needs a trusted Developer Relations team made up of engineers who are the interface between 3rd party developers and the engineering and product teams building the underlying platforms.
Developer Relations are the canonical source of truth, both for 3rd party developers looking for documentation, best practices, and training, and for internal engineering teams who need to understand the thoughts and experiences of 3rd party developers, and to get candid technical feedback on their developer offerings.
Here are, in my opinion, the most important values and competencies required to build a Developer Relations team that can have a real positive impact.
1. They need to be credible engineers
To have influence with internal and external engineering teams, your DevRel team needs to be respected as credible.
Engineers don’t trust people, particularly not people from companies trying to convince them to use their products. So we need to prove ourselves.
I used to think that meant they needed to be a visibly ‘legit’ engineer, and some of the most effective Developer Relations people I’ve worked with have transferred from the teams that built the platforms, worked on popular 1st party apps, or came from jobs as successful 3rd party developers.
But arguably the most effective DevRel people I’ve known have come from sales and support. Their credibility stems from their close relationship with their developer audience and the empathy and understanding that brings.
They do need to be able to write good code. Developer Relations teams are responsible for sample code, libraries, articles on best practices, books, training, and samples used by millions of developers—so it’s critical that they’re high quality.
They’ll also be influencing the direction of the platform including checking-in code, contributing to API design, and performing code and API reviews.
That’s why Google’s Developer Relations team goes through much the same interview process as Software Engineers, with their coding skills tested and evaluated in the same way as any other Google engineer.
Of course “developers” now include more than just “engineers”—so your Developer Relations team needs to expand accordingly, adding additional roles like legit designers to the team.
They need to be excellent communicators
There are a lot of things battling for developer attention, all of it running a distant second to the code they should be working on.
Your developer relations team needs to create material that solves problems, as well as being inspiring, interesting, and entertaining.
That means crafting code that’s self-documenting and explicitly documented; presenting material that’s informative, entertaining, and engaging online, or on-stage; wordsmithing docs, blogs, and social media that are a fun to read; answering questions concisely and comprehensively; interacting with communities; and effectively communicating bugs, features, and issues with internal engineering teams.
It’s not enough that they have a deep understanding of the platform they’re working with, they also need the ability to effectively share that information with other engineers.
They need to be diverse
Every team benefits from diversity—your Developer Relations team disproportionately so (which is one of the reasons we love programs like Women Tech Makers and run our global Google Developer Groups).
Developer Relations’ goal is to work with the largest developer audience possible, and creating a diverse Developer Relations team full of credible engineers makes it inclusive of a wider audience.
Developers are more likely to trust people to whom they can relate, so to expand your reach you need a team that includes people with diverse backgrounds: languages, education, countries of origin, ethnicities, genders; as well as different programming languages, preferred IDEs, and industry experience.
Presenting a diverse team as the public face of your engineering efforts may even help inspire a greater diversity in the industry—a win for everyone—so it’s worth trying to create a team with even greater diversity than the company (and industry) that they represent.
They can’t be selling anything
Engineers have finely honed (if not overly developed) bullshit detectors, and an inherent mistrust for anything they perceive as self-serving.
Sales and marketing often struggle to have an impact with developers, so it’s vital that Developer Relations be incentivized towards making life better for developers rather than making money for the platform.
Trust requires honesty, which depends on a level of candour about the opportunities and limitations of the platform and products they represent. That honest assessment forms the basis of the narratives Developer Relations creates and uses: “How can this product or platform help developers”?
Developer Relations can’t be cheerleaders, or sales people in disguise. They should make a horse aware of water, demonstrate how the water can help it, lead it to the water, and make the water as easy as possible to drink.
If the developers aren’t interested, the most important responsibility for Developer Relations is understanding why, and sharing that feedback with the platform team to help improve the offering (preferably before it’s offered in the first place).
They need to feel developer’s pain
Developer Relations should be the “zeroth” customer for every Developer Platform or API. They have the perspective needed to experience the product in a way that’s as close as possible to the developer audience, while having the access to, and trust of, the core engineering team, so they can help fix issues before exposing them to 3rd parties.
A good Developer Relations team will push back against advocating a product if they don’t believe they can honestly promote it and advocate for it.
This will sometimes put the Developer Relations team at odds with Product Managers, whose focus is on launching and growing adoption.
This friction is a good thing. Products must launch (and can’t be perfect), but the long term health of your ecosystem depends on a robust developer experience—growing awareness of a crappy experience is likely to cause more harm than good, and because it affects trust, the potential damage is difficult to repair.
They need to listen (and respond)
In order to build trust with 3rd party developers, and represent them to internal engineering teams, Developer Relations needs to be a part of the ecosystem.
You can show you’re listening to developers by making changes to the platform and improving the developer experience, but that process can take months (or years!). Developer Relations must maintain more timely communications channels—providing insight into the priorities and (where possible) direction of the platform, and providing reassurance that developer concerns are being heard and acted upon between releases.
Developer Relations engages with the community in much the same way as they would if they were a 3rd party developer. More than just posting announcements and reading responses, Developer Relations also interacts on an ongoing basis by working 1:1 with partners, and participating in online and in-person communities via forums, social media, and conferences.
They need to be prolific
I’ve led teams that have built three developer-focused YouTube channels that now have over a million subscribers each.
Whether it’s videos, blog posts, or social media—the way to get an audience is by posting through it. Multiple new pieces of content every day on multiple platforms.
Colt McAnlis called this the “content tsunami”, and sustaining that flow of material is how you maintain an active and engaged relationship with developers. That’s a relationship that starts with building awareness at launch but just as importantly also shows third party developers that you continue to be actively engaged in helping and supporting their ongoing success.
Developer Relations is the voice with which you speak to your developer audience—it’s important that they speak often, and loudly.
The material created by Developer Relations encompasses everything from driving awareness, inspiring innovation, teaching and training, and sharing best practices—all of which evolves alongside the growth of the ecosystem, so there’s never any shortage of source material
They need to work at scale
There are around 20 million developers in the world, spread across over 200 countries—so everything Developer Relations does needs to have a strategy to scale that doesn’t require a linear growth in team size.
Engineers are hard to come by, so it’s often difficult to convince executives to divert talented engineers away from their platforms and products, and into Developer Relations—which further pressures the team to find even more scalable approaches to their work.
As the size of the addressable audience, developers in the ecosystem, and platforms being supported continues to grow, that need to scale impact without a corresponding increase in team size gets increasingly important.
This article was originally published on my Medium page, and has been lightly edited before being republished here.