What is DevRel? The complete guide to developer relations

Developer relations is everywhere. Every major technology company has a DevRel team. Startups hire developer advocates before they hire marketing generalists. Conferences and communities dedicated to DevRel have sprung up globally.

Yet for all this growth, DevRel remains poorly understood. Ask ten people what developer relations means, and you'll get ten different answers. This lack of clarity creates problems: misaligned expectations, poorly defined roles, and programs that struggle to demonstrate value.

This guide aims to bring clarity. After thirty years working in and around developer relations, here's my take on what DevRel actually is and how to do it well.

Defining developer relations

Developer relations is the practice of building relationships between a company and the software developer community. It encompasses all the ways a company engages with developers who use, might use, or influence the adoption of its products.

DevRel serves as a bridge. On one side are developers: their needs, frustrations, and aspirations. On the other side is the company: its products, roadmaps, and business goals. DevRel connects the two, advocating for developers internally while representing the company externally.

The key word is "relations." This isn't one-way communication. It's an ongoing relationship that requires genuine engagement, not just broadcast marketing.

What DevRel includes

Developer relations typically encompasses several functions that may be structured differently across organizations:

Developer advocacy

Developer advocates are the public face of DevRel. Their core mission is to show developers a vision of their world with your product in it. They create content, speak at conferences, engage on social media, and build relationships in developer communities.

I've written a full guide on what developer advocates do. In brief, their responsibilities include:

• Creating technical content: blog posts, tutorials, videos, sample code
• Speaking at events: conferences, meetups, webinars, podcasts
• Community engagement: forums, Discord, Slack, social media
• Building demo applications and prototypes
• Gathering and synthesizing developer feedback

The best advocate content is "outside-in": it takes matters of great interest to developers in your target market and provides historical context, summarization of the problem, and discussion of solutions. This differs from "inside-out" content that focuses primarily on your product features. Outside-in content drives leads; inside-out content drives conversion and customer satisfaction.

Developer experience (DX)

Developer experience focuses on the quality of developers' interactions with your product. This includes:

• Onboarding and getting started flows
• Documentation quality and organization
• API design and consistency
• SDKs and client libraries
• Error messages and debugging tools

Some organizations include DX within DevRel; others structure it as a separate function. Either way, DevRel and DX must work closely together. You can't advocate effectively for a product with poor developer experience.

Community management

Community management handles the operational aspects of developer communities:

• Managing forums, Discord servers, Slack workspaces
• Moderating discussions and maintaining community standards
• Organizing community events and programs
• Supporting community-driven initiatives
• Recognizing and nurturing community leaders

Strong communities don't happen accidentally. They require intentional cultivation focused on long-term, collaborative, and technically credible activities. In other words, things that develop over time, involve mutually beneficial technical discussion, and are rooted in code. I've written about building developer communities from scratch.

Technical writing and documentation

Documentation is often DevRel's responsibility, though it may also sit in engineering or product. Your docs should represent the spine of your growth strategy. Developers will quickly scan your homepage and search for "docs" or "developers" in the top nav. They'll bypass white papers and webinar signups and head straight to your docs. Great docs can turn a skeptical developer into a fan.

Critically, your docs are now for AI. AI coding assistants like Claude, Cursor, and GitHub Copilot have become primary consumers of developer documentation. This changes what effective documentation looks like:

• Dual audience design: Your docs now serve both humans who skim and jump around, and AI assistants who parse sequentially and need complete information to avoid hallucination
• Scenario-focused content: Document not just what your API does, but what can be built with it. AI assistants recommend products based on matching developer problems to capabilities
• Complete code examples: AI needs full request and response examples to generate accurate integration code, not just interesting snippets
• Exhaustive error documentation: When AI cannot find error documentation, it hallucinates explanations. Document every error code with causes and solutions

Documentation quality becomes even more critical because AI amplifies both excellence and mediocrity. Poor documentation produces hallucinations and failed integrations. Excellent documentation drives adoption without human intervention.

This includes:

• API reference documentation
• Tutorials and how-to guides
• Conceptual and architectural documentation
• Code samples and quickstarts
• Changelog and release notes

What DevRel is not

Clarifying what DevRel isn't is as important as defining what it is:

DevRel is not just marketing

DevRel and marketing overlap, but they're not the same. Marketing is fundamentally about creating demand and driving conversions. DevRel is about building genuine relationships and earning trust.

The best DevRel programs create value for developers regardless of whether those developers ever become customers. This long-term orientation, which I call "Help First," distinguishes DevRel from marketing, even when the activities (content, events, community) look similar. Help First means genuinely prioritizing developer success over your own business outcomes, trusting that the business results will follow.

DevRel is not sales

Developer advocates sometimes generate leads and pipeline, but that's not their primary function. The moment developers feel they're being sold to, trust evaporates.

DevRel supports sales by building awareness, credibility, and trust. It may warm leads before they talk to sales. But the advocate's job isn't to close deals; it's to help developers succeed.

DevRel is not just evangelism

The term "developer evangelist" has fallen out of favor because it implies one-way communication: spreading the good word about your product. Modern DevRel is bidirectional. Advocates bring developer feedback back to the company just as much as they bring company messages to developers.

DevRel is not developer support

Support answers specific questions and troubleshoots specific problems. DevRel may do some support work, especially in community channels, but it's not the primary function.

The line can blur in smaller organizations, but mature DevRel programs distinguish between reactive support (answering tickets) and proactive DevRel (building relationships and creating resources).

Where DevRel sits in the organization

One of the perennial debates in DevRel is reporting structure. Should DevRel report to marketing, engineering, product, or stand alone?

There's no single right answer. I've seen successful DevRel programs in every configuration. What matters more than org chart placement is:

Executive sponsorship: Someone at the leadership level needs to champion DevRel and protect it from short-term pressures.

Clear mandate: The team needs to understand its purpose and how success is measured.

Cross-functional relationships: DevRel works with marketing, product, engineering, and sales. These relationships matter more than formal reporting lines.

Appropriate metrics: DevRel shouldn't be measured purely on marketing metrics (leads) or purely on engineering metrics (code shipped). It needs metrics appropriate to its unique function.

The core skills of DevRel

Effective DevRel practitioners combine several skill sets:

Technical competence: You need to understand your product and the ecosystem around it at a deep level. You don't need to be a senior engineer, but you need credibility with developers.

Communication: Writing, speaking, and explaining complex topics clearly. DevRel is fundamentally a communication function.

Community intuition: Understanding developer culture, knowing what resonates and what falls flat, sensing when a conversation is going sideways.

Empathy: Genuinely caring about developer experience and advocating for improvements even when they're inconvenient.

Self-direction: DevRel often involves ambiguous goals and independent work. You need to be able to prioritize and execute without constant direction.

Finding people with all these skills is challenging. I've written about what kind of developer advocate you need and where to find them.

Building a DevRel program

If you're starting a DevRel function from scratch, here's how I'd approach it:

Start with strategy

Before hiring anyone, answer these questions:

• Who are the developers we're trying to reach?
• What do we want them to know, believe, or do?
• What value can we provide to these developers?
• How does DevRel connect to our business goals?
• How will we measure success?

Skip this step and you'll end up with activity without direction.

Hire the right first advocate

Your first hire sets the tone for the entire program. Look for someone who:

• Has genuine technical credibility
• Is already known in relevant communities
• Can work independently with ambiguous direction
• Combines tactical execution with strategic thinking
• Truly cares about developer experience

It's tempting to hire someone junior who's eager. But your first DevRel hire will be defining the function, not just executing tasks. Invest in experience.

Focus on a few channels

You can't be everywhere at once. Pick two or three channels where your target developers spend time and go deep. This might be:

• A specific conference circuit
• A particular community (Discord, Slack, Reddit)
• Content platforms (YouTube, blog, dev.to)
• Open source contributions

Expand only after you've established traction in your initial channels.

Build feedback loops

DevRel's internal advocacy function is as important as its external work. Build systematic ways to:

• Capture developer feedback
• Surface it to product and engineering
• Track how feedback influences decisions
• Close the loop with developers who provided feedback

If DevRel is just outbound communication, you're missing half its value.

Measuring DevRel

Measuring DevRel effectiveness is notoriously difficult. I've written extensively about how to measure developer advocacy, but here's the summary:

Don't try to prove direct ROI for every activity. The causal chains are too long and complex. A conference talk might influence a deal that closes eighteen months later. You'll never prove the connection.

Build a portfolio of evidence. Track multiple metrics that together tell a story:

• Content metrics: views, engagement, sharing
• Community metrics: growth, engagement, sentiment
• Product feedback: quality and quantity of input
• Brand metrics: awareness, consideration, preference
• Business metrics: influenced pipeline, deal acceleration

Focus on trends over time. Single-point metrics are less meaningful than improvement over quarters and years.

Use qualitative evidence. Customer quotes, community sentiment, and anecdotes from sales and support all provide evidence of DevRel impact.

Common DevRel mistakes

Having observed DevRel programs across many companies, these mistakes appear repeatedly:

Treating DevRel as a megaphone. Focusing on broadcasting messages rather than building genuine relationships. Developers can tell the difference.

Ignoring internal advocacy. Only focusing on external work while neglecting to bring developer feedback back to the organization.

Hiring for speaking over substance. Prioritizing presentation skills over technical depth and community credibility.

Measuring with the wrong metrics. Applying marketing metrics (MQLs) or engineering metrics (PRs shipped) rather than developing appropriate DevRel metrics.

Expecting quick results. DevRel compounds over time. Expecting immediate ROI leads to abandoning programs before they mature.

Isolating DevRel from the business. Allowing DevRel to become disconnected from company strategy and product roadmaps.

The future of DevRel

Developer relations continues to evolve. Several trends are shaping its future:

AI transformation: As AI tools change how developers work, DevRel must adapt. Documentation becomes training data. AI assistants become a new channel. I've explored this in your docs are for AI now.

Measurement maturity: Organizations are developing more sophisticated ways to measure DevRel impact, moving beyond vanity metrics to genuine outcome measurement.

Specialization: As the field matures, we're seeing more specialized roles: DX engineers, community managers, technical writers, and developer marketers alongside generalist advocates.

Geographic expansion: DevRel is increasingly global, with programs designed to serve developers across regions and languages.

Getting started

If you're new to DevRel, here's my advice:

Read widely. I've compiled a list of the best developer marketing books which includes essential DevRel reading.

Join communities. DevRel Collective, the Developer Marketing Community, and similar groups offer peer learning opportunities.

Experiment constantly. DevRel is still a young field. What works for one company may not work for another. Develop your own approach through testing.

Help First. Whatever tactics you use, the core of DevRel is genuinely caring about developers and helping them succeed. This Help First orientation should drive everything else.

If you want to go deeper on DevRel and developer marketing more broadly, I've written an entire book on the subject. Picks and Shovels: Marketing to Developers During the AI Gold Rush covers DevRel strategy, team building, measurement, and much more.