In part two of the series we discussed what DevRel north star metrics commonly get used across the industry. We also saw that it can be quite tricky to find the right metrics to measure because they are plenty, sometimes lag behind or the relation to your North Star is not direct but only delivered over time.
So what should we do?
I will answer this question in this article for people who are just starting out and looking for a way to have a solid foundation to build on. Because that is what I found myself in when I started my Developer Advocate journey 😊.
But also if you have something in place already. This article will help you make sense of metrics and give you inspiration.
The Solid Framework: Kim Maidas Keystone Framework
Just starting out with DevRel-Metrics? Look no further than Kim Maidas DevRel Metrics Keystone Framework. Over the course of her career leading in Developer Relations she says she found a way to holistically measure DevRel in a way the C-Suite understands. And I could not agree more!
Her idea is to define one Keystone (North Star) as your guidance. Her recommended keystone is 1 signup/registration. Ideally it is your companies north star.
Once you have your keystone you can come up with a price tag for it. Yes, real money!
Then with a price tag you can attach a percentage of this keystone value to each metric in the following categories:
There is an order to it also. Reach metrics are at the top of the funnel and thus improving metrics from that category is not as valuable as further down the funnel. Engagement and finally DevRel Qualified Leads are worth so much more and you can add more value to each metric in those categories.
What you basically do is attaching a value tag on every metric and are thus able to calculate the value DevRel brings to the table 🥳
I do not want to copy Kim Maidas article, so for the sake of brevity, I encourage you to read it and use her method to give every metric a meaning tied to company metrics.
There is also much more in her article that makes the read worthwile!
My Personal Additions
I personally found two additions helpful in showing impact on product/engineering:
- Internal Impact
- Direct Impact.
The first one captures the feedback you bring from the community into the company. The second one measures your direct impact you have by doing developer experience audits and creating content.
Internal Impact
In my daily work a lot of things I do are related to product development. Be it providing feedback for new features, betatesting new features, writing docs, gathering feedback from the community and relaying it back to development. The above areas do not cover them completely.
Luckily I found two articles that cover these areas well (See DevRel Metrics and Why they Matter by Sean Falconer and The Core competencies of Developer Relations by Reto Meier). They talk about the developer relations cycle where they introduce Developer Feedback and Developer Sentiment that Developer Relations collects and brings into product development.
As you are acting as a middlehuman for these two, I call this internal impact as you affect your product through the feedback delivered.
What I like to measure here is the number of feedback and sentiment brought to the department in your company where it is best seated. If anything comes out of this feedback that is also noted down.
Direct Impact
As you have noticed, most metrics are loosely tied to company goals. But there are ways to demonstrate a direct impact. Things I found useful are the following:
- Developer Experience Audits: Evaluating your product as a user would and providing detailed feedback and improvement suggestions to product management. You should also track what is finally implemented and if possible if any metric was impacted by the change (Less bug-tickets, specific user complaints decreasing).
- Tracking your content's impact: With sufficient tracking in place you can track if your company’s North Star metric is affected by your content like docs, blogs or videos. In fact this is what I do and I could demonstrate that videos on YouTube drive Sign Ups.
Conclusion Part 3
With a framework like the one from Kim Maida you can lay a solid foundation for all your metric needs in a structured way. It also makes reporting easier by directly tying individual metrics to your companies north star.
In the last part of the series we will dive into the wonderful world of company development stages and their individual needs from DevRel. Early stage startups are different than enterprise organizations. And there is a lot of space in between.
Thus we should shift our focus and the metrics we take into focus accordingly.
I will also share my template I use to report DevRel metrics every month.
Photo by Leonardo Vazquez
Top comments (0)