Quick answer
Developer relations (DevRel) is the function that represents a company to developers, and developers back to the company: advocates, documentation, sample code, community and talks that help developers succeed with a product and feed their experience into it.
Developer relations
DefinitionA DevRel team usually combines developer advocacy (people who teach, demo and answer questions in public), developer experience (docs, SDKs and onboarding), community (forums, chat servers, meetups) and some developer marketing (reaching the developers who have not heard of you yet). Titles and reporting lines vary by company; the mandate is the same.
Also called: DevRel.
What does a developer relations team actually do?
Four jobs, usually spread across a few people. Advocacy: engineers who teach the product in public through tutorials, talks, livestreams and community answers. Developer experience: the docs, quickstarts, SDKs and sample apps that decide whether a trial succeeds. Community: the forum, Discord, meetups and programs where users help each other. And the feedback loop: carrying what developers struggle with back to the product team, with enough standing to get it fixed.
The split between those four varies by company. A small DevRel team is often one advocate who also owns the docs; a large one has separate advocacy, DX and community leads. What stays constant is the mandate: developers succeed with the product, and the company hears what they say.
How is developer relations different from developer marketing?
DevRel is a function; developer marketing is a discipline. DevRel produces the material developers trust (tutorials, talks, docs, answers) and holds the relationship. Developer marketing is the work of reaching developers who have not heard of you, with that material and with paid distribution, and it is practised by DevRel, product marketing and growth alike.
The two overlap most at distribution. An advocate's tutorial reaches the people who already follow the team; marketing takes it to the developers on that stack who do not. Teams that treat them as rivals end up with great content nobody new sees, or paid reach pointing at a landing page with nothing behind it.
Common mistakes
- Hiring an advocate before the docs work, so they spend the year writing docs.
- Measuring DevRel on leads and cutting it when leads lag.
- Letting marketing rewrite advocate content into a pitch before promoting it.
- Treating community as a support channel the vendor runs, rather than a place members run.
How developers experience it
- They remember the advocate who answered their question at 11pm, not the campaign.
- A tutorial that works end to end earns more trust than any claim.
- They can tell within a paragraph whether the author has used the product.
How do you measure developer relations?
- Reach: readers of tutorials and docs, viewers of talks and streams, community members. Inputs, not results.
- Activation: developers who reached a first working result after a DevRel touch, tracked by tutorial completions, sample-app clones and sign-ups from DevRel content.
- Support deflection: questions answered in community rather than by support, and docs search success.
- Product influence: changes shipped because of developer feedback DevRel carried.
- Retention: whether developers who came through community stay longer than those who did not.
Attribution is partial by nature. Report the trend and the stories alongside the numbers; a DevRel team judged on last-click sign-ups alone will be cut in the first budget review.
How does DevRel work with paid channels like daily.dev?
DevRel writes what is worth promoting; paid distribution puts it in front of the developers who do not follow you yet. A release post, a benchmark or a tutorial an advocate already wrote runs as a promoted post in the feed of developers on that stack, and the company page keeps the ones who follow.
The handoff works when the content is honest and specific, because the feed judges it against the best posts of the day. It fails when marketing rewrites the tutorial into a pitch. Let the advocate keep the byline and the voice; buy reach for it as it is.
When should a company hire its first DevRel person?
When developers are already using the product and the questions are arriving faster than engineers can answer them in passing, or when the docs are the reason trials stall. Hire an engineer who can write and teach, give them the docs and the community first, and add paid distribution once there is something worth distributing. The second hire is whichever of community or developer experience is hurting more.
On daily.dev
How it works on daily.dev
DevRel teams use daily.dev Ads to put the posts they already write (tutorials, release notes, engineering stories) in front of the developers who follow a stack, and to grow a verified company page those developers keep following between launches.
Explore my optionsDeveloper relations vs developer advocacy vs developer marketing
| Capability | Developer relations | Developer advocacy | Developer marketing |
|---|---|---|---|
| What it is | A function: advocacy, DX, community, feedback | One role inside DevRel | A discipline practised across teams |
| Main output | Developers who succeed, and product feedback | Tutorials, talks, answers, sample code | Reach: the right developers see the right content |
| Who does it | Advocates, technical writers, community leads | Engineers who teach | DevRel, product marketing, growth |
| Measured by | Activation, deflection, shipped feedback | Developers activated from content | Reads, follows, sign-ups, activation |
| Paid media | Rarely owns it | Writes what gets promoted | Buys the reach |