What Is DevRel? Developer Relations Explained
DevRel (developer relations) explained: the four parts of the work, job titles, DevRel vs developer marketing, how to measure it, and a week of DevRel.
The short answer
DevRel, short for developer relations, is the work of building a two-way relationship between a company and the developers who use its product. Outbound, it helps developers succeed through docs, tutorials, sample code, posts and community; inbound, it brings their feedback, bugs and requests back to the product team.
Key takeaways
- DevRel runs in both directions: help goes out to developers, and what they say comes back in.
- The work falls into four parts: content and education, code, community, and feedback.
- Developer marketing gets developers to choose you; DevRel helps them succeed and makes sure the company hears them.
- Measure each part by what developers do, not by how much DevRel publishes.
DevRel gets described as "the people who go to conferences", "marketing for developers" or "the community team", and each of those is a slice of it. This guide gives you the whole picture: what developer relations means, the four kinds of work it covers, the job titles you'll see, how it differs from developer marketing and developer experience, how to measure it, and what a week of DevRel looks like at a small company.
If you're a startup deciding how to do DevRel without a dedicated hire, read this first for the definitions, then our guide to DevRel for startups for the routine.
What DevRel means
DevRel, short for developer relations, is the work of building a two-way relationship between a company and the developers who use its product. Outbound, it helps developers find, understand and succeed with the product: docs, tutorials, sample code, talks, posts and community. Inbound, it carries what developers say back into the company: bugs, confusion, missing features and requests.
The two directions are what separate DevRel from a content team or a support desk. A team that only publishes is doing developer marketing. A team that only answers questions is doing support. DevRel does both, and its value comes from the loop between them: what developers struggle with this month becomes next month's docs fix, tutorial or product change.
DevRel exists wherever developers are the users, or a big part of them: API and SDK companies, databases and infrastructure, developer tools, open source projects, and SaaS products with a public API or integrations ecosystem.
What DevRel does: the four parts
Most DevRel work falls into four parts. Small teams do a little of each; larger teams give each part its own people.
| Part | What it looks like | Typical output | Sign it's working |
|---|---|---|---|
| Content and education | Explaining the product and the problems it solves | Docs, tutorials, release posts, changelogs, videos, talks | Developers reach their first success without asking for help |
| Code | Making the product easy to use from code | Sample apps, quickstarts, SDK examples, integrations | Examples get copied, starred and forked; time to first API call drops |
| Community | Being present where developers talk | Answers on GitHub, Discord, Slack, forums, Hacker News, Reddit and X; meetups and events | Developers answer each other; questions get answered in public |
| Feedback | Bringing the developer's view into the company | Friction reports, feature requests with context, docs bugs, beta testing | The product team changes something because DevRel brought it in |
Content and education
The most visible part. It covers reference docs and guides, tutorials, release announcements, changelog entries, videos and conference talks. Good DevRel content is specific and honest about limits: a working snippet beats an adjective. Release communication sits here too, and it's the part small teams drop first: the feature ships, nobody writes the post, and users never hear about it.
Code
Developers learn from code faster than from prose. This part covers quickstarts, sample apps, SDK examples, starter templates and integrations with the tools your users already run. Some teams call it developer experience (DX) engineering when it extends to the SDKs and CLI themselves.
Community
Being where developers already talk, and making it easy for them to talk to each other. That includes GitHub issues and discussions, a Discord or Slack community, forums, Hacker News, Reddit and X, plus meetups and events. The job is to answer, connect people and spot patterns, not to promote.
Feedback
The inbound half. DevRel hears friction before anyone else: the confusing parameter, the missing example, the integration everybody asks for. Writing that down with context and getting it to the product team is what makes DevRel more than outreach. When the fix ships, closing the loop with the people who asked is often the most effective post of the month.
DevRel roles and job titles
Titles overlap and vary by company. These are the common ones, with what the role usually focuses on.
| Title | Main focus | Typical work |
|---|---|---|
| Developer advocate | Content, community, feedback | Writes tutorials and posts, speaks, answers developers, brings feedback in. The most common DevRel title |
| Developer evangelist | Content and outreach | The older name for an outbound-leaning advocate; many companies now say advocate |
| DevRel engineer / developer experience engineer | Code | Sample apps, SDKs, quickstarts, integrations, developer tooling |
| Developer educator | Content | Courses, workshops, learning paths, certification |
| Technical writer | Content | Reference docs and guides; often in DevRel, sometimes in product or engineering |
| Community manager | Community | Runs the forum, Discord or Slack, events and programs like ambassadors |
| Head of DevRel / director of developer relations | All four | Strategy, budget, hiring, reporting the program's impact to leadership |
At a small company one person, often a founder or an engineer, covers most of this table part time. That's normal; the question is which parts get done every week and which never do.
DevRel vs developer marketing vs developer experience
These three get mixed up because they share an audience. The difference is the goal.
| DevRel | Developer marketing | Developer experience (DX) | |
|---|---|---|---|
| Goal | Developers succeed with the product, and the company hears them | Developers discover and choose the product | The product is easy and pleasant to use from code |
| Measured by | Activation, community health, feedback acted on, content used | Sign-ups, pipeline, campaign reach | Time to first success, error rates, SDK and API usability |
| Typical owner | DevRel team | Marketing | Product and engineering, sometimes DevRel |
| Example output | A tutorial for a new feature, an answered GitHub discussion, a friction report | A launch campaign, a comparison page, a webinar | A clearer error message, a better SDK method, a faster quickstart |
They work best together. Marketing brings developers to the door, DX makes the product usable once they're in, and DevRel teaches them, listens to them and keeps both sides honest. One practical rule: if a piece of content would embarrass you in front of the engineers who built the feature, it's marketing wearing a DevRel badge.
Where DevRel reports
There's no single right answer, and each home pulls the work in a direction.
| Reports to | What it tends to prioritise | Watch out for |
|---|---|---|
| Marketing | Reach, content volume, events, sign-ups | Being measured on leads, which pushes toward promotion over help |
| Product | Feedback, betas, docs, launches | Less time for community and outreach |
| Engineering | Code, SDKs, docs accuracy, DX | Content and community seen as "not real work" |
| Its own leader (CEO or a VP) | Balance across all four parts | Needs a clear mandate and metrics to defend the budget |
At a startup the question is usually moot: DevRel reports to whichever founder runs it. As it grows, pick the home whose goals match the gap you're trying to close.
How to measure DevRel
DevRel is hard to measure because its effects are spread out and slow. Measure each part by what developers do, not by what DevRel produces.
| Part | Useful signals | Vanity signals to avoid on their own |
|---|---|---|
| Content | Docs and tutorial visits to new features, search traffic to guides, sign-ups from content | Number of posts published, raw impressions |
| Code | Sample repo clones and forks, time to first API call, quickstart completion | Number of samples written |
| Community | Questions answered, time to first answer, share of answers from community members, returning members | Member count, follower count |
| Feedback | Issues filed with context, product changes traced to developer feedback, loops closed with the requester | Number of feedback forms collected |
Pick two or three signals that match what the company needs this quarter, write down how you'll count them, and report them the same way every month. Consistent numbers beat a dashboard nobody trusts.
What DevRel looks like as a company grows
Before a DevRel hire. A founder or senior engineer owns a short loop for every release: announce what shipped, document it, listen to what comes back. A couple of hours a week, on a fixed slot. Events, ambassador programs and daily posting can wait. Our DevRel for startups guide has the cadence.
The first developer advocate. Hire to scale a loop that already runs, not to invent one. The first advocate usually takes content and community, keeps release communication and docs current, and starts a regular feedback report to the product team.
A DevRel team. Specialists appear: DX engineers for code, educators for courses, a community manager, a head of DevRel who owns the strategy and the metrics. Programs like ambassadors, conference talks and partner integrations start to pay off once the basics run without anyone thinking about them.
A week of DevRel at Acme
Acme is a made-up API for scheduling messages, with a team of 12 and no DevRel hire. One of the founders owns DevRel. This week Acme released webhook retries: failed webhook deliveries are now retried automatically for 24 hours.
| Part | What happened this week |
|---|---|
| Content | A changelog entry in plain words, an X post and a LinkedIn post with a short example, and a new docs section on retry timing and how to make handlers safe to repeat |
| Code | The webhook quickstart repo got a handler that ignores duplicate deliveries, linked from the docs |
| Community | Two GitHub discussions asked about missed webhooks; both got an answer pointing to the new docs section, and one asker was thanked for the original report |
| Feedback | Three developers asked to see failed deliveries in the dashboard. The founder filed it with links to the threads, and it went on next month's roadmap |
Nothing here needed a conference or a campaign. Each part fed the next: the release gave the content its subject, the content gave the community answers a link, and the community gave the product team its next request.
How AI is changing DevRel
AI is good at the repetitive writing that falls between the parts, and bad at the parts that depend on trust and judgement.
What AI can take off the plate: first drafts of release posts and changelog entries from the pull requests in a release, docs updates for changed behaviour, reply drafts that point to the right docs page, and summaries of what developers are asking about across channels.
What should stay human: deciding what matters, relationships, talks, community judgement, anything security-related, and the final yes before something goes public under your name.
The risks to manage: AI drafts can invent APIs, describe a beta as generally available, announce changes that were merged but not yet released, or sound like hype. Anything AI writes for developers should be grounded in the actual code and docs, checked before review, and approved by a person.
How DevRelay does it
We built DevRelay to run the content half of DevRel for teams without a DevRel hire, with a person approving everything. It watches your GitHub repositories, waits for the real release (a merge alone isn't treated as shipped), and decides which changes your users would notice. Then it drafts the release posts for X and LinkedIn, the changelog entry and a docs update when your docs don't cover the change, grounded in the pull requests, your docs and your brand voice.
For the community part, Engage finds threads on Hacker News, X and GitHub where your product or the problem it solves comes up, and drafts a reply from your docs. A person copies and posts every reply; DevRelay never posts in communities for you. Relationships, talks and deciding what your company stands for stay with you.
To try the writing side on a single pull request first, the free PR to tweet and PR to LinkedIn post tools draft a post from a pasted PR.
Frequently asked questions
What does DevRel stand for?
DevRel stands for developer relations: the function that connects a company with the developers who use its product, through content, code, community and feedback.
What does a DevRel do?
A DevRel, usually titled developer advocate, writes tutorials, docs and release posts, builds sample code, answers developers on GitHub, Discord, forums and social media, speaks at events, and reports what developers struggle with to the product team.
Is DevRel the same as developer marketing?
No. Developer marketing aims to get developers to discover and choose a product and is measured by sign-ups and pipeline. DevRel aims to help developers succeed with the product and to bring their feedback inside, and is measured by activation, community health and feedback acted on. The two work best together.
What is the difference between a developer advocate and a developer evangelist?
Mostly the name. Evangelist is the older title and leans toward outbound promotion; advocate is the more common title today and stresses advocating for developers inside the company as well as for the product outside it.
How do you measure DevRel?
Measure what developers do: visits to docs for new features, quickstart completion, time to first API call, questions answered and how fast, and product changes traced to developer feedback. Follower counts and post counts alone say little.
Does a startup need a DevRel team?
Not at first. Before a dedicated hire, a founder or senior engineer can run a short loop for every release: announce it, document it and listen to what comes back. Hire a developer advocate to scale that loop once it runs.
