Shawn Wang

Mar 11, 2022

Join or sign in Register for your free TechRepublic membership or if you are already a member, sign in using your preferred method below. Use Your Email Join or sign in We recently updated our Terms and Conditions for TechRepublic Premium. By clicking continue, you agree to these updated terms. Welcome back! By registering, you agree to the Terms of Use and acknowledge the data practices outlined in the Privacy Policy . You will also receive a complimentary subscription to TechRepublic's News and Special Offers newsletter and the Top Story of the Day newsletter. You may unsubscribe from these newsletters at any time. Username must be unique. Password must be a minimum of 6 characters and have any 3 of the 4 items: a number (0 through 9), a special character (such as !, $, #, %), an uppercase character (A through Z) or a lowercase (a through z) character (no spaces). Loading Account Information Check out this article I found on TechRepublic. Your email has been sent Image: iStock 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. Must-read developer coverage 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? 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. 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. Developer Essentials Newsletter From the hottest programming languages to the jobs with the highest salaries, get the developer news and tips you need to know. Weekly