7 Main Takeaways from 2020 Developer Relations Report

Developer relations is a growing practice of engaging with external developers. In simple words, the job of a DevRel team is to make sure that developers working with the software or API are happy, which positively affects the image of the platform and leads to its popularity. 

How companies achieve this goal depends on the company and its business. Still, usual activities within DevRel teams include writing tutorials, providing sample applications, understanding the major pain points of the developers, relaying them back to engineers, and actively engaging with the community through online channels, conferences, and meet-ups.

DevRel is not an entirely new field, and it has been around for a long time. One of the first "software evangelists" was Mike Murray from Apple, who coined the term and actively engaged with developers in the late 1980s, persuading them to develop applications for Macintosh (instead of IBM). 

Nowadays, DevRel teams start playing an increasingly important part, just as engineering or marketing departments. Big companies like Google or Amazon AWS invest millions into their DevRel programs, making them a critical factor in attracting more developers.

The new State of DevRel 2020 report prepared by Hoopy outlines some of the recent trends in the industry, which I present in this article. I hope that some information in this post can help you better understand what DevRel is about and how they can help drive awareness of your product.

Once perceived as an esoteric job rooted in tech startups within the Valley, today, developer relations is a global activity employed by Fortune 500 companies, startups, and medium-sized companies. Although the field is not new, it is still growing, especially in Europe. The number of companies practicing developer relations in Europe is almost four times smaller than in the US (56% of all companies practicing DevRel originate from the USA). 

While developer relations originated from tech companies, more traditional industries start to discover DevRel, including companies from the automotive, healthcare, entertainment, and retail sectors. However, tech still dominates the field: IT companies paired with SaaS providers account for almost 75% of DevRel today. Surprisingly, the telecom sector's presence in DevRel has decreased from 16% in 2016 to 4% in 2020.

Developer relations may seem like a luxury small and growing companies cannot afford. Still, numbers suggest that even companies with less than 100 employees practice developer relations, making 27% of all companies. More prominent companies with more than 1500 employees still dominate the market (50% of all companies with DevRel).

Developer relations happen for different reasons depending on the needs of the company. The majority of practitioners (24%) do developer relations to drive awareness and adoption, 22% see their goal in education and support of developers, and 19% have started DevRel to drive engagement.

Only 1% of companies do DevRel to drive sales. This fact makes sense, as it is challenging to sell your product to a developer if there is no real value behind it. At the same time, if your work shines and you dedicate enough time and effort into making developers aware of it, the sales will grow along. 

The number of products (APIs, SDKs, HDKs) under the scope of developer relations programs vary from 1 (less than 10% of practitioners) to more than 100 (19% of the companies). Most companies (50%), however, manage less than or ten products at a time. These numbers correlate with the company size: the bigger a company, the more products it controls at a time. 

Metrics are essential for measuring the overall success of any company. While how to measure the success of developer relations is still a debatable topic, most companies tend to measure the success of their programs by the amount of created content, like docs and samples (50%), signups and registrations (48%), usage of the product (41%), and apps developed (35%). Only 16% of DevRel teams measure their success by revenue.

The report notes that DevRel practitioners are an increasingly diverse group of people, ranging in age from 22 to 60+, with 30% in the 41-50 range (still predominantly male). Surprisingly, almost half of all practitioners do not have a technical degree, and having one is not a decisive qualifier for the job. 

The majority (34%) of the DevRel specialists make between $100K and $150K, 8% more than $250K, and 8% less than 50K a year. 

DevRel practitioners spend most of their time developing content, planning and attending events, and doing "evangelism". The majority of the practitioners travel at least once a month (before pandemic). Seventy-two percent of the respondents work entirely remotely (even before Covid-19).

The top three skills necessary for DevRel, according to the report, are Empathy (40%), Communication (33%), and Creativity (9%). The practitioners' other skills are patience, technical knowledge, ability to work cross-functionally, passion for the job, and organizational skills.

Empathy may not seem like an obvious choice for top skills necessary for this job, but only until you ponder about it for a while. Indeed, one of the goals of a developer relations practitioner is to advocate for the best developer experience possible, and it is not possible without having empathy for a developer in the first place.

One of the best ways to learn empathy in the DevRel context is to become a developer for the product yourself. This will help one learn the software/API from the bottom up and uncover significant pain points in the developer journey before the first external developer gets to work with your product.

Developer relations are becoming popular in companies other than tech. Most of the DevRel teams manage ten or fewer products, spend their time creating content, and traveling to developer conferences. We can expect that the field continues to grow with the number of companies offering API and other software for developers.

For more information, read the original report.