Recently I took part in a community session hosted by SlashData.
We reviewed the results from a Q4/2021 survey about developer program strategy. This post is a summary covering a subset of the topics and my thoughts on each.
You can learn more about the developer program survey, how to participate, and past results on the Developer Program Survey website.
How do program leaders spend their time, budget and effort?
Below is the results from the survey breaking down how developer program leaders spend the majority of their time.
It’s encouraging to see that program leaders are spending the majority of their time on strategy. As Benjamin Franklin famously said, “Failing to prepare, you are preparing to fail.“
When I joined Skyflow, I spent a lot of time immersing myself in the product, the problem space, meeting people and customers, and thinking deeply about strategy. I wanted to be able to put together a longterm vision. What does developer relations look like for Skyflow in 5 years? And, a short-term vision. Where will be in 6 months?
Starting with a strategy and creating a plan helped me focus where I should put my attention and how to think about hiring. There’s always a million things to do at a startup, but if you try to do everything at once, you’ll do nothing well. A strategy with clear objectives helps you tune out the distractions and focus on moving your key metrics in the right direction.
Thinking about and creating a strategy should be the foundation of any developer program. You should outline your goals, the things you’re going to measure, define a North Star metric, and plan the tactics that will get you there. However, just because you have a plan doesn’t mean it’s going to work. As Mike Tyson said, “Everyone has a plan until they get punched in the mouth.“
You need to be able to adapt. Failure is to be expected. It’s a learning opportunity. Just don’t make the same mistake over and over again.
Product influence
One component of a developer program that’s missing from this survey is time spent on collecting and sharing feedback. Or another way to think about it, time spent influencing product direction.
I think this is a core responsibility of a developer program. We should be influencing product and engineering to make sure we are creating a great developer experience. Otherwise, you might be wasting marketing efforts driving developers to a leaky bucket. I’m interested in seeing this category added to future surveys.
Internal buy-in and funding
The survey reports that 22% of a leader’s time is spent creating internal buy-in or securing funding. In a prior survey, this was 15%.
I think part of the responsibility of any program lead, regardless of function, is to spend sometime justifying their function’s existence and securing funding. It’s our responsibility to convey our program and team’s value. That being said, I think it’s unfortunately too common that developer program leaders spend A LOT of time on this and it’s a topic that continually comes up.
At Google, I felt that several times a year, I had to give presentations explaining what my team did, the value we brought to the program, the impact we’d had, but even then, I really had to fight for resourcing. Continually fighting this battle is counterproductive and exhausting.
So although it’s part of a program lead’s responsibility, I believe there should be a limit. Ultimately, it’s critical that developer programs have executive buy-in and are seen as a strategically important investment. Without that, you’ll burn yourself out trying to make people understand something they are simply not ready or interested in accepting.
Time for the DevRel CEO?
There’s been an evolution in the tech industry over the past 20 years. More and more founders and CEOs have come from an engineering background. I believe the growth in the engineer CEO has changed the cultural perception of engineers and the sense of their value to a company.
As a result, many companies see engineers as their most valuable asset. Engineers have a ton of agency about product direction, what’s important, and are very well compensated for their contributions. The engineer CEO has also helped change the landscape of companies, resulting in huge growth and investment capital for API-based companies. APIs have become the product.
I think for developer relations and related functions, a similar evolution needs to happen. We need more DevRel CEOs and founders.
If there were more successful founders with a background in developer relations, the battles DevRel leaders often face with creating internal buy-in would go away. Community, developer success, developer education, and developer experience would be seen as primary drivers of the business. The days of a startup hiring their first developer advocate where they expect that person to own strategy, create demos, own documentation, present at multiple conferences every month, create a meetup program, respond to developer support questions, make videos, write blog posts, and do three backflips every hour would be a thing of the past.
How valuable is a developer?
The survey asked program leaders about how they measure the value of a developer. The majority of respondents said they justify the program as part of product development or with a qualitative argument. However, there was a small subset of respondents that try to assign a dollar amount to the value of a developer.
I think a lifetime value (LTV) for a developer is an interesting way to articulate the potential value for a program, but there are challenges with measuring it. For example, it’s hard to know for sure whether a conversion to a paying customer was in fact due to a developer in your community influencing the decision.
Despite the challenges, you can at least estimate the value.
According to a different SlashData survey, developers influence about 65% of tool buying decisions. Using this calculation along with knowing the percentage of developers in your community that are employees of a paying customer, percentage of unique companies in your community where the first contact with that business was a developer, and with the actual LTV of a customer, you can create the following mathematical estimate for developer LTV.
Note: There’s likely other ways you could approach the estimate of developer LTV and it probably depends on how you think about activation.
The value behind a measurement like this goes back to the need to create internal buy-in. If you can articulate the LTV of a developer, that may help your executive team understand why investing in a developer program makes sense.
Need to account for people’s worldview
While LTV for a developer could be a great tactic for articulating program value, it’s very important that you try to understand the worldview of the people you’re presenting your argument to and what they value most.
Going back to my time at Google, I found the most effective argument for resource investment was based on internal cost savings, in particular SWE Days (days a software engineer spends on a task). The leads of my product area cared a lot about maximizing engineering resources. By explaining that amount of SWE Days we were losing each quarter due to the lack of developer tooling, developer support programs, and self-serve educational materials, led to me securing my first headcount.
This particular tactic might not make sense for you, but the important take away is that you must try to frame your argument in terms that will resonate with your audience. Try to understand what they care about most? What do they lose by not making the investment? How do they define success for the product or company?
Check out my article on how to influence people to prioritize developer experience for more thoughts and tactics on this.
How should developers be segmented?
The final part of the survey results presents how different program leaders segment their audience.
Surprisingly, 23% of respondents said they don’t differentiate or segment developers. Perhaps those companies have compelling reasons for not doing any kind of segmentation, but I think in most cases segmentation is essential. Even if your target audience is all developers in the world, it makes a ton of sense to segment.
Segmentation helps you better target your messaging, tactics, and improves the health of your community.
Messaging and tactics
One style of communication isn’t going to be a fit for everyone.
The messaging that appeals to the CTO of a company might be quite different than a junior developer or computer science student. The C-level probably doesn’t need all the details, they want to understand at high-level how your solution solves a pain point they have. However, the engineer that’s actually going to implement your solution needs the details.
Similarly, tactics will vary. Live code streaming on Twitch might be a great tactic to reach certain developers, but is probably not going to target the C-level.
In the past, I worked on a B2B product where our developer partners were mostly large enterprise companies. Even within this community, there were different types of companies and different levels of developers we needed to appeal to. As much as I enjoy organizing hackathons and interacting on Twitter, those tactics didn’t make sense for any of our target audience.
With large enterprises, where conversations were typically with very senior level people, we had to use a white glove approach. Even though we organized regular community workshops, these companies needed 1:1 time. To get them onboard, custom workshops, walkthroughs of how to get started, and regular checkins were needed. With scrappier, smaller companies, that made up the longtail of our community, we had to focus on self-serve and scalability.
Segmentation helps enable network effects
If your strategy for reaching developers lacks any segmentation, then the people you reach are far less likely to be connected in some way.
Consider every developer in the world as nodes in a graph and the relationships between them as edges. The graph represents the global developer network. Network density is a measurement used to measure the health and effectiveness of a network. Your network density is likely to be much smaller (i.e. less healthy), if you don’t segment and try to address everyone.
For example, assume your community is 10,000 people. The potential connections between all these people can be calculated using the formula below where n is equal to 10,000.
To calculate network density, we take the ratio between actual connections between people in the community and the potential connections as shown below.
The closer the network density is to 1.0, the healthier your network. Assuming the total community doesn’t change, your potential connections will always going to be the same, but your actual connections is greatly impacted by how spread out your audience is. By segmenting by attributes like programming language, region, expertise, vertical, or some combination of these, you greatly increase the chances that your community members know each other.
This makes for a healthier and more effective network (i.e. community) and increases the chances of spreading by word of mouth. Rather than everyone in the community being in a silo, they will be more tightly grouped and their friends and colleagues will end up hearing about your product not just from one of their connections but by multiple, increasing the likelihood of adopting your product.
Final thoughts
Thanks for getting this far.
I hope you enjoyed this recap of my thoughts on the results from the SlashData survey on building a developer program.
If you have thoughts on the survey or perhaps don’t agree with something I said, please hit me up on Twitter.
