Tips for getting developer relations right at your company

Many companies realize they need developers to build with them, but they aren’t sure how. Here are some do’s (and don’ts) from one of the industry’s top DevRel professionals.

In tech, some things are intuitively important but with impact that is notoriously difficult to measure. Take DevRel, or developer relations, for example. It’s become a truism that developers are the new kingmakers, that they can be immensely important to the success of a platform or service. And yet, as Temporal’s Shawn Wang has written, DevRel is often “Lots of sizzle, questionable steak.”

Given an apparent inability to consistently measure the impact DevRel has on a company’s fortunes, why do companies continue to invest? Because they definitely are investing, and not just in the US and Europe, and not merely technology vendors, as I’ve detailed. Given how long Wang has been involved in DevRel, and for whom (AWS, right before he joined Temporal), his suggestions on how to measure the impact of DevRel are particularly instructive.

All the cool kids are doing it

Sure, the DevRel folks you follow on Twitter probably work for AWS, Google and Microsoft, but these cloud companies are hardly the only companies employing DevRel professionals. I did a quick search and found DevRel at Ford Motor Company (automotive), CapitalOne (financial services), Ubisoft (gaming) and more. That’s because while every organization has different needs for third-party developers, increasingly companies see value in enabling developers to build upon their software (or hardware) assets.

Or, as Martin Woodward, senior director of developer relations at GitHub, has stressed, “The reason DevRel is hot in the industry right now is because more and more people are getting into software, and they understand the importance of community and building network effects around your software so that it grows and it grows organically.” If every company is increasingly dependent on software, pretty much every company could benefit from having more developers use and/or contribute to that software in some way.

Still, once you recognize that you need DevRel, for whatever reason, how do you measure success?

SEE: Hiring kit: Android developer (TechRepublic Premium)

It’s common to see vanity metrics like GitHub stars (for an open source project you may have) or badges scanned at in-person events (remember those)? These are worthless, Wang argued. Instead, “Stop looking: Your North Star metric is ‘monthly active developers’.” That is, the number of developers subscribing to your newsletter, contributing to your project, following your development-related Twitter handle, etc. By taking an aggregate of all the diverse ways developers engage with your company, you get a holistic view of community health. If that number is going up, great. If down, not so great.

One problem with measuring DevRel is that it’s easy to succumb to the law of large numbers. No, not that law of large numbers; rather, I mean the idea that everyone wants big numbers because big is good right? Maybe. But in DevRel, much of the best things come from reaching fewer, but more valuable, people. Or as Wang put it, many DevRel metrics fail “because they value quantity over quality, breadth over depth, free-and-superficial over paid-and-indicating-serious-interest.”

Think about it this way. If I’m running an open source project, it’s tempting to think a vibrant community looks like tens of thousands of contributors to the project. Yet for the vast majority of projects, fewer than 10 people do 90% of the work, as a recent study uncovered. Nearly all projects, then, would benefit more by finding one of those 10 people who can deeply engage in a project, rather than trying to amass an army of onlookers. For the DevRel professional who helped bring in that one contributor, their job is done for the year.

SEE: Business leaders as developer: The rise of no–code and low–code software (free PDF) (TechRepublic)

Which brings us back to the question of what DevRel should be doing. This depends on your product/project, as noted, but one thing that Wang disparages, which I’ve seen routinely touted at various companies, is using DevRel to inform product development. It seems like such a great idea. It just rarely works: “The reality is often the ratio of this two way street traffic is 99% outbound and 1% inbound,” he wrote, “because the product/engineering orgs haven’t set aside any bandwidth for ‘shadow PM-ing’ from devrel and all of devrel’s metrics are outbound focused.”

So what are good reasons to have DevRel? I like to think of DevRel as an authentic way to engage (or market to) developers. This can be done, Wang said, by focusing DevRel on community, content and/or product. A company might want to build a broad community around a complementary open source project, for example, something that will make it easier to sell the core product, or perhaps the community is simply intended to make would-be buyers feel safety in numbers. Or perhaps DevRel would create deep technical content that enables third-party developers to build with or upon the company’s product. Speaking of product, DevRel can also be the team that brings a product alive by building demos and, through this and other means, helping the company’s product team know when a new product isn’t quite ready for general availability.

But wait! There’s more. So much more, in fact, that I’ll leave you to read Wang’s excellent post. Just remember: the “right” DevRel is tuned to your particular organization’s needs. You’re not Google. You don’t need Google’s DevRel organization. As I’ve written, “So, before you go hire a DevRel lead in the mold of [Google’s] 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.”

Disclosure: I work for MongoDB but the views expressed herein are mine.