The Core Competencies of Developer Relations
Building a Team That Can Change the World
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.
They need to be legit engineers
To have influence with internal and external engineering teams, your DevRel team needs to be respected as peers.
Engineers don’t trust people who aren’t engineers, so Developer Relations needs to be made up of developers. Even then, they won’t trust just any engineer — we need to prove ourselves.
Some of the most effective Developer Relations people I’ve worked with have transferred from the underlying platform team, worked on 1st party apps (like Google Keep), or came from jobs as successful 3rd party app developers.
Beyond influence, engineering ability is critical because the sample code, libraries, articles, books, training, and reference apps they create will be used by millions of developers — so it’s critical that they’re high quality and exhibit best practices.
They’ll also be influencing the direction of the platform — even 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 SWEs (Software Engineers), with their coding skills tested and evaluated in the same way as any other Google engineer.
Of course “developers” these days includes more than just engineers — so your Developer Relations team needs to expand accordingly, adding additional roles like legit designers to the team.
Continued in “Too Legit to Quit: Setting the Bar for Developer Relations” (coming soon)
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.
Continued in “Avoiding Signal Loss: Effective Communication in Engineering” (coming soon)
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 legit 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, backgrounds, 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.
Continued in “The Next 50 Million Developers: Diversity in Developer Relations” (coming soon)
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).
Continued in “Never. Be. Closing: Why Developer Advocates Shouldn’t be Sales” (coming soon)
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.
Continued in “The Zeroth Customer: To Relate to Developers You Must Be the Developer” (coming soon)
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 maintains a more timely communications channel — providing insight into the priorities and (where possible) direction of the platform, and providing reassurance that developer concerns are being heard and acted upon in the periods 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.
Continued in “Responsive Advocacy: Engaging with your Developer Audience” (coming soon)
They need to be prolific
In 2014 my Scalable Developer Advocacy team produced more than 700 videos, 6 full MOOC courses, 183 blog posts, and countless Google+ posts and tweets.
That doesn’t count the countless docs, code labs, and reference apps created by other parts of Google’s developer relations team. In 2015 we aim to double it.
Colt McAnlis calls this a “content tsunami” and sustaining that constant 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 new innovations, 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
Continued in “Creating a Content Tsunami” (coming soon)
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.
Continued in “We’re Going to Need a Bigger Boat: Developer Relations at Scale” (coming soon)
An effective Developer Relations team is made up of a diverse group of legit 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.
Sounds easy right?
