In yesterday’s post I touched the Developer Relations topic by comparing some of the results from two reports “State of developer relations 2019” (28 pages) and “The State of API 2019” (62 pages).

DevRel still feels a bit fuzzy and thus I started to look for things the team is used. The first thing that came to my mind long time was interaction with the developers. That’s kind of obvious vague. It could easily be labelled as traditional community management. There’s got to be more.

Purpose of Developer Relations team

In the State of developer relations 2019 I found some benefits of having a DevRel team. According to the report DevRel teams are used differently depending of the community size.

According to the report main reasons to have DevRel team are:

In Platform of Trust devrel is part of another team - not marketing

Applying this to our work at Platform of Trust shows some contradiction. We are young startup with solid funding. I started working with the platforrm Dec 2018. We don’t have devrel team. In our case devrel is part of the “UX/DX/tools” team which is outbound customer oriented team. It is the eyes and ears of the “backend” developer teams. It also acts as umbrella to block customer noise from the internal developers.

UX/DX/tools team for example is responsible for gathering customer requirements and feedback, and process it to features in the API designs and tools as well as pass the message to Growth team if needed (business related). The team does work in close cooperation with “CX, PX and sales” team. PX stands for Partner eXperience and CX for Customer eXperience. In that sense we are like “the others” since marketing is involved but the foot of DevRel is more on different team.

UX/DX/tools

Main purposes of the UX/DX/tools team which is the home of devrel is to develop needed self-service tools, guides, design APIs & libraries, API Docs for the developers. We drive directly to self-service and our feedback is also based on self-service. We springle around links to provide feedback in APIs docs, guides and developer portal. We are also building analytics on the developer behaviour related to our tools and services. Of couse API management is providing us info too. Aim is that feedback is automatic and eventually we have analytics engine which gives us hints where the problems might be now or in near future. Thus developers might not need to give us feedback about all the things.

Awareness, sales and partnerships

In our case awareness building is top level activities. I’m doing it also in the 100 Days DX series. I write invited posts to other publications about the platform. I’m visiting podcasts now and then. I’m also attending conferences as speaker although not that much yet. I could say that I’m the evangelist at the moment. Big part of my work is to do “sales” by igniting new partnerships with other organisations and as part of that show in code level how the platform works. I’m also often called into meetings with prospect customers to act as the technical person. B2B Sales (partnership model) is very strongly present.

In our case feedback is not the focus of devrel, but awareness and partnerships with other organisations (joint business interests).

Lately my focus has turned on other strategic aspects and features of the platform and DX is in process of transfer for my colleague. Anyway, my tasks was to kickstart DX development in the platform and that is going forward now with solid plan. Time for me to do other stuff, solve other problems. I need to let go of my baby and let other people handle the rest after handover process is done.

Discussion

DevRel is not so clearly visible in our organisation. It’s there, but hidden gem which might grow out from the shadows of others in the future.

Some more to read from 100 Days DX