// How does Developer Relations (DevRel) create value? What 13 interviews revealed.

What does value creation in Developer Relations actually look like?

I’m not asking what DevRel does, as there’s plenty of descriptions of DevRel activities out there. Nor what it should do, as there’s no shortage of opinion there either. But what does value creation (the specific mechanism by which a DevRel team contributes something meaningful to its organisation and its developer community) actually look like in practice?

I’ve spent a large part of my career in and around Developer Relations, so I’ve been thinking about this question for a while. Back in 2024, I decided to stop thinking about it and actually research it.

At the time, I was studying for an MBA at Warwick Business School (completing it in early 2025, graduating that June) and chose to make this the subject of my dissertation.

Why I spent a year researching DevRel value creation

The question of how DevRel creates value has been debated for a long time, and largely answered with opinion or anecdotes rather than evidence. Keith Casey’s A Painful Reckoning and Lee Briggs’ The Death of Developer Relations are two examples of the strength of feeling in that debate, and swyx’s journey from DevRel’s Death as Zero Interest Rate Phenomenon to DevRel is Unbelievably Back within fourteen months illustrates just how fast the narrative shifts when the evidence base is thin.

The industry is going through a period of significant change as highlighted in the State of Developer Relations reports from 2023 and 2024. From layoffs reshaping teams to AI changing how developers work, getting a clearer answer feels more urgent than ever. It has implications for how teams are structured, how budgets are allocated, how success is measured, and ultimately how the function evolves.

Developer Relations is, by design, a cross-functional and cross-cutting discipline. DevRel teams create content. They give talks. They attend conferences. They engage developer communities. They surface product feedback. They run programmes designed to grow and retain developers in an ecosystem. They partner with internal teams to resolve customer-specific issues. And they do all of this simultaneously, often without a coherent mechanism for demonstrating how it translates into organisational value.

The public-facing side of the work (travelling, talks, social presence) is valuable. It’s also the part that’s easiest to see and point to. But the stuff underneath is harder to make visible: the contribution to product adoption, to market fit, to developer experience and to the feedback loop between the developer community and the product organisation. However, this friction between the visible and invisible can cause misaligned stakeholder expectations, and eventually lead to randomisation with a team pulled in every direction and no coherent thread connecting daily activity to the outcomes that matter.

There was also an academic gap that surprised me. When I searched the major research databases for peer-reviewed literature specifically on Developer Relations, the results were light. At the time, a keyword search for “DevRel” or “Developer Relations” across Web of Science returned six items. Across Science Direct, results were slightly more numerous but largely irrelevant to the research area. Six items for a function that exists inside almost every major technology company. That gap in the academic literature tells you something: the field has been defining its own practices largely without systematic evidence-based research.

So I wanted to understand something specific: how do successful Developer Relations teams create value for their broader organisations?

Not from theory. Not from case studies of companies with large DevRel budgets, but from practitioner evidence. Real-world experience of people doing this work across a range of companies, contexts, and geographies. So I conducted 13 in-depth interviews with DevRel leaders (VPs, Directors, Senior Directors, Managers) from companies ranging from sub-200-person startups to companies with thousands of employees, spanning developer-first and developer-plus contexts across the Americas, Europe, and Asia.

I went in with several hypotheses and expected certain conclusions to be true. Some were. Many weren’t. And a few findings emerged from the interviews that I hadn’t anticipated. My dissertation earned a Distinction from Warwick Business School and I think the insights are genuinely useful for the field, so I’m finally turning them into a blog series!

The DevRel value model (in brief)

To answer the question of how DevRel creates value, I built what researchers call an antecedent, actions, consequences, and moderating factors model. Think of it as a structured way of asking: What conditions need to be in place for the team to be successful? What does the team actually do? What does success look like? And what factors either accelerate or undermine it all?

The model looks roughly like this:

• Antecedents: the conditions and context that shape how DevRel should operate. This includes the company’s orientation (developer-first or developer-plus), the stage of the product and company lifecycle, and the team’s understanding of its own purpose.
• Actions: what DevRel teams actually do. Developer education, success, marketing and programs; all built on a foundation of value co-creation with the developer community.
• Consequences: what successful DevRel teams produce. Product adoption is the headline. But the route to it is more nuanced.
• Moderating factors: the things that determine whether the antecedents and actions actually produce the consequences. From my research, and chatting with peers across the industry, this is where many DevRel teams have gaps. And this is where I think the most actionable work sits.

The DevRel measurement gap that surprised me most

Measurement is a known challenge across DevRel. A similar gap used to exist in marketing, but that discipline has evolved to the point where there are well-established frameworks connecting activity to business outcomes. I expected measurement to be a challenge here too, but I didn’t expect it to be quite as significant.

Of the 13 DevRel leaders I spoke to, only two (around 15%) could clearly demonstrate a link between their tactical activities and their organisation’s strategic outcomes. The rest had plenty of metrics: blog views, event attendance, video watch time, stars on GitHub repositories and community member counts.

As one participant put it: “Measurement has always been the trickiest part of DevRel because we’re touching so many parts of an organisation. It feels like it’s a distracted profession and hard to measure consistently. There are things that we can measure, like views on videos. But there are a lot of superficial measurements.”

This isn’t a new problem, but it is solvable. The research suggests existing frameworks and approaches that can help close this gap, and we’ll explore those as we progress through the series.

What this series will cover

Over the next eight posts, I’ll walk through the model systematically, translating the research into something that practitioners and leaders can use. The posts will cover:

• Value co-creation, not marketing: Why the authentic peer-to-peer mechanism of DevRel is distinct from traditional marketing, and why this reframe matters for how you structure and position your team.
• Developer experience: the centre of everything: Developer Experience is at the heart of the entire model. It’s also simultaneously an antecedent and a consequence, a nuance with strategic implications.
• The four pillars (and the foundation): Education, success, marketing, programs and the foundational layer that makes everything work.
• Company context: developer-first, developer-plus, and the lifecycle gap: The organisational antecedents that shape how DevRel should operate, including a gap in the existing literature.
• Developer communities are not brand communities: What the academic research on community engagement gets right and wrong when applied to developer communities.
• The feedback loop: DevRel as the primary conduit between the developer community and product organisation (one of the most underarticulated dimensions of DevRel’s value).
• From tactics to strategy: The measurement gap, the developer funnel, and a concept I’m calling RODI (Return on Developer Investment).
• The randomisation trap: Why DevRel teams get pulled in every direction, how to build the golden thread from company OKR to daily activity, and a surprisingly effective technique for protecting team capacity.

I should be clear about what this series isn’t. It’s not a definitive playbook. Qualitative research with 13 participants doesn’t generalise universally, I was transparent about the model’s limitations throughout my dissertation, and I’ll aim to continue that same level of transparency here. What it is, I hope, is a rigorous starting point for an ongoing conversation: grounded in interviews with practitioners living these challenges, informed by academic frameworks tested in adjacent disciplines, and honest about the gaps that still need filling.

If any of this resonates (or if you find yourself disagreeing), I’d love to hear from you. Drop a post on the thread in BlueSky below, or connect with me on LinkedIn.

Until the next post, bye for now!