If you are in a developer relations organization, this question will eventually come up. It has likely already come up when the team was first created. And it is a tricky to answer. What is the question? "How do you measure developer relations?"
Most businesses seek to drive the behavior of their employees by setting certain incentives in place. For example, let us say that you are releasing a new product among your suite of products. How do you get the sales team to sell more of that product? You change the compensation plan - they get paid more for selling more of the new product.
Putting incentives in place drives a change in behavior.
It is not uncommon for this desire to drive behavior through incentives to leak over into the developer relations organization. Inevitably, somebody will suggest that the developer relations should be generating more tweets from the money spent sending them to "have fun" at conferences.
Soon an incentive shows its ugly head. "You need twenty (arbitrarily picked number) tweets per event." Or "You need to get ten more followers." You get the idea, and if you have been in this fledgling career path long enough, I am sure you have run across this before.
Somebody on the team will eventually respond by creating dummy accounts. Or by getting their relatives to follow them. Or by ... take your pick. Advocates are smart, and given the chance to game the system, just like anybody else, they will game the system.
So how do you measure developer relations?
I like to answer this question with "You don't." This usually draws a pronounced reaction. Eyes roll. Jaws drop. I have even seen tempers flare.
Good. Now that I have their attention, I can continue.
Measuring developer relations is actually a very good thing. You definitely want to know how many people were at a conference. How many people were in your session. How many social media imprints that session drew. How many social media imprints the conference drew. You want to know what it cost to get there, what it cost to be there, etc. The list goes on and on.
You want to know this because the facts help you make better business decisions in the future. You do not want to know these facts so you can say which advocate is better than the others, or which one will get the raise.
For example, when I ran a developer relations team at Adobe (for seven years), we found that up to a point, a ratio of about one advocate per 150 attendees would yield the best results. So if the conference was 600 people, we would generally send three or four advocates. Some would have sessions. Some would be attending sessions. All of them would be working to build relationships (making heroes).
Above 600, and certainly by 1,000 attendees, the impact of the individual advocate fell dramatically. We were entering the realm where corporate marketing was needed to really emphasize a brand presence.
Measuring our work helped us to agree on this trend, and plan how to adjust in the future.
Battle vs. War
As an Army veteran, I like to think of this in the context of a battle vs. a war. If you are trying to raise awareness of your brand, products, ideas, etc. then that is your marketing war. A conference, meetup, open source project, etc. are specific battles.
In that sense, a field commander wants to know if the battle was won or lost. That same commander however does not say "You each need to kill twenty more enemies in this next battle." That is dark, I know, but the analogy holds true. The commander knows that he sent a certain number of soldiers against a certain number of enemies, and came away with a specific result. He can use that information to maximize his results further along the war.
Telling an advocate to get more tweets would be like telling them to kill more enemies.
At the end of the day however, advocates are corporate employees. There will come a time, usually annually, when raises are due, promotions are considered, etc. This means that there does need to be incentives for individuals. You just want to be sure that the incentives do no compete with the altruistic behavior of the advocate.
So what does that look like?
For my team at Adobe, I very much focused on the individual. There are certain activities which an advocate must do by the very nature of the role. I wanted to setup incentives that drove them to be the best advocates they could be. That went something like the following.
Customer Visit (once per quarter)
An advocate should be in touch with the customer. This means more than just going to conferences. Visiting our customers, and hearing their challenges and successes, is key to understanding how our product(s) is being received.
Conferences and Groups (once per month)
Obviously, a speaking opportunity is great, but it is also important that advocates attend conferences. This gives them an opportunity to explore new content. To see how others present their product. When attending, it was expected that notes would be taken, and insights would be shared across the team.
Blogging and Video (once per week)
Being a person, an individual, and having opinions is key. Understanding the context of the comments is also important. Developers do not trust corporations, they trust people, so be a person. Be you. See where that takes you.
Additionally, not every development shop moves in cadence with your product releases. Having material available for developers to review, when they come around to needing that information, is important. I like to think of this as the long tail of content, and would often tell my team that they needed to be presenting content (in whatever form) that was a year out from what most shops were currently using.
Individual Contribution (once per quarter)
It is difficult to build relationships (make heroes) if all you are doing is talking. I wanted my team to be actively involved with helping customers succeed. If the opportunity presented itself for them to spend a week with a customer, helping them test out our product features, then that was a worthy endeavor.
In my experience, this usually starts at a conference. You get that rush of questions after a session for example. If one of those questions pulls you to take action, then you should be motivated to do so. You should also have the budget flexibility to make purchases if needed (an IoT project for example).
Personal Project (per manager)
I would use this as my wildcard. It allowed me to work with the individual advocates directly on their career growth. For example, it is not uncommon for new advocates to struggle with work/life balance. More mature advocates might want to dig deeper into a specific area of study. Or even take some classes. Reserving a personal project for my management discretion helped me keep a balanced team.
All of my incentives were setup to bring out the best in my team. They were setup to motivate behavior inline with what I expected of the advocacy role. Measurements were important as well, but not as a grade, rather as a means to assess if we were being as efficient as possible (maximizing ROI).
So does developer relations need to be measured? Yes! Absolutely. It is important however to not mix measurement with incentives.