The 9th Developer Program Leaders Survey is now live. Take part and voice your views on running developer programs and communities. Want to sample the insights? Continue reading to learn about the latest survey results and take a look at the full findings here.
Recently, I got a chance to review results from the Developer Program Leaders Survey Q2, 2022 by SlashData and this blog is my contribution to decoding findings that I found especially interesting and a better understanding of how DevRel programs are evolving across the industry.
It’s no mystery that a Developer Advocate wears multiple hats. We are always involved in a variety of different activities meant to reduce friction for developers using our products but it’s really good to see that creating a developer strategy still remains one of the most prioritised activities for DevRel practitioners, today.
1. Creating Developer Strategy: The importance of having clear goals
From my personal experience as a developer advocate, I could attest having specific goals helps a lot in cutting down on distractions. You get a clear understanding of which events are right for you and what sort of content will help your developer community grow and nurture. So, in turn, creating a developer strategy directly influences other activities alike and spending more time creating one, helps to better prioritise things and makes it easier to say “No” to the opportunities that add little to no value to your community.
2. Internal buy-ins and getting funding: Steadily bridging the gap
Now, this is an interesting one. Seeing a drop in creating internal buy-ins and securing funding from 22% in the Q4-2021 survey to 15% this year, really proves that DevRel practitioners are now spending relatively less time in convincing and justifying the cost of their DevRel programs.
This could be the result of developer advocacy programs becoming more mature and clearly linked to strategic goals. The impact of developer advocacy programs and their integration into company-wide strategy seems to be making it clearer for stakeholders to consciously invest both budget and resources in DevRel efforts.
I’ve been on the spot, spending hours to justify the cost of attending a conference or organising an event or just buying a new service or platform subscription to support our Developer community, so it’s really good to see that time is being claimed back and spent doing other rather more impactful tasks such as :
Direct developer engagement (rising from 11% to 18%). This is one of my favourite activities as a developer advocate. The feedback you get during 1:1 or 1:many interactions are extremely useful and specific. This also gives you an opportunity to create relationships on a much more personal level with members of your developer community, which can later become the foundation of your ambassador program.
Understanding of the product:
Although not showing up in the results but of great importance based on personal experience, is time spent in understanding your own product better. This is especially true for developer-first organisations where the products are ever-evolving and getting complex.s a DevRel practitioner it’s important to stay up-to-date with your own product growth and for someone who just joined a new organisation as DevRel, quite a significant amount of time can go into learning about the product itself.
3. Challenges calculating on-boarded developer value:
The survey also asked how a Developer program budget is justified and the estimated lifetime value of an on-boarded developer. It’s clear that the majority of people (~45%) participating in the survey don’t have a solid methodology for calculating the value of an on-boarded developer and hence only a small portion (8%) has backed the budget allocated to the developer program by an exact FIAT value. Given the complex developer lifecycle and pricing plans of developer-facing - products, platforms and solutions, it’s fairly complicated to create a solid framework that can help calculate the exact dollar value associated with an on-boarded developer.
Most products often have a free tier associated up to a certain usage and some also have free tiers for certain segments of developers such as student groups or non-profits. A developer can also evolve from being a part of a free tier to onto a paying payment plan over time and hence adding more complexity to put a dollar value on developer acquisition. It’s also difficult to know which acquisition strategy exactly works in onboarding a new developer, whether it’s that Youtube video you recently published or a past conference talk or demo during a local meet-up, It could very well be your SDK written in Go with good documentation.
4. What's up with the segmentation?
The next part of the survey shows that nearly one in five DevRel practitioners don’t differentiate or segment developers. I believe there has to be a really good reason for not doing that or their product is relatively niché, targeting a very specific group already.
In my experience segmenting has always been crucial, especially on the basis of developer self-identification - being a hobbyist vs professional vs student, which accounts for 20% in this survey. The needs of a hobbyist developer are very different from those of a professional using your products in real environments. A hobbyist might be looking for affordable (read-free) pricing whereas a professional developer might be willing to pay extra for faster technical support and better documentation. Understanding developer motivation and goals come on top or along with segmenting for experience and/or type of involvement.
Only 6% of DevRel practitioners segment based on business models. This is actually not surprising. For example, a product of an IoT company can be used for agricultural as well as manufacturing applications so in my opinion if your product caters to a wide variety of businesses it can be a useful segment based on the business model to better understand and address their pain points.
5. Do you put your efforts into the right initiatives?
The last part of this survey is the most interesting one for me. It shows the relationship between where DevRel efforts and budget is focused vs what things are important to developers. There can never be one size fits all when it comes to catering needs of your developer audience, some developers love dark mode themes in their IDEs during evening time while others prefer only light mode. developers used to love online events at the beginning of the pandemic where a programmer sitting in India could attend a React conference happening in Greece but eventually online conferences were not fun anymore over time, seeing a decline in sign-ups. A similar is the case when it comes to DevRel efforts.
It’s a no-brainer that without a good product, libraries and integration to use that product you can’t even begin to think of a happy developer community, hence the budget and efforts in this department have been the most significant. Comparatively fewer efforts are spent on creating good documentation and sample code which is of utmost importance to developers as seen from the survey insights. There’s still a gap between tutorials and how-to videos which developers expect but DevRel efforts are not truly up to the mark in that department giving clear signals on the areas DevRel practitioners can focus on when planning their DevRel strategy.
-----------------------------------------------------------------------------------------------
Thank you for making it this far, I hope you enjoyed this blog and my thoughts from the survey insights which are of course from my experience and understanding. I’d love to know your opinion and ideas.
Feel free to connect with me on Twitter or in the DevRelX Community and let me know what you think about this post, cheers!