You can be forgiven for your mad dash into hiring a developer relations (DevRel) Expert. After all, software is eating the world, developers are the new kingmakers, etc. etc. You need developers building on your platform, and you need them RIGHT NOW.
But, before you dive into developer relations, it might be worth considering what kind of developer you need to relate to, and how to do that. While Redmonk’s James Governor is correct to laud Microsoft’s hiring streak of DevRel folks for Azure, that doesn’t mean you need to do the same. Not all developers and, hence, not all DevRel, is created equal.
Meanwhile, back in Kansas…
This was the message I delivered at the recent DevXcon in San Francisco. Sitting in on the other sessions, I felt a bit out of place, despite the fact that I manage the developer ecosystem activities for a large software vendor. I’m not interested in gathering millions of front-end developers to build widgets. Nor do I really want to do meet-ups disguised as campfires replete with s’mores and everyone happy.
Those are probably great ideas for different companies, with different potential communities. But for me (and probably for you, if we’re frank), these are not the “droids you’re looking for.”
SEE: Job description: Full stack developer (Tech Pro Research)
After all, you’re not GitHub. Or Microsoft. Or Google. Or (insert basically any name of any major tech company). You’re (insert the name of your company), and your needs are different from those of other companies.
It’s a bit like Gartner analyst Svetlana Sicular’s counsel to CIOs frantic to hire data scientists: “Organizations already have people who know their own data better than mystical data scientists.” The trick is to enable these internal candidates with the tools to take on data science.
Or, in the case of developers, to take on developer relations.
Your mileage may vary
The general definition of a developer advocate is likely akin to Cloud Native Computing Foundation executive Chris Aniszczyk’s illustration: Someone involved in “public speaking, crafting demos and the careful finesse of walking the line between representing your company and the developers you seek.”
What I found for my team, however, was the advocate role can be as much inward-facing as external. Such a person needn’t be a candidate for the next CES keynote, but should be able to work closely with different product teams to help them become more developer-minded.
Or simply to listen–both to internal and external developers.
The first order of business is to determine who your developer community includes. According to SlashData estimates, there are roughly 13 million developers, but that doesn’t mean there are 13 million developers interested in your company/product. While some companies absolutely need random developers sitting in their garages to write applications to run on their platforms, that likely doesn’t describe your need. In my case, our primary developer audience is employed by system integrators or other software vendors. They don’t need campfires. They need APIs, documentation, use cases, and sample code to give them a running start on delivering on customer needs.
You only learn this, however, if you listen to them.
For example, when I took on my role running our developer ecosystem, I assumed what was needed was more developer assets (APIs, documentation, etc.). This was a gap, but the first-order priority was actually fixing the provisioning and authentication process such that a third-party developer could more seamlessly start working with the APIs we provide.
As for internal needs, it was nice that I could tell the product teams to put all their documentation in a central repository, but it was better to learn that the reason they weren’t doing so was that the system we had in place was too cumbersome.
In my world, developer advocates are less useful for their prowess on stage and more useful for their ability to talk with our developer community, inside and outside the company, and translate those conversations into better “hygiene.” That doesn’t refer to bathing habits, but rather to the quality of assets and processes available to developers.
So, before you go hire a DevRel lead in the mold of Kelsey Hightower (a very high bar indeed), first understand the community you hope to have. It may well be that the ideal candidate sits in the cubicle next door.