How to measure success in Developer Relations is one of the most discussed (or debated) topics. Having been in Developer Relations for a good number of years I believe it’s important we measure it. Without measuring we don’t know what to improve, what works and what doesn’t work.
Now, I don’t believe there is one way to measure Developer Relations. Every company with a Developer Relations organization or a team will measure its success differently. The same way companies approach success in general, every company has its own unique ways to measure success.
Instead of telling you how to measure success, I’d like to offer a framework. The framework can be adjusted for a company’s specific goal and needs. The framework consists of three parts:
I learned a lot about Developer Relations in 2019 and in the process I have been sharing my experience here. The following is a collection of articles I published in the past year. I hope some of the content is valuable and helps you build and grow your program. I of course continue to learn. I’d love to hear what you think and what other topics I should cover.
When people ask me what I do, I tell them I’m in Developer Advocacy/Relations space. Most people look at me confused and say: what? Even folks who are in a software space usually don’t know what this role is.
Last January I set a goal for myself to publish a blog post every week that offer some value, even if small (I actually started in February 2019). I couldn’t miss even a single week, no excuses. I had to publish something. Now, not every blog post was a long-form, in fact most blog posts were short and cover something very small/specific. Nevertheless, the goal was not to miss a single week. For me it was important to get into the habit and stay consistent and once the habit was established it became easier to come up with content ideas and write every week. If this also works for you — that’s great. You should come up with your own approach to keep going.
If you think it will be hard to come up new ideas every week that go beyond the standard tutorial, article or how-to, I shared a blog post on interesting content ideas you can try. The blog post covers the following ideas:
Notes or summary from a conference, meetup
Event in 10 pictures
Links to series of articles
Links to previous month video recordings
Since I published that blog post, here are some additional ideas to help you.
IBM Developer NA West team had a great 2019, the team accomplished a lot. A big thank you to the team 💙. I want to share some of the highlights of what the team did in 2019. You can also check out the cool infographic below.
Measuring success in Developer Relations is always one of the most interesting questions or challenges. Every organization does it differently – from measuring how many stickers were handed out, how many Twitter followers one has, to how many people attended a conference talk, to how many API calls were made. There are many more things you can measure. Every approach has its pros and cons and every organization will use an approach that helps reach their business goal(s).
I think it’s easy to focus on features but that’s not what Developer Advocacy is about (at least in most cases).
Developer Advocacy is about showing what developers can do with your product/service, what problems developers can solve and what solutions developers can build. I covered this topic earlier in this blog post: Share outcomes and results, not features.
Our job is to help, show and educate what rad things developers can build.
Developer Advocacy is how to make developers awesome 🙌
When I shared this blog post with Burr, he told me he uses another phrase:
Our job is to give developers super powers
So here you go, two really great phrases to describe Developer Advocacy from Burr Sutter:
Our job is to make developers awesome
Our job is to give developers super powers
Scaling your Developer Relations program is a challenge faced by virtually all organizations. It doesn’t matter if you are a startup with 10 people or IBM – you still need to scale your efforts.
IBM probably has one of the biggest Developer Relations organizations in the world. Even with such size, Developer Advocates cannot be everywhere to host in-person workshops, meetups and attend conferences. You cannot scale with people.
Even if you could send a Developer Advocate to every meetup or conference, there are many more developers who don’t attend meetups or conferences. There are many reasons, maybe they leave in an area where there are no meetups or they don’t have conference travel budget. You need to reach these developers and also scale.
The way to scale a program is through content, online meetups (webinars), videos and online forums. I shared how to scale with online meetups and content before:
All these resources are available to anyone with an internet connection regardless of location and can be consumed any time of the day or night. In addition, all these digital resources can provide value for a long time, months or even years.