This week I attend the first DevRel San Francisco meetup in 2020: How to Measure Developer Relationswith Amir Shevat. This blog post is a short recap, notes and pictures from the event.
The topic of the event was how to measure success in Developer Relations. Amir is a great speaker and used examples from his experience running Developer Relations at Google, Slack, and Twitch.
Amir started by explaining that there are three different developer communities:
- Developers as core contributors
- Linux
- Developers as customers
- Stripe, Twilio
- Devevelopers as ecosystem partners
- Slack, Android
In this meetup Amir focused on #2 and #3.
Before getting to the main topic, Amir defined what is Developer Relations in his opinion by showing this picture:
Amir then shared the developer funnel which looks like this:
In this funnel, every step has a different success metric. For example, for interested, the measure can be page visits generated from meetups, conferences and speaking at events.
For building step, the number of API tokens generate can be used as a measure (this is an example from Slack).
Published is the number of apps published and used is how many people use the published app.
I think understanding what to measure at each step is important. I published an article that relates to this topic Active developers vs. awareness events, an approach we are trying. If you do a conference talk – that’s most likely an awareness event and won’t result in a large number of projects created on your platform.
Looking at the funnel, I think an extra step can be added to it: awareness. Interested – I think implies that a developer already knows about the service or API. In my experience, it is not uncommon for developers not even be aware what a company offers.
Amir then shared examples of how to measure community activities. In the first example he talked about Google Developer Groups. There are hundreds of Google Developer Groups in the world. They are volunteer-led, independent but that also makes them scalable. Measuring success is not always easy. The step in the funnel (or impact) here is awareness and the measure can be adoption of new product features.
Another example shared was how Slack approached its community strategy. When Slack was starting it didn’t have a big community. What they did – they partnered and collaborated with other communities. In 2017 Slack partnered with IBM’s Developer Advocacy team in Europe and did a city tour together with a focus on how to build Chatbots with IBM Watson and deploy them on Slack. In this example they tapped into IBM’s developer community. I shared a very similar idea in this blog post: Why Developer Advocacy programs should consider working with partners.
Amir then showed what are good and not so good things to measure.
First is a list of metrics you probably shouldn’t be measuring:
- Number of developers engaged
- Hard to define “engaged”
- Giving a talk to an audience that didn’t find it interesting or valuable is still “engaging developers” but this engagement doesn’t add value
- This metric can be easily “hacked”
- Number of developers registered
- This metric can also be easily hacked by running a Facebook campaign where a large number of developers would register
- Revenue to the company
- Turns Developer Relations into sales
This list shows better metrics that companies should consider measuring:
- Number of developers with weekly active tokens
- This shows active developers on the platform now
- % paying customers using the platform
- This shows how many existing customers are paying. This doesn’t measure how much they are paying (revenue). This only shows the percentage of paying vs. non-paying customers
At the end Amir shared lessons and tips. Here are some of them:
Tie Developer Relations to business goals/objectives. I think this is crucial if you want to make Developer Relations succeed at your organization. Tying the program to business goals and measuring the right things — will allow you to show the value of the program to your leadership.
Writing and content. Most impactful, for career and developers. 100% agree with this. Content is also scalable, shows your work and helps others learn. Good quality content can provide value for a long time (vs. an event that happens and it’s over). Adam DuVander published a very good article on this topic: Why Every Developer Needs a Blog.
I published a number of articles about content in the past year:
- A year of blogging every week
- How content creates content
- Interesting content ideas you may consider
- Where to publish content?
- Using online meetups to scale your Developer Relations program
Live engagement. Live streaming and tools such as Glitch should should be considered and used by Developer Advocacy programs today.
One not fun thing. Amir said that his least liked activity is doing booth duty. He advised always to ask what is the value being there (at a conference). Maybe instead of being at a conference for three days, a better use of time is to create a high-quality step-by-step tutorial that can be used by thousands of people, for a long time.
I enjoyed the meetup. Thank you Amir for sharing your experience. I’m looking forward to the next event.
Top comments (0)