The first question that comes into the picture when we first hear about the relatively new yet already existing just-named role is,

Why do organizations need a separate team named developer relations?

Depending on the organization, a separate DevRel/DevEx team is required to aid the storytelling and support not only the marketing side of the product but also to handle the internal and external communications. They are also required to aid with the trailing technical tasks of the company with the objective of growth as a community by being the point of contact in a developer-concentric community. Since a relatively larger organization in terms of headcount is more inclined to include a full-fledged team for facilitating its relationships, most likely the founding (senior) engineer sets the tone or metrics for the incoming team members in this space who try to implement their unique, and authentic methods to eventually lead to the first principles/foundations set by the founding DevRel engineer. These metrics aren’t laid by analysis but by consistent optimization based on trial and error on what works and what doesn’t work depending on the experience of the team members. This process is quite analogous to the product builder’s journey in a team where the engineers need to deliver quality features consistently chasing that ever-growing mountain every time on reaching the peak. In this journey, comes a point when the plateau is reached, or growth saturates and they need to figure out new best practices for scaling by adapting to the demands of the marketplace hence leading the competition.

No perfect metrics exist that measure the inputs of the Developer Relations Team correctly because the process isn’t a repeatable one for different teams due to differences in:

• The nature of the product and hence the community interests
• The focus being on quality over quantity.

However, some minimum viable cues that validate the work of the team through visible contributions can be:

1. Different outputs at different stages: Initially, the team invests their time and efforts to make the product visible through strategies that look creative to make a noise in the industry and gain a foothold in their online presence. But, once the awareness stage is surpassed the focus is on educating about the product and developer experiences through tutorials in different formats, increasing outreach through collaborations or events, and building sustainable communities. So, the input metrics grow here with the community growth.
2. Team approach transitions from breadth-first-demands to depth-second-content: As the team grows, members are assigned to handle a particular niche of the responsibilities that were earlier managed by the team generalists wearing multiple hats. So, output metrics grow here with the growth of each member of the DevRel team who comes together and leads with consistent learning and sharing.
3. Being mindful of internal and external connections: This pointer is analogous to meditation in the sense of reflecting once in a while and employing effective methods to increase cross-team work awareness within the organization. A good metric here would be the cross-domain teams being aware of the point of contact for internal and external communications, even within the DevRel team associated with a particular function like developer experience, success, marketing, or relations.
4. Doing improved creative work, not just telling but showing visible numbers gives an ROI: Being flexible and adaptable with the mode of reaching out to the relevant audience yet consistent and authentic during difficult times like the pandemic or the ongoing recession calls for different not desperate measures. There were no in-person conferences for quite some time. Hence, other platforms like twitch streams and youtube tutorials replaced them to pitch the product and kept people engaged and curious, making it easy for them to understand the product, and its initiatives and grow a community. These efforts of the DevRel teams have successfully created a bridge between a technical as well as a non-technical audience and a complete technical product through innovative ways like video or written content in different ways like newsletters on different platforms. The direct user interaction on these platforms over a period of time accounts for the ROI and serves as a metric to track the community interaction followed by tools in place to track the conversion ratio as well as sustaining audience and users. The different platforms are indicative of the “how” and the “what” can be improved according to the response.
5. Framing company requirements into interval-spaced out goals and tracking them: Different organizations have different goals for DevRel teams as some may be focused on improving the technical documentation, some may be focused on increasing community engagement, etc. Having clarity regarding the areas of work to be worked on in advance helps the team to plan long-term goals and set achievable milestones with trackable progress serving as the metric.
6. Feedback collection and data analysis: Finally, since the DevRel teams are exposed to any and every possible way of interaction and engagement, constant data collection from those at the receiving end through surveys, etc. plays a crucial metric to check the response, analyse different areas, and improve according to the feedback loop.

Quick Reminder: Request to be empathy-driven for these amazing people in tech doing a really creative and demanding job who manage a lot of stuff/madness that goes behind the scenes thankless. They are the first contact point of the organization if things go south internally or externally but their stability is the first one that gets affected by the restructuring of an organization.

Hope this article helped any person looking forward to or already in the DevRel Space. Feel free to let me know how can I improve:)

Connect with me on Linkedin or Twitter!