What Is Developer Relations? A Complete Guide to DevRel in 2026
Developer relations (DevRel) is the discipline of building authentic, mutually beneficial relationships between a company and the external developers who use its APIs, SDKs, or platform. It combines engineering, marketing, community, and product feedback, turning developers into informed advocates and turning their feedback into better products.
If you have spent time around API-first companies like Stripe, Twilio, MongoDB, or Postman, you have seen DevRel in action: the conference speaker shipping an integration demo, the maintainer answering questions in a Discord channel at 11pm, the engineer who walked your bug report into a product meeting the next morning. Over the last decade that work has matured from scattered side projects into a measurable, budgeted function with its own job ladder.
This guide covers what DevRel is, the four pillars practitioners organize around, the common roles on a team, where the function sits in the org, the metrics used to prove it works, and how to build a program from scratch.
What is developer relations?
Developer relations is a strategic function that connects a company’s product to the developer community that uses or could use it. The work spans technical content, community building, conference speaking, sample code, SDK design, documentation, product feedback loops, and customer enablement. The unifying thread is that DevRel professionals serve developers first, and trust the resulting goodwill, adoption, and feedback to drive business outcomes.
That framing comes from Mary Thengvall’s 2018 book The Business Value of Developer Relations, still the most widely cited primer on the field. Thengvall draws a line between traditional marketing (push) and DevRel (pull): DevRel’s job is to make developers successful rather than sell to them. When developers are successful, they tell other developers, they adopt more of the platform, and they file the kind of detailed feedback product teams could not buy.
Where the term “DevRel” came from
The roots go back to Apple and Microsoft in the 1980s, when both hired “evangelists” to recruit third-party software developers onto their platforms; Guy Kawasaki popularized the title at Apple. The modern incarnation took shape in the 2010s as API-first companies (Twilio, Stripe, SendGrid, GitHub) realized growth depended on developers integrating their products, and the playbook looked nothing like enterprise sales. The shorthand “DevRel” appeared in titles and conference names around 2015 and is now the common label across job titles, conferences, and team charters. The Developer Relations Foundation, a non-profit organization for DevRel practitioners, gives the discipline a vendor-neutral home for shared standards and research.
Why developer relations matters now
A few things pushed DevRel from “nice to have” into a budgeted line item:
- APIs became the product. Companies whose revenue depends on developers writing code against an API cannot rely on traditional marketing funnels; the decision-maker is an engineer evaluating documentation at 2am.
- Bottom-up adoption became the norm. Individual developers choose tools and bring them into their employer, so winning developer mindshare matters before any procurement conversation starts.
- The addressable audience grew. SlashData estimates more than 40 million active developers worldwide, and reaching them at scale requires content, community, and product experience working together.
Build Better Relationships With Developers Using Moesif
14 day free trial. No credit card required.
Try for Free
The four pillars of developer relations
Most mature DevRel teams organize their work around four pillars. The framing comes out of practitioner writing on sites like developerrelations.com and matches how teams at Twilio, MongoDB, and others describe their charter internally.
Community
Community work is the relationship layer: forums, Discord and Slack groups, ambassador programs, user groups, conferences, and the ongoing one-to-one conversations on social platforms. The goal is a network of developers who help each other, surface problems early, and amplify wins. It is slow to compound, hard to measure month-to-month, often the first thing cut in a downturn, and the hardest thing to rebuild afterwards.
Content and education
Content is how DevRel reaches developers who have not heard of you yet: blog posts, tutorials, sample apps, video walkthroughs, conference talks, reference architectures. The bar is technical accuracy and usefulness, not polish. A blog post that walks an engineer from zero to a working integration in fifteen minutes beats a glossy white paper at higher altitude.
Product feedback
DevRel sits closer to the user than almost any other team in the company. Advocates and DX engineers are in support channels, on stage taking questions, and on calls with developers building integrations, which puts them in position to feed product a stream of real friction, edge cases, and feature requests. A DevRel team without a working feedback loop into engineering leaves most of its value on the table.
Developer experience
Developer experience (DX) is the sum of every touch a developer has with your product: docs, SDKs, error messages, onboarding flows, sandbox environments, sample code, time to first successful API call. DX is sometimes owned by DevRel and sometimes by a dedicated team inside product, but DevRel always has a strong opinion about it because they hear from developers when it breaks.
Common developer relations roles
The titles below show up on almost every DevRel team. Exact lines between them vary by company, and at smaller startups one person often wears two or three of these hats. The descriptions below build on the foundation in our earlier post, adding day-to-day responsibilities and the KPIs each role is held to.
Developer Advocate
The Developer Advocate is the role most people picture when they hear “DevRel.” Advocates sit at the intersection of customer success and product. Their job is to help external developers succeed with the platform and to carry those developers’ needs back to product and engineering. Day-to-day, advocates write sample code, build reference integrations, run office hours, answer questions in community channels, jump on calls with strategic accounts, file detailed bug reports, and turn recurring developer pain into product proposals. They are usually engineers or close to it.
Typical KPIs: qualified product feedback delivered to engineering, developer satisfaction in owned channels, time-to-first-successful-call for developers they work with directly, and sourced or influenced pipeline from the accounts they engage.
Developer Evangelist
The Developer Evangelist (sometimes Technical Evangelist or Technical Ambassador) is the outbound, brand-facing edge of DevRel. Where the advocate’s day is mostly inbound, the evangelist’s is mostly outbound: speaking at conferences, attending meetups, hosting hackathons, recording webinars, writing high-reach content, and being a recognizable face for the company. They need to be technically credible but do not always need to be production-level engineers; the skill set leans toward technical storytelling, public speaking, and content production.
Typical KPIs: reach metrics (talks delivered, audience size, content views), top-of-funnel developer awareness, brand share of voice, and qualified leads or signups sourced from owned content and events.
Developer Experience Engineer
The Developer Experience (DX) Engineer is the engineering-flavored seat on a DevRel team. DX engineers ship code that other developers consume: SDKs, CLI tools, sample apps, OpenAPI specs, documentation generators, code snippets in the docs, integration starter kits. They own the onboarding flow end-to-end, so they care deeply about the path from “landed on the docs” to “first successful API call.” A strong DX engineer is a full-time software engineer who treats external developers as their primary user.
Typical KPIs: time-to-first-call for new developers, SDK adoption and version uptake, documentation coverage of public endpoints, sample app freshness, and reduction in support tickets driven by onboarding friction.
Developer Marketing Manager
Developer marketing is technically a marketing function, but it works so closely with DevRel that most teams include it in the same org or at least the same standup. The goals are traditional (signups, qualified leads, attributable pipeline) but the methods look different, inbound and content-led approaches dominate because developers reject overt sales motion. A Developer Marketing Manager owns content strategy and distribution, paid channels that work with engineers (sponsored newsletters, podcast ads, conference sponsorships), developer landing pages and signup flows, and the analytics that tie it back to revenue.
Typical KPIs: developer signups, activation rate from signup to first call, content-attributed pipeline, organic search traffic, and cost per qualified developer signup.
Head of Developer Relations
The Head of DevRel (or DevRel Manager at smaller companies) owns strategy, headcount, budget, and reporting for the function. The job is part hiring, part politics, part strategy: hiring across specialized roles, making the budget case against more easily-attributable functions like sales, building the metrics dashboard that proves DevRel is working, and deciding which communities, channels, and conferences to invest in. Many DevRel leads keep a public-facing role and continue to write or speak themselves.
Typical KPIs: overall developer activation and retention, qualified pipeline sourced or influenced by DevRel, NPS across the program, team retention, and program ROI as a ratio of investment to attributable revenue.
Where DevRel sits in the org
There is no single right answer to where DevRel should report. The three common homes, marketing, product, and engineering, each shape the work differently.
- Inside marketing, DevRel tends to be content- and demand-heavy with strong attribution to pipeline. The risk is getting pulled into traditional marketing motions (gated content, lead chasing) that erode developer trust.
- Inside product, DevRel tends to be feedback- and DX-heavy with strong influence on the roadmap. The risk is under-investment in outbound community and content work, which are harder to tie to product KPIs.
- Inside engineering, DevRel tends to be technically deep with strong credibility in front of developers. The risk is that the function gets treated as a side project to “real” engineering and starves for hiring and budget.
Many mature programs split the difference: DX engineering sits inside product or platform, developer marketing sits inside marketing, and a dedicated DevRel team owning advocacy, evangelism, and community reports to a senior leader carrying the cross-functional charter.
How to measure developer relations success
This is where most DevRel programs struggle and where most competitor posts go thin. DevRel can absolutely be measured. The trick is choosing the right metrics for each layer of the funnel and instrumenting the product so the data is available. Think in five layers.
Awareness and reach. Top-of-funnel signals the program is being seen: unique visitors to developer content, organic search traffic on target queries, conference talk attendance, podcast listens, social reach, share of voice against named competitors. None of these tie cleanly to revenue on their own, but they are leading indicators for everything downstream.
Activation and adoption. The most important DevRel metrics live here, and they require instrumenting the developer journey from signup through first value. Track time-to-first-call (median minutes from signup to first successful API request), time-to-hello-world, activation rate (signups that hit first-call within seven days), and SDK adoption by language. These tell you whether your docs, onboarding, and DX investments are paying off.
Engagement and retention. Once a developer has made their first call, do they keep calling? Track 30/60/90-day retention curves, API call volume per active developer, feature adoption across the API surface, and activation-to-paid conversion. Retention curves are an honest mirror for DevRel: a smooth curve means the product and DX are working; a sharp drop-off after week one means onboarding is broken even if the conference talks landed.
Community and content. Track community contribution rate (members who answer at least one question per quarter), content engagement (time on page, scroll depth, repeat visits), NPS among active developers, and the volume and quality of product feedback delivered into engineering each quarter.
Business impact. Tie it back to revenue. Track sourced pipeline (opportunities that started with a developer engagement DevRel owns), influenced pipeline (opportunities that touched DevRel-owned content or events along the way), expansion revenue from accounts where DevRel has active relationships, and program ROI as the ratio of fully-loaded program cost to attributable revenue.
The reason most DevRel programs cannot answer “is it working?” is not that the metrics do not exist, it is that the data is scattered across marketing automation, product analytics, the docs platform, the community platform, and a half-dozen spreadsheets. Closing that gap is an instrumentation problem, which is where we fit in. For more on what good looks like, see our companion piece on best practices for developer relations programs.
How to build a developer relations program
If you are spinning up DevRel for the first time, four moves matter more than the rest.
Define your developer ICP. “Developers” is not a market. A backend engineer at a Series C fintech evaluating a payments API has nothing in common with a hobbyist building a Discord bot. Pick the profile that maps to your revenue and write down their stack, seniority, company size, and the problem you solve for them.
Pick your channels deliberately. You cannot be everywhere. For most B2B API companies the channels that tend to pay off are a docs site that is genuinely good, a blog that ranks on queries your ICP searches, a presence at two or three conferences a year where your ICP goes, and one community channel where you can have ongoing conversations.
Instrument the developer journey. Before you scale content or community, make sure you can see what happens after a developer lands on your docs. Track signup, first call, second call, and the integration milestones that matter for your product. Our guide on great developer experience goes deeper on the instrumentation pattern, and tracking a developer’s journey from documentation visit to first API call covers the funnel end-to-end.
Close the feedback loop with product. Set up a weekly or biweekly cadence where DevRel feeds aggregated developer feedback into a product owner who acts on it. Without that loop, advocates burn out delivering insights that go nowhere.
Developer relations tools and resources
A short, opinionated list worth bookmarking:
- Moesif, an analytics platform built for measuring the developer journey end-to-end, from first docs visit through signup, first API call, activation, and long-term retention.
- Mary Thengvall, The Business Value of Developer Relations (Apress, 2018), a widely cited primer on why DevRel exists and how to make the business case for it.
- The Developer Relations Foundation (dev-rel.org), vendor-neutral non-profit with working groups on metrics, ethics, and career frameworks.
- DevRel Collective Slack community, invite-only Slack where practitioners trade tactical advice.
- SlashData / Developer Economics surveys, the most cited quantitative data on global developer behavior.
For more, see our developer relations and marketing content hub and our developer relations interview questions for hiring teams.
Measuring what matters: how Moesif helps DevRel teams
For API-first products, the most useful DevRel signals usually live in request data: who signed up, who made a first call, which SDK they used, where they hit errors, and whether they came back a week later. We built Moesif to connect those events into funnels and cohorts so DevRel is not relying only on page views, Discord anecdotes, or signup counts. The practical use cases we see most often: funnel reports from first docs visit through activation, cohort retention curves to test whether an onboarding change moved the needle, segmenting by SDK or language to see where integrations stall, and identifying individual developers who hit an error or stalled mid-integration so an advocate can reach out before they churn. If you’re running a DevRel program and trying to prove it works, the analytics layer is usually the missing piece. See our developer relations platform for details.
Frequently asked questions
What does a developer relations engineer do?
A developer relations engineer (often a Developer Advocate or DX Engineer) writes code that other developers consume, helps external developers succeed with the platform, and carries feedback back to the product team. Day-to-day: building sample apps, answering questions in community channels, speaking at conferences, writing technical blog content, and filing detailed product feedback.
How do you become a developer relations engineer?
Two common paths: coming from software engineering and adding public speaking, writing, and community skills, or coming from technical content and community work and adding hands-on coding ability. Hiring managers look for both: a GitHub history that shows you ship code and a public footprint that shows you communicate.
What is the difference between developer relations and developer marketing?
Developer marketing is a marketing function with traditional KPIs (signups, leads, pipeline) tuned for a developer audience. Developer relations is broader: community, advocacy, evangelism, developer experience, and product feedback. The two overlap heavily and almost always partner closely; at smaller companies one person sometimes does both.
How much does a developer advocate make?
Compensation varies widely by company, location, and seniority. Public salary data and reports from DevRel practitioner communities put senior Developer Advocate total compensation at well-funded US tech companies broadly in the $180K-$300K range, with leadership roles (Head of DevRel, VP DevRel) reaching higher; salaries at startups and outside the US are usually lower.
Related Articles
API Strategy
Leveraging AI For a Better API Strategy
Learn how to leverage AI to build and fortify your API strategy. Improve design, governance, documentation, and align APIs with business outcomes.
API Strategy
The 5 Best Mixpanel Alternatives of 2025
Learn about the best Mixpanel alternatives to determine the right analytics solution for your use case.
API Development
How to Leverage Moesif Effectively for API Observability
Effectively leverage Moesif for API observability through best practices for integration, event enrichment, custom actions, and engineering workflow integrat...
API Strategy
How to Build an Internal Chargeback Model for Your API and AI Usage Using Moesif
Use Moesif to implement internal chargebacks and enable precise API and AI cost attribution for better transparency and resource optimization.