My name is Mario Viviani, I’m Manager of Developer Relations at NVIDIA Omniverse. I'm a technologist and developer myself, and come mostly from the mobile apps and games space.
In this article, I'll talk about what success looks like in developer relations (DevRel) and how you can define meaningful goals for your team to drive success.
Let’s get into it. 👇
The mother of all questions in DevRel: How do you measure success?
Misconceptions about DevRel
“How do you measure success?” is probably the most difficult question to answer. There are a lot of preconceptions on developer relations and what we do.
Developer relations has been referred to by different members of teams and leadership teams as a “fluffy, touchy-feely” business.
In general, DevRel’s activities are difficult to measure intrinsically. The role is very human and based on relationships and engagement.
Our role as developer relations experts, as developers, marketeers, and as evangelists as well, is to demonstrate that developer relations can be a very data-driven world, and that everything we do can be measured and add true value to the business.
Teresa Garanhel
Defining success
Most companies are obsessed with the concept of measuring success, and rightfully so.
However, when it comes to developer relations, even before we define the measure of success, we need to take a step back and define what success means because it has a lot of different nuances.
For example, you can look at what success looks like individually for the functions of your team or for the company overall.
You need to ask yourself when it comes to success: what does ‘good’ look like for the company and what is the company's endgame? Your customer in developer relations is the developer.
We want to provide a great experience to developers and this is often intrinsically different from the company’s endgame. It's important to decompose what does that look like, and then think about how your customers (the developers) and their actions contribute to your company’s ultimate goals.
Usually, for developer relations, success means a developer adopting a product. Essentially, there’s some marketing or education activity you need to put down, and then a result you want to measure, which is adoption.
Adoption
Adoption is what the endgame should be for us as developer relations overall. The journey to adoption starts with tracking capabilities.
You and your team want to be able to track the developer activity and what are they doing as a consequence of the inputs you're providing (which is the marketing activity, sharing content, etc.).
You need to track what you do, and then you need to attribute. If tracking means that I know the developers consume content X, attribution means I know that, as a consequence of it, the developer has adopted the product.
Most common scenarios of tracking & attribution
The ideal tracking & attribution scenario
The first is the ideal tracking & attribution scenario, where your entire developer journey is tracked. In other words, all the steps from discoverability of your marketing content and activity down to the content consumption and even the product adoption are tracked end-to-end.
This means you can easily build attribution as you know exactly who came into your marketing activities, who is coming from the top of the funnel, who has consumed the content and who has adopted it.
Additionally, this means you can determine causation (action causes results). You have data and reports that clearly define this journey. From an infrastructure perspective, you have all the building blocks you need to be able to demonstrate success to your leadership.
You can demonstrate attribution and adoption of the product directly as a consequence of your marketing activities.
The less ideal tracking & attribution scenario
If you’re in the ideal scenario, then you’re in the 1% of all developer relations organizations. Most developer relations organizations are in the second scenario, which is the less ideal tracking and attribution one, where you don't have end-to-end tracking and attribution.
This is especially true for the younger and newer DevRel organizations.
In this scenario, you can measure two things:
- Your marketing activities (action) → The action you're taking, how many campaigns you’ve done, how many developers are even looking at the content, and what content is being consumed.
- The product adoption (result) → How many developers are using your product.
What you can’t determine, because you have a broken tracking mechanism, is if ‘action’ caused ‘result’. You don't know if the developers adopting your product are the same as the ones consuming the content.
You need to build a body of evidence that allows you to demonstrate that there’s, if not causation, at least correlation between ‘action’ and ‘result’. If you're able to do that, then you will start fixing this broken funnel where you don't have entire end-to-end attribution.
Determining correlation by defining meaningful goals
There are a few mechanisms you can put in place to determine correlation, but everything starts with defining meaningful goals for your team.
Defining meaningful goals for your team is all about establishing what your north stars are, as well as the type of activities, goals and KPIs you put down to your team.
Your team’s levers
The first step in demonstrating correlation is fully understanding what your team's levers (the buttons your team can push to determine a change in behavior by the developer) are. The mechanism to get to adoption should be the levers your team can control.
Levers or activities need to be specific to the different functions. For developer advocates or developer evangelists, who are usually tech experts that create content and distribute content with the developer community, you could assign set levers like produce x amount of pieces of content on the specific product or reach a certain number of developers speaking about this product.
There are a few ways to measure that.
For your marketing team, who’s usually distributing content with the biggest number of developers, the levers here could be to deliver X amount of campaigns on product X and drive X impressions to the technical content about product X.
Your team can feel empowered when they reach those goals, which are measurable team functional KPIs. These can be the meaningful goals you assign to your team. This allows you to have a framework of reference when you're debating performance with your team and understanding if the things you're doing are right or wrong.
Measure how levers correlate to adoption
The next step is to measure how levers correlate to adoption. The only way you can do this is through data. You need to build dashboards and reporting, where you’re tracking all the activities your team are doing (as well as adoption) and you need to cross reference this information.
You also have to determine a sensible timeframe for analyzing the behavior of developers because you'll see highs and lows in adoption of your product, and then you will see activities by your team which are displaced in time.
So, you have to look at trends. For example, you added more paid marketing, did more events, did more content sharing about a product and, over time, you saw growth in adoption of the product.
Ultimately, you start driving conclusions between the correlation between your input, your levers, and the output, which is adoption.
Iterate! This is not a precise science but you have to constantly iterate and change things. This is why you want to define flexible master goals for your team. Ultimately, you’ll get a picture of what levers control adoption.
We’ve fixed our funnel!
Once we have defined all these tracking capabilities and start attributing between levers and output, we’ve technically fixed our funnel. We know that, by doing certain actions, we’ll drive adoption, which is the evidence we need to demonstrate value to leadership.
If not direct causation, we have a strong correlation between the activities and the result coming out at the end, the adoption of the product.
💡 Quick tips
- Brush up on business intelligence. If you can, build a business intelligence team. You need to be able to get your hands on data and build correlation of data. Being skilled at collapsing, merging and interpreting data is absolutely crucial to run a successful developer relations organization.
- Have your functions collaborate and share data. Your marketing, evangelist, documentation and localization teams should all talk to each other and share their data. Set up a meeting where you all come together to share information with the broader team.
- Always have clear measurable CTAs for your activities.
- If possible, focus on building end-to-end tracking and attribution capabilities to determine causation. Work with your team, your business intelligence team and your engineering team to get there at a certain point in time.
To sum up
How do you measure success?
Define meaningful goals that are related to what your team can control and what they can do to drive adoption.
Your top-level goals for your team should be about adoption and should be driving product X with developers.
Your team’s functional goals should be about the levers and action.
By correlating those two, analyzing the journey of the developer and measuring success, you’ll be contributing to not only your team's success, but your top-level company success too.
With our Fellowship certification, you'll understand how to monitor your success using competitor intel, churn rates and your approach to positioning, strengthen your leadership skills, create a great developer marketing strategy, and so much more!
Join your fellow leaders for six weeks of tutorial and live sessions. You'll have the chance to share ideas, hone skills, and explore distinct leadership styles within marketing.
