The Three Pillars of Developer Relations

Dip your toes into Developer Relations (DevRel), and you'll quickly encounter a discipline that is as niche as it is broad. It encompasses a wide range of titles: “Developer Advocate”, “Developer Evangelist”, “Developer Relations Engineer”, “Technology Evangelist”, “Community Manager”... and that’s before considering technology-specific roles like “AI Developer Evangelist” or “Database Relations Engineer”. There are many skillsets and talents represented under the DevRel umbrella and navigating these broad definitions can prove difficult.

Yet, despite this complexity and variation, understanding the fundamental taxonomy of Developer Relations is simpler than it seems. I believe nearly all DevRel functions can be understood through three core categories: Advocacy, Community, and Evangelism. While most roles involve a blend of these areas, grasping each distinct pillar is crucial for planning your DevRel strategy, structuring roles effectively, and hiring the right people.

You won't get it perfect immediately. Communities are akin to complex data structures: you won't fully understand them until you engage with them, and you'll find yourself constantly iterating. Your users, their motivations, and how they use your products are constantly evolving – much like watching someone grow up: changing, yet fundamentally remaining themselves. Thinking about your developer community in these ways helps set realistic expectations.

Let's break down these pillars of Advocacy, Community, and Evangelism.

Advocacy: The Voice of the Developer

Advocacy serves as the interface between developers and the company or product team. It’s the mechanism through which developer feedback reaches the organization, ultimately driving improvements to the product and the overall developer experience.

This can take many forms. In its simplest form, advocacy is gathering direct feedback from community members and relaying it to Product and Engineering. When establishing a DevRel function, this is often a low-investment, high-return starting point for improving your offering. However, this anecdotal approach doesn't scale well and can sometimes prioritize the loudest voices over the most common needs.

Mature developer advocacy involves building robust and developer-driven feedback loops. Robust means these loops should be well planned, coordinated across your organization, and executed with the same care you’d apply to bringing a product to market. Developer-driven means measuring what matters from the developer's experience. It’s less of a narrow view of “support tickets closed” and more of a holistic view of “how often do our users hit roadblocks”.

These feedback loops could include structured processes for contributing to product roadmaps, streamlined bug reporting systems, targeted user surveys, or organized feedback sessions. Crucially, effective advocacy combines quantitative data with qualitative insights and testimonials, distilling this information so internal stakeholders can understand where advocacy is succeeding and where it needs improvement.

Proper advocacy also recognizes that these loops are rarely built in isolation. Strong advocates champion the entire process by securing stakeholder buy-in, designing and creating the systems, ensuring alignment across teams, and overseeing final implementation. While it might be the least outwardly glamorous part of DevRel, building these internal bridges delivers some of the most significant, and tangible business impacts. Everyone wants developers to love their products, and that adoration requires dedicated relationship work done behind the scenes.

Community: Connecting Developers

Community focuses on the bidirectional interface between developers. While your company and staff are part of the community, their role is more often as stewards rather than primary participants. Community work is about fostering and growing connections among users.

These connections can occur in online environments like Discord servers, forums, or recurring webinars. They can also be in-person gatherings such as local meetups, hackathons, or user conferences. They can be internally focused – built around your company and its products (e.g., a company Slack) – or externally focused spaces created by others (e.g., a meetup for SQL enthusiasts).

DevRel creates and stewards these places. Sometimes they’re created around a product, other times around a broader niche. Establishing community rules, defining processes for welcoming new members, creating structures and activities that encourage continued engagement, and addressing conflict fall under the community umbrella. Answering these questions effectively is crucial to building a thriving and sustainable community.

Evangelism: Spreading the Word

Evangelism represents the interface from the company or product to developers. It’s about making developers aware of your product – ensuring they know it exists. This function sits closest to traditional marketing, and like marketing, it's essential; developers can’t discover, use, and build communities around your product if they don't know it exists.

Evangelism answers the "what" and "why" for potential users, while also identifying relevant conferences, podcasts, and meetups to attend. It involves deciding what technical blog posts to write, webinars to host, and talks to give.

This discipline is about collaborating closely with Marketing teams to ensure messaging, copy, and communication strategies resonate authentically with developers and address their specific needs. It’s pursuing partnerships with influencers, seeking co-marketing opportunities, and exploring collaborations between projects. The overarching goal of evangelism is to generate genuine buzz and pique the curiosity of developers who haven't yet encountered your offerings.

Blurry Lines and Blended Roles

Advocacy, Community, and Evangelism – these are the three fundamental pillars. However, it’s common for hires to take on responsibilities that span across these categories. That's perfectly normal, but it’s vital to understand which pillars you are filling with which role so that they can be matched to the right staff. By recognizing the distinct nature of these functions you can ensure you’re focusing efforts effectively, even while most roles are blended.

Just keep in mind that DevRel roles are most efficient when prioritizing one of these three pillars. Are you primarily focused on improving your product based on user feedback? Prioritize Advocacy. Need to foster a supportive ecosystem where existing users help each other? Invest in Community. Trying to reach new developers and make them aware of your solution? Focus on Evangelism.

Conclusion

The “blurry lines” aren’t a sign of confusion but rather a reflection of the interconnected nature of building relationships with developers. Understanding the fundamental purpose behind each pillar allows you, your team, and your hires to align efforts, measure success more effectively, and adapt strategically as your product and community inevitably evolve.

This framework is just a starting point. There’s still many more questions to answer like: How do you effectively gather data and secure stakeholder buy-in for advocacy initiatives? What are the practical steps to build and run a thriving, welcoming community? Which evangelism tactics yield the best results for reaching your target developers? I’m currently writing more in-depth pieces on these and many other topics, so make sure to subscribe if you'd like to keep up to date with my latest posts.