Last month we got together with the DevRelX Community to look into and discuss the latest Developer Program Leaders survey results. The session was joined by our research analysts and a panel of Developer Program Leaders Forum experts.
Together we deep-dived into how Developer Relations practitioners prioritise their resources and activities, and justify the value of their developer program, offering everyone in the community an insight into how they compare against the industry’s practices, especially in times of uncertainty.
You can rewatch the full session and get access to the results at devrelx.com/dpl-survey
Since not all audience questions were addressed during our recent Developer Program Leaders Forum session, we are back for a spotlight series with our Forum experts!
In today’s spotlight is Katie Miller, Director of Developer Marketing at Slack, who answers your questions, and shares tips and takeaways from the 10th Developer Program Leaders survey.
Continue reading below or enjoy the video of the on-demand Spotlight Session with Katie!
Are DevRel practitioners spending enough time researching?
The thing I find interesting about this chart (see below) is not what it says, but what it doesn’t say. For example, how do folks differentiate the research they do for creating a strategy from general research? Or did they answer the developer strategy question with the assumption that research was baked into it and that the stand-alone question was browsing SlashData research independent of focused planning work? If not, what informs planning?
If research isn’t something folks engage with, why? Is it time? Cost prohibitiveness? Usefulness? A sense that the research isn’t custom enough, or custom research takes too long or is too resource intensive? Having the right skills themselves, or within the org, to apply them to program planning?
And then…why is so much time spent strategizing vs doing?
My hypothesis (assumption?) is that it’s because we wage a constant battle for the resources to implement said strategies, along with constantly fluctuating (and often conflicting) goals and priorities from partner organizations, that create a never-ending cycle of making plans, justifying plans, starting to implement plans, and changing plans.
Does this resonate? Too cynical? And at the root of it is…when folks see that stat, is the reaction “Wow, I need to spend more time doing” or is it “Yeah, feels about right…this is the right balance to get the work done?”
And this weaves back to the initial conundrum about strategy vs research – all of the questions above would be research questions to better inform strategy - how resources are used, what work needs to get done, etc. and yet, would we make the time within our strategic planning to get the answers to said questions.
And now all I can think about is “If you give a Mouse a Cookie” or “There’s a Hole in the Bucket, dear Liza,” or “I’m Henry the 8th I Am” or any story or song that brings you back to the beginning. So what will it take to break the vicious cycle of planning so we can focus on the virtuous cycle of the developer flywheel? Perhaps…research?
Now, let's dive into the audience questions!
How do you distinguish between Developer Relations vs Developer Marketing vs Sales?
It’s easy to say “It depends” or “They’re not distinct” and the truth is, depending on the company’s developer offering (ex: is it platform first or an “API to extend the product?”), where the team sits organizationally, how big the functions are, etc… the lines can definitely blur. And truthfully, some short-term nimbleness can help products and strategies flex (although not advisable longer term, as lack of clarity can affect professional growth, the ability for impact to be appreciated, and burnout). But if I must define them:
Developer Relations are the front-line subject matter experts, building relationships and trust, without a direct quota, through empathetic listening and feedback collection, content creation and delivery, internal advocacy, and community building. Note: content can include docs, samples, code labs, tutorials, product overview videos, social media, conference talks, etc. This does NOT mean they’re not involved in Sales. In fact, they ideally should be for top customers and should be OK referencing sales meetings in reporting out the impact. However, I do believe that sales metrics should not be a primary goal or metric for Developer Relations. Success should be measured by reach, engagement, satisfaction, and product adoption.
Developer Marketing builds and manages the campaigns and programs that marries a company’s developer product offerings with Developer Relations activities to propel the “developer flywheel” - driving awareness, engagement, adoption, and trust. This can include high-touch programs from which Sales can benefit, such as invitation-only technical workshops, champions networks, advisory boards, etc., and like DevRel, should be OK to acknowledge the influence on sales outcomes. However, like DevRel, sales metrics should not be the primary goal or metric for marketing. Success should be contributing to reaching, engagement, satisfaction, and adoption metrics defined by Devrel.
Sales…sells the product. They’re defined by quota. If sales of developer products are done well, it recognizes a) the importance of IC devs’ buy-in in influencing sales (see: empathy and trust); b) the importance of involving DevRel in strategic sales calls as a trusted, empathetic expert; and c) the importance of partnering with marketing to execute high touch technical programs for strategic customer accounts.
When is it time to scale with more people on the DevRel team?
My guidance on scaling is when the program or programs have internal buy-in and external adoption, and are secure enough to have a longer-term, sustainable impact (ie: they’re deemed critical to the delivery of company goals and objectives), but there are “single points of failure” in the execution of the programs. It’s nuanced for sure - companies cannot (and shouldn’t) endlessly scale. But if there’s a team of 1-2, and their departure would mean business-critical work cannot get done, it’s probably worthwhile considering advocating for resources. In the absence of a full-time headcount, temp, vendor, contractor, or agency partners can stop gaps, but in the long term can be more costly (ex: heavy investment in product training/company knowledge that is lost more quickly because they’re short-term contributors). Something underlying this question though is 2 other questions - what do we do in the absence of resources, and HOW do we advocate for an additional hire? For the former point, if the work is mission critical, this is where leaning into cross-functional partners and advocating for budget for agencies and contractors may come in. If it’s the latter, it’s really about showing the impact of work to date, and the gap that is left if it isn’t filled.
What are some best practices for scaling developer programming with a super small team/limited resources?
I used up my scale tips on the question above:) But in a nutshell:
Ruthlessly prioritize
Build really strong cross-functional relationships and find opportunities to mutually amplify work through each other’s initiatives
Use data from “proofs of concept” to demonstrate impact and opportunity to advocate for more resources. Being lean in a time of growth is not sustainable for people’s productivity and well-being. Scale and scrappiness ideally are short to medium-term.
How important is content syndication in your marketing plans?
Developer Marketing IS content syndication. Content reigns supreme - the nuance is what content, for whom, with what intention, and what distribution strategy.
If you sense a developer "doesn't like to be sold to" then how do you sell to them?
Developers are OK with buying if the product is trustworthy, useful, and worth the value. The goal is no BS. But that doesn’t mean it cannot be clever and fun. Like any good marketing, it’s about knowing the audience, and delivering campaigns and programs that get them what they need in a way that resonates with their motivations and preferences!
Kudos to Katie for her insightful answers!
You can rewatch the full session and get access to the latest Developer Program Leader survey results at devrelx.com/dpl-survey. To be part of peer discussions like this one, get notified about the next survey and access more industry data, join the DevRelX Community!