--- title: "What is developer relations? | daily.dev Ads glossary" url: https://business.daily.dev/glossary/developer-relations/ description: "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." lastUpdated: "2026-10-20" llmsTxt: https://business.daily.dev/llms.txt --- ## What is developer relations? 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. Also called: DevRel. A 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. The function runs in both directions. Outward, it builds awareness and helps developers adopt the product. Inward, it carries what developers struggle with, ask for and build back to the product team, often earlier and more candidly than support tickets or sales calls do. DevRel is measured by reach and by effect: the audience of its content and talks, the developers who activate because of it, the health of the community it hosts, and the product changes it caused. It overlaps with developer marketing without being the same thing: DevRel is a function and a relationship; developer marketing is a discipline it uses. ## 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. ## 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. **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. ## 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](https://business.daily.dev/verified-company/) those developers keep following between launches. ## Developer relations vs developer advocacy vs developer marketing | | 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 | ## Go deeper - [How DevRel drives pipeline](https://business.daily.dev/resources/developer-relations-marketing-channel-how-devrel-drives-pipeline.md) - [Building a DevRel team from scratch](https://business.daily.dev/resources/building-devrel-team-from-scratch-hiring-org-structure-first-year-plan.md) - [How developer marketing, PMM and DevRel fit together](https://business.daily.dev/resources/developer-marketing-org-structure-pmm-devrel-growth.md) Related terms: [Developer advocacy](https://business.daily.dev/glossary/developer-advocacy.md) | [Developer experience](https://business.daily.dev/glossary/developer-experience.md) | [Developer marketing](https://business.daily.dev/glossary/developer-marketing.md) | [Community-led growth](https://business.daily.dev/glossary/community-led-growth.md) ### Frequently asked questions **Is developer relations marketing?** Partly. DevRel reaches developers and builds a brand, which is marketing, but it also owns docs, community and product feedback, which is not. Most teams treat developer marketing as a discipline DevRel practises alongside product and growth. **What does a DevRel team do day to day?** Writes and records tutorials, speaks at meetups and conferences, answers questions in community channels and on social, maintains sample code and SDK docs, runs programs such as champions or office hours, and reports what it hears back to product. **Where should DevRel report?** To product, marketing or engineering, depending on which the company needs most from it. The reporting line matters less than two rules: DevRel has standing with the product team, and nothing ships to developers without an engineer reading it. **How do DevRel and paid channels work together?** DevRel produces the material developers trust; paid distribution gets it in front of developers who do not already follow the team. A tutorial that reached the room at a conference can reach everyone on that stack when it runs as a native post in their feed. **How big should a DevRel team be?** One strong advocate who also owns the docs is enough to start. Add community and DX specialists when the product has enough users to sustain conversations that are not about the vendor. [All terms](https://business.daily.dev/glossary.md) | [Explore your options](https://business.daily.dev/schedule/?ref=glossary-developer-relations) | [How pricing works](https://business.daily.dev/pricing.md)