// The four pillars of DevRel (and the foundation they rest on)

When I started reviewing the literature on Developer Relations for my dissertation, I expected to find prior academic research that reflected what DevRel teams do. The field has conferences, frameworks, books, and more opinion pieces than I can count.

What I found (at least academically) was thinner than I expected. The most structured practitioner account came from Lewko and Parton’s 2021 book, which maps DevRel activities across four primary domains: Developer Education, Developer Marketing, Developer Success, and Developer Programs, with Developer Experience at the centre as the goal that the whole system is working towards. In my previous post, I explored why DX sits at the centre. This post moves one layer out: if DX is the centre, these four pillars are the main ways DevRel teams shape it in practice.

Chris, aren’t you just restating a framework that already exists? Fair question. Lewko and Parton give us one of the clearest descriptions of what DevRel teams do in terms of activity. But what kept resurfacing in my interviews was the moderating factor that makes those activities work: a foundation of authentic advocacy. Not a fifth pillar, but an underpinning layer that makes the other four feel helpful, credible, and worth listening to.

The four pillars of Developer Relations

With that, let me walk through what each pillar looks like in practice. Here’s the short version before I dig in:

• Developer Education: documentation, tutorials, workshops, and any content that helps developers understand and use a technology effectively.
• Developer Marketing: community insight, developer personas, and peer-to-peer engagement, alongside the practical work (events, content, community presence, and social engagement) that flows from it.
• Developer Success: ensuring developers actually succeed in building with your technology, and supporting them as they grow into advocates and contributors.
• Developer Programs: formalised infrastructure (superfan programs like ambassador schemes or champion initiatives) that scales authentic advocacy beyond the core team.

Developer Education

Developer Education is the visible face of most DevRel programs. It includes documentation, blog posts, tutorials, videos, livestreams, workshops, conference talks, and any other activity designed to help developers understand a technology and use it effectively. Education is how most developers first encounter a DevRel team, and it’s where a lot of DevRel’s impact shows up.

But in the interviews, education kept showing up as friction reduction rather than content production. One participant challenged the default docs-first instinct directly:

There’s a problem where the types of content we create may not be the best way to achieve those learning goals. Sure, we can document […], but wouldn’t an interactive playground be better?

Another participant described the same issue from a different angle:

The most important thing we do is create more niche content, which the documentation team has missed. We have a ton of documentation about ‘getting started with […]’. But I do a ‘what is […]’ YouTube video, which gets 200,000 views. That shows a clear gap in our documentation.

That matters because it pushes education beyond “make more content” and into a motion of identifying where the journey is still unclear and targeting those gaps. Another leader framed this in terms of learning curve and context:

Can a developer grasp this at an evening meetup, or does it require weeks of in-depth experience?

That is a much more useful planning question than just asking what asset to publish next. It lines up with more recent industry evidence too. Instruqt’s State of Developer Adoption 2025 found that hands-on, real-world training ranked ahead of clear, step-by-step documentation as the most effective way to help developers actually get to grips with new technology.

This is also where the link back to developer experience matters. Education is one of the most visible ways DevRel improves value-in-use in practice. It reduces friction, closes gaps, and helps developers move from curiosity to first success with less wasted effort. Good DevRel education closes specific gaps, reduces specific friction, and helps the right developer get to value faster. Therefore, my recommendation is to make sure that the content format appropriately matches the gap and learning problem.

Developer Marketing

Developer Marketing in this context does not mean promotional campaigns (that distinction is important). My interviews were consistent on this point:

We don’t think that traditional marketing efforts reach developers. Instead, a peer explaining the technology would be better suited. So, we exist to bring awareness to these tools, help the developer community use them, and bring the feedback internally.

Another participant was even blunter about this:

We provide meaningful information to developers instead of your marketing stuff. So, if [marketing] comes up with something almost cringeworthy from a developer’s perspective, the idea is that we give feedback. Maybe change the angle a bit, and then this might work.

Both of those quotes point to the same issue: developer marketing only works when it feels relevant and targeted to the developers it’s intended to help, instead of sounding like a generic campaign. This is why segmentation matters. If the team does not know which developers it plans to speak to or what they are trying to accomplish, then they cannot make the story feel useful or credible. As another participant put it:

It’s super important for me to have very clear segments, personas, and micro-segments. How do I go to market in this tiny niche and get developer adoption of, say, a community that’s maybe 1000 people total? Because with 1000 people, the adoption’s easy.

That point matters more than it first appears; there is no single developer persona. Students, hobbyists, consultants, platform engineers, and product teams can all encounter the same technology with very different goals, risks, and time horizons. A student deciding what to build at a weekend hackathon and a staff engineer assessing production risk do not need the same story, proof, or path to value. They both have very different jobs to be done, and need different approaches to help understand whether the technology is right for them.

Done well, developer marketing is less about broadcasting and more about matching the story to the segment, the problem, and the stage of the developer journey. That is why I think this pillar should never be separated from feedback or from specificity of their audience. If the “marketing” activity is not helping learn who is getting value, where the friction is, and which stories are real, it is drifting away from DevRel and towards generic promotion. The job is not to talk to “developers” as a monolith, but to help developers recognise themselves in the problem, the context, and the route to value.

This also lines up with broader developer data. Stack Overflow’s 2025 Developer Survey found that developers most commonly lose interest in technologies when API quality or reliability falls short, while “good brand and public image” ranked much lower as a reason. Developer marketing is not about polishing perception, but about helping (a targeted set of) developers understand what the product is, and whether it is worth their time.

Developer Success

Developer Success is about ensuring community members actually succeed in building with your technology; not just onboarding them and leaving. It’s about understanding where they get stuck and creating the resources, community support, and feedback channels to help them move through their own goals (while surfacing what product teams need to hear). One participant captured the link between success and advocacy perfectly:

You want them to be successful at whatever they’re doing. It makes my heart sing when people say, “I built my thing using your tools”. But you want them to be so successful that they become ambassadors, so they’re saying, “You know, what’s a good tool? That one!”

There was also a more practical, longer-term version of the same point:

About 38% of our alumni and community members have introduced technology they learned at a hackathon into production at work. That might take a year or two. But they remember what they used, and that is incredibly sticky.

And one respondent mapped developer success back to the inward dimension of advocacy (and product improvement), making the link between success and feedback loops even clearer:

So, the goal of our DevRel team is to make our friends who are developers better at what they do. And that works in two directions. We try to improve them by saying, look, you can use our tools or this framework or try this framework. At the same time, we also want to improve our friends who are dev teams internally at supporting our external friends, which means taking feedback.

That is why I think success is the proving ground of authentic advocacy. The dissertation also pushed me to think about success more broadly than product usage alone. One participant described success as helping people manage their communities, avoid burnout, get funding, and use open source to further their careers. DevRel success is not just “did they activate?”, but also “did we help them become more capable, confident, and influential?”, another indicator that the value co-creation loop is working.

That dual responsibility (maintaining credibility with developers and genuine usefulness to the business at the same time) is one of the harder tensions for DevRel teams to manage. This is also where the link back to value creation matters. In the model, consequences such as product adoption and community value do not appear by accident; they are the delayed result of developers succeeding. Therefore, it’s important to measure success on a longer horizon than just activation: ‘The strongest DevRel success work often looks slow in the quarter that it happens, but a year later, it is clear why.

Developer Programs

Developer Programs are what make advocacy possible at scale. Superfan programs like ambassador schemes or champion initiatives. These create structured pathways for community members that are genuinely enthusiastic about the technology to do more, contribute content, give talks, mentor others, and act as feedback channels in early adoption and NDA scenarios. These communities help DevRel extend its reach beyond the core team, and help the most deeply invested community members get the recognition and platform they deserve.

However, the interviews made me more cautious about how these programs are framed. Programs are not where advocacy begins, but are what you build when trust already exists. One participant described these community members as:

[…] key influencers in the community and unpaid developer advocates. We get feedback directly from them under NDA, showing them what’s coming and what we’ve been working on to see how it’ll best reach the audience.

That is an important nuance. Programs are not just distribution channels, but represent part of the “trust and feedback infrastructure”. Another participant put it this way:

[…] We do almost zero consumer marketing, so when developers learn about our programs, it’s word of mouth. If I find something valuable enough to tell others, that’s the validation that we’re creating a valuable experience.

This suggests good programs are curated, not just grown. The right advocate, in the right context, telling the right story, is very different from recruiting the largest possible superfan community list. This also links back to the value co-creation post: programs are one of the clearest routes from individual value-in-use into co-production, where community members start teaching, mentoring, shaping, and extending the ecosystem themselves. Therefore, it’s important to treat programs as an extended part of the team (like “partner infrastructure”) rather than scalable promotion.

If a program is extracting content from people who have not yet experienced success, the community will spot that quickly. If it gives trusted advocates clear ways to contribute, learn, and influence, it can become one of the strongest parts of the whole system.

The foundation of authentic DevRel advocacy

Why the pillars are not enough on their own

What the four-pillar framework doesn’t quite explain is why some teams can do all four things and go nowhere, while other teams can build communities that keep going.

Thematic analysis from my 13 interviews with DevRel leaders kept pointing to the same conclusion. I call it a foundation of authentic advocacy based on trust. It is a “foundation” rather than a fifth pillar, because it is not another ‘activity category’. It is an underpinning layer that makes education, marketing, success, and programs feel credible enough for developers to engage honestly. Without it, the work across the four pillars isn’t as impactful.

What authentic advocacy looks like in practice

Ranjan and Read’s (2016) value co-creation framework supports this from a non-DevRel perspective. After reviewing 149 studies, they argue that value co-creation has two dimensions: value-in-use (experience, personalisation, and relationship) and co-production (equity, interaction, and knowledge). Their wider point is that both matter (most of the studies they reviewed focused on one or the other, which is partly why value co-creation so often only gets partially described).

That maps well onto the four pillars:

• Value-in-use is easiest to see in education and success work: targeted tutorials, workshops, and practical support all help developers get to first success with less friction.
• Co-production shows up more clearly in marketing and programs: sharper community insight which influences positioning, feedback loops through beta programs, office hours, community calls and superfan programs all give the developer community more influence over how the product evolves and how its story gets told.

A team can invest heavily in that second half and still miss the lived experience of using the product. Equally, it can create content and demonstrate the developer experience without creating meaningful ways for developers to shape what happens next. In a DevRel setting, trust is what lets those two dimensions connect. Without it, developers do not share what is really frustrating them, where the product is falling short, or become contributors or constructive critics. Authentic advocacy is what keeps that door open.

One participant put the “inbound” half of that clearly:

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.

What I mean by authentic advocacy is speaking up for developers and carrying that reality back into the organisation, while maintaining credibility so they trust you when you do it. It does not rescue a poor product on its own, but it keeps the feedback loop honest enough for teams to see friction, fix it, and earn trust rather than just asking for it.

DevRel earns the right to educate, support, and scale programs because it is close enough to developers to understand their reality, and influential enough internally to carry that reality back into the organisation. A second participant captured why that representation works in the first place:

The value of DevRel is that you have developers supporting other developers. And so, credibility and familiarity are important.

Developers can easily tell the difference between a team that is speaking with them and a team that is speaking at them. Peer credibility is what makes education feel useful rather than promotional, marketing feel relevant rather than awkward, success feel supportive rather than transactional, and programs feel earned rather than extracted.

When I reflect on my own experiences, the conversations that genuinely changed how I understood a product’s limitations happened because the developers there believed I was genuinely there to help, not to “convert”.

What breaks when trust disappears

Once the community start to suspect those motions are there to serve internal goals rather than their outcomes, the whole relationship starts to feel hollow. Developers stop telling you what they really think and the feedback gets thinner. The trust fades first and the rest of the system follows suit. A third participant was blunt about how fragile this is:

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.

And another named the test that most matters:

[…] If developers don’t feel it’s authentic, nothing requires them to show up, so they won’t. The most successful DevRel teams effectively balance what developers need and want with the company’s goal.

Trust is not just a cultural nice-to-have, it changes how the whole model behaves Education becomes content production without a learning goal. Developer marketing becomes messaging rather than listening. Developer success shrinks to activation support with no real check on whether that activation led anywhere. Developer programs become a mechanism for extracting content from people who have not yet experienced real success. The value co-creation loop quietly breaks: developers stop sharing honest feedback, the product stops improving from community input, and the whole system starts producing diminishing returns.

In other words, the four pillars are what a capable DevRel team does. But the authentic advocacy foundation is what makes that work believable enough for developers to engage with it in good faith:

Our DevRel team exists to bring credibility and authenticity to our products and services. We want people to use and love our products. […] But I want the activities to be authentic and the outcomes to create better products and user experiences.

And as one participant put it:

Trust is your most valuable currency with developers.

What this means for your DevRel strategy

My contribution from the dissertation is not “here are four pillars” (as Lewko and Parton already gave us that). It is that these pillars describe DevRel activities, but the foundation of authentic advocacy explains why developers trust teams enough to result in better products and sustained adoption.

To make that more practical, I want to give five recommendations for how to protect that foundation.

1. Protect inward advocacy. Every outward activity should create a route back into the organisation. If your talks, office hours, docs, or events never change the product, the onboarding, or how the technology is talked about externally, you are only doing half the job.
2. Match the format to the learning curve. A docs page, an interactive playground, a meetup, and a deep technical workshop solve different education problems. Treating them as interchangeable misses the point of education, and shows you’re not trying to target a specific point of friction.
3. Measure progress to value, not just reach. Time to first success, onboarding friction removed, repeat usage, community problems resolved, and product improvements influenced tells you more about DevRel’s health than impressions on their own.
4. Treat developer programs as downstream of success. Do not expect a superfan program to create advocacy out of thin air. Developers recommend products because they helped them succeed first, and the best programs give the community opportunities to shape the product.
5. Design incentives that preserve trust. Good people can still make poor trade-offs when the surrounding system rewards short-term promotional activity over long-term developer value.

The four pillars tell you what a capable DevRel team is likely to do. The foundation of authentic advocacy builds the trust that makes that work credible, useful, and worth listening to.

Next time, we’ll look at “the organisational factors that shape DevRel strategy”. If you’d like to carry on the conversation, drop a comment onto the BlueSky thread below, or drop me a DM on LinkedIn. Until the next blog post, bye for now!