I took two reports I had read some time ago under review again since I lacked a good idea for the post. The mentioned reports are “State of developer relations 2019” (28 pages) and “The State of API 2019” (62 pages).

Neither of them are academic but conducted by companies which might affect the reliability/validity and should be taken into account when reading the reports. I have no reason to suspect any obvious bias but company interests often have an affect on what is reported and what is left out. Also the methology and data collection method descriptions are often missing. State of API report at least contains brief methodology description. With quick scan of the Dev Rel report I was not able to find any descriptions. That said, I love that such reports are out there for us all to learn from.

What is DevRel?

I was not able to find academic precise definition for developer relations. I’m not saying there isn’t any, I just did not have the energy to make a thorough search.

Google has described their DevRel as: “Our global Developer Relations team are comprised of Googlers who are in love with the coolest new technology and thrive by connecting to other developers who share similar passions. This is the team behind all the rich, technical content on developers.google.com, as well as the people you’re likely to see speaking at Google I/O or might be following on Google+.”

Mary Thengvall, founder of Persea Consulting and author of The Business Value of Developer Relations, says DevRel is really about managing the relationship between groups.

Matthew Broberg, Advocate and Editor at opensource.com says that in practice the implementation of DevRel has been far from consistent. “DevRel, in theory, is the intersection of three disciplines: engineering, marketing, and community management”.

To me the variety of so different and even vague descriptions which might fit anywhere indicate immature nature of Dev Rel. It seems to a rising thing, but it’s still a juvinile. In addition some use terms such as community relations in parallel with dev rel.

Measure the success

Both reports contain tons of good material. Both of them contain at least one pretty similar question with percentage responses:

These caught my attention this time. I combined the results in one pic (butt ugly way):

Revenue is not the driver

Notable is that in both results making shit load of money is not the measure of success for majority of the respondents. In both surveys revenue was measure of success only for roughly 20-22%.

Usage

Usage of the product was in my opinion close enough to each other to say that the programs (API program 53% and dev rel program 61%) are aligned although the positions in list differ. In both cases people are happy if the product is used. That makes sense since both aim to increase the popularity, adoption and usage of the product. Although it must be noted that in Dev Rel report API usage and registrations were bundled together. On the State of API rerport registrations was much lower in the results (number of subscriptions, 25%). Bundling the API calls and registrations makes it hard to compare the two without leaving some questions open and unanswered.

Who are we serving?

What really astonishes me is the “If management is happy” in Dev Rel report. 29% of the respondents say that Dev Rel is a success if management is happy. That sound immature and a bit childish to me. I might say that it sounds also that some of the respondents have lost for whom they exist: management or customers? On the other side, in API State Report Developer eXperience is 2nd most commonly seen as measure of success. This indicates strong customer orientation.

I would expect Developer eXperience to be one of the success indicators in DevRel too

Discussion

Thee two reports can not be fully compared to each other since one is focused on API as a Product and the other on relations to the consumers of the product. The two should be aligned well enough so that they support each other and both work for the same strategic goal in the company. In my opinion the immature nature of larger Dev Rel programs is visible in the “if management is happy” percentage.

DevRel is new thing in bigger picture and needs to mature so that DevRel teams are not there to satisfy egos on your managers, but to increase the satisfaction and love of the developers. It also sounds like the DevRel teams are not independent teams but instead subordinates of some existing teams and that team manager must be pleased. This hypothesis is supported by the report which says that onyl 16% of the DevRel teams are independent.

I might sound negative or suspicious of dev rel. I might be suspicious since I can smell some people using the term too vaguely and as BS term just to sound cool and still do the old fashion marketing stunts. Negative? No, I still need to see where dev rel is going before I can say whether I love it or not.

Some more to read from 100 Days DX