// Developer Relations is more than marketing. It's co-creation.

A question that framed my early MBA dissertation research is “Why does Developer Relations (DevRel) get described so differently depending on who you ask?”

Ask a senior marketing leader, and you’ll often hear something like: “DevRel is a specialised form of developer marketing.” It’s a framing that Tessa Kriesel challenges in More Than Marketing, and one I’ve heard plenty of people in the industry either defend or push back against.

I understand where the idea comes from. DevRel involves content, community, events, and advocacy. It contributes to awareness and whether developers decide to use the product. For organisations trying to draw an org chart, marketing is one of the closest boxes on the page.

But I’d argue that comparison is incomplete. DevRel can work closely with marketing, and it can absolutely sit in a marketing organisation. The problem starts when the work isn’t viewed holistically and instead gets framed solely as outward promotion. Get that wrong, and you shape the team around the wrong incentives, the wrong metrics, and the wrong story about where its value comes from.

Why developers resist marketing, and why DevRel feels different

Most developers do not want to be “marketed to” in the classic sense. They want to try the thing, read the docs, see some tangible demos and understand what their peers are saying to make up their mind. Large developer surveys keep pointing in that direction. In both the 2024 and 2025 Stack Overflow Developer Survey results, documentation, community spaces, and peer signal remain central to how developers discover and evaluate tools.

That does not mean “marketing” is irrelevant (I’ve put marketing in quotations as I believe the discipline is close to strategy than outbound promotion and advertising, but I’ll lean into the stereotype for this post). It means trust is usually earned through usefulness and proof, not promotion alone. Developers reward utility and punish hype, and that applies to how success gets measured too: earning trust, not impressions is what actually matters. I’ve felt that shift in my own community interactions. When I’m there to help developers get unstuck, the questions get sharper and the feedback gets more honest. But I’ve seen conversations tip into technical marketing, and the trust erodes fast. One of the research participants from my dissertation studies described the mechanism directly: “Trust, whether the external trust of the communities and the people that we enable and serve, takes a long time to gain and build. […] I’m teaching the rest of the company that losing trust is simple.”

In developer communities, trust builds slowly by showing up, being useful, and proving that you know your stuff. And it can be destroyed quickly by a single interaction that feels promotional, inauthentic, or self-serving. Another participant articulated the difference between marketing and Developer Relations slightly differently:

Because we talk to the developer community, we have a deep knowledge of the product and how it is used, and we are often subject matter experts for our customers. […] We can improve the product by listening to and representing them. But it’s a relation. We don’t just evangelise to developers; we advocate for them in our organisation.

That last sentence really resonates with me. DevRel advocates in both directions: outward to the community, inward to the product and wider organisation. Teams that earn trust become genuinely influential. Teams that feel like “promotion in a hoodie” risk losing it.

That bidirectional model isn’t just my framing. The developerrelations.com guide to DevRel frames developer advocacy explicitly as a two-way bridge: representing developers internally while helping them understand your technology externally. And Jeremy Meiss traces the historical evolution of the role from the “developer evangelist” spreading “good news” in one direction to the more genuinely bidirectional advocate of today.

Value co-creation: why it explains Developer Relations better than marketing does

Part of my dissertation involved an extensive literature review to identify existing research that could help explain what I was seeing in practice. The idea that value is built with customers rather than for them has been gaining ground in business thinking for some time. Ramaswamy and Gouillart made that case in a 2010 Harvard Business Review article, drawing on real-world examples from Lego to La Poste. The best academic fit I could find for the DevRel context was Value Co-creation: Concept and Measurement by Ranjan and Read, a marketing paper that explores how value is created.

In a nutshell, they explain that value is created jointly between a company and its customers, rather than on behalf of their customers. Translating into our scenario, DevRel works best when it helps developers succeed with a product/platform/tool and makes it easier for the community to influence the product and ecosystem. Ranjan and Read identify two key dimensions:

• Value-in-use: This overlaps strongly with what many teams mean by developer experience. It’s the value a developer actually experiences when using the product. Are the docs clear? Is the onboarding smooth? Can they get to first success quickly? Do they feel empowered, or blocked? You cannot broadcast or evangelise your way into that feeling, developers have to experience it for themselves.

• Co-production: This is what happens when developers start shaping the ecosystem around the product. Being able to contribute documentation improvements. Request features that meaningfully influence the roadmap. Showcase tutorials written by community members, giving back to the next developer who hits the same problem. Providing talks at meetups from people that use the tools every day. This is where developers move from consuming value into co-producing it, by learning out in the open and paying it forward. It also maps onto what some call developer-led versus community-led growth; individual value-in-use on one side, collective co-production on the other.

With that framing in mind, the overlap with DevRel becomes much clearer. In their 2021 book, Developer Relations, Caroline Lewko and James Parton identify four core DevRel activity areas: developer education, developer success, developer marketing and developer programs. Those areas align well from a value co-creation angle:

• Education improves value-in-use by helping developers get productive more quickly with the platform or tool.
• Success work creates the conditions for co-production as developers deepen expertise and become visible contributors.
• Programs create structured routes for community members to teach, mentor, build, and share (an example of co-production).
• Developer Marketing, in Lewko and Parton’s sense, is broader than promotion. It includes understanding developer segments and reaching them through authentic developer-facing channels such as events, content, and online engagement; meeting them where they are and embracing the other three pillars.

Similarly, a 2013 study on consumer engagement in a virtual brand community breaks engagement into learning, sharing, advocating, socialising, and co-developing. Doesn’t that sound a lot like what we do in Developer Relations?

Almost. DevRel’s role is slightly different, in that it helps developers experience value directly and feed what they learn back into the organisation to improve the product. In essence, a strong and authentic feedback loop between developers.

Developer-first and developer-plus: how company type shapes DevRel focus

As a brief aside, a company’s focus may help explain why DevRel can look a bit different from organisation to organisation. The underlying job stays the same, but the emphasis shifts. For example, Caroline Lewko and James Parton coin the terms “developer-first” and “developer-plus” to describe different types of companies. I hypothesised that the balance between value-in-use and co-production might shift depending on the company type:

I went into the research expecting this distinction to be a major divider. But interestingly, every participant could describe developer-first clearly while only a minority could clearly describe developer-plus. I think this is partly due to sampling bias in my respondents. I interviewed 13 experienced DevRel practitioners, but most came from technology companies rather than sectors like automotive, healthcare, or banking, where the developer audience would have a different commercial context. So this question remains open and is one of the limitations from my study. But I wanted to at least mention it here, as it may be a useful frame for thinking about how DevRel may look different across companies.

Why DevRel authenticity comes from team design, not just who you hire

Back on topic… All four DevRel activity areas only work when they are rooted in authentic advocacy. And when I say advocacy, I don’t just mean Developer Advocates as a job title. I mean a mindset that should run through the whole team, whatever the role. The work only lands if the people doing it care about the technology, care about the developers using it and are trusted enough to say hard things internally.

Chris, that all sounds great in principle, but isn’t “authentic advocacy” just a nice way of saying hire people who genuinely care? What’s actually structural about that?

One DevRel leader I interviewed explained exactly what happens when a DevRel team gets the label of “marketing in a hoodie”. They lose the thing that makes them effective. Similarly, Angie Jones, wrote on the GitHub README project that a developer advocate can become “tainted” if marketing is giving them their directives. That independence is not incidental, it is what makes the trust possible in the first place. Developers extend trust to peer advocates, not to company representatives. As another participant put it: “The value of DevRel is that you have developers supporting other developers. And so, credibility and familiarity are important.”

Organisational structure has the potential to make or break trust with the community. If the team has a reporting line that shapes their priorities towards promotional activities, or if the team is judged on typical marketing metrics, the community will pick up on that over time. They’ll realise that the team is there to represent the company’s interests, not the developers’. And when that happens, trust evaporates.

But this isn’t just cultural. It has organisational consequences too. The State of Developer Relations 2024 report shows DevRel teams sitting across a mix of marketing, engineering, product, and other reporting lines. The DevRel Bridge analysis of org charts and reporting lines shows how different placements could shape which metrics get prioritised. Those metrics, over time, shape team behaviour. That doesn’t mean a DevRel team inside marketing cannot succeed, it absolutely can. But the risk starts when the team gets pulled into short-term promotional work and judged only on traditional marketing metrics. In that setup, the work may drift toward promotion and away from bidirectional advocacy (deprioritising that feedback loop in improving the product experience).

One participant described the influence of reporting lines on team behaviour like this:

If I’m reporting to someone in product, I’ll be influenced by their metrics. If I’m reporting to someone in marketing, I’ll be influenced by their metrics. If I report directly to the CEO, I feel I’m on an equal footing with product and marketing and can coordinate directly between both.

But that’s also not an argument for every DevRel team reporting to the CEO. It is a reminder that incentives shape behaviour. The same people, with the same values, will make different decisions depending on whose targets they are asked to optimise for. It’s also worth calling out some tension here. One of the four activity areas Lewko and Parton identify is “Developer Marketing.” So yes, DevRel can include “marketing work”. But that doesn’t mean DevRel should be equated to marketing, or measured only through a marketing lens. That distinction matters for org design.

So, what changes when DevRel is framed as value co-creation?

If Developer Relations is value co-creation rather than marketing, three things follow:

1. The success metrics need to change. Impressions, reach, and click-throughs can tell you whether a message travelled. They cannot tell you whether a developer actually succeeded, or whether the product got better because of community feedback. Those are different questions entirely. You need metrics that reflect co-production and value-in-use. I like Kim Maida’s Developer Empowerment Flywheel model here, mapping the developer journey from inspiration through to active contribution and community empowerment. I’ve seen similar funnels and alternative concepts used in practice, but overall, having metrics that tell a narrative of the developer journey.

2. Programs need to be designed differently. Value co-creation doesn’t happen through broadcast alone. A webinar that generates leads is not the same as a workshop that helps developers get to first success. A content calendar is not the same as a community programme that creates contributors. As one participant put it: “I want the activities to be authentic and the outcomes to create better products and user experiences.” The programming needs to enable those things, not just produce content.

3. Organisational positioning matters. If trust is the currency, then structures, incentives, and metrics that make the team look like a promotional function have the potential to undermine the thing you’re trying to build. The team design needs to enable authentic advocacy, not just content production. So being mindful of measurements and reporting lines is important, even if there is no one-size-fits-all answer.

This doesn’t need a dramatic overhaul. But it does need an honest conversation about what DevRel really is, or risk drifting in the wrong direction.

As one participant told me:

Developer advocates are only magic when you can point them in the right direction. They don’t know how to draft a strategy. They don’t know how to speak executive. So, you’re not getting the results you want from them unless you appropriately guide them with a strategic vision, with focused audiences, segments and personas.

While I disagree with the framing that developer advocates (or DevRel broadly) lacks a strategic capability or the ability to speak executive, I do agree that the team needs to be guided by a strategic vision. And I firmly believe that vision needs to be grounded in how they influence the developer experience with those tools, frameworks or platforms (value-in-use) and enable the community to be a part of that journey (co-creation) with the wider organisation.

To succeed, DevRel needs both credibility with developers and clarity inside the business. One without the other is not enough.

In the next post, I’ll explore developer experience, because I think its pivotal to successful DevRel work. If you missed why value creation is the right frame for thinking about DevRel, start there. And if you want the wider picture, you can follow the full strategic case for Developer Relations series.

Has this post resonated with you? Is this obvious? Or are you shouting at your screen “Chris, you’re missing the point, DevRel is ….”? I’d love to continue the conversation in the comments on BlueSky below. Or if you want to chat privately, you can find me on LinkedIn.