DevRel commonly groups advocacy, community, education, experience, marketing, and programmes. Companies assign these responsibilities to different titles and teams, so distinguishing the functions helps define roles and strategy.
1. Developer Advocacy
Definition. A public-facing technical practitioner who teaches, demonstrates, and listens: representing the developer community to the company and the company’s capabilities to the community.
Primary work.
- Writes blog posts, tutorials, and sample code.
- Speaks at conferences, meetups, and user groups.
- Streams or records video content.
- Maintains a personal voice in public technical forums.
- Triages community feedback and represents it inside the company.
- Reviews docs, SDKs, and APIs for “developer feel.”
Best fit person. A practising engineer who genuinely enjoys writing, speaking, and teaching, who maintains technical credibility through ongoing hands-on work.
Often confused with. Evangelism (more outbound, often more product-pitched). Technical marketing (more campaign-driven, more decision-maker-targeted).
2. Developer Evangelism
Definition. Originally synonymous with advocacy, the “evangelist” label now usually signals a stronger outbound and adoption-oriented bias. Where advocacy puts the developer’s interests first, evangelism more often leads with the company’s product or platform’s importance.
The distinction is a soft one and many practitioners use the labels interchangeably. In practice:
| Advocate | Evangelist |
|---|---|
| Listens then talks | Talks then listens |
| Helps developers win with the product | Helps the product win developers |
| Often reports to product or engineering | Often reports to marketing |
| Measured by satisfaction, retention, product feedback | Measured by reach, signups, awareness |
Both are legitimate tools for different adoption problems. Early-stage products with low awareness often need more evangelism; mature products with engaged user bases often need more advocacy.
Historically, “evangelist” was the dominant term from Apple’s Guy Kawasaki in the early 1980s through Microsoft’s global Developer & Platform Evangelism organisation of the 1990s and 2000s. The shift toward “advocate” began in the late 2000s and accelerated through the 2010s as the field matured.
3. Developer Experience (DevEx / DX)
Definition. The end-to-end experience a developer has when they discover, evaluate, learn, integrate, ship, operate, and (sometimes) leave a product.
DevEx covers:
- Time to first hello world (TTFHW).
- Quality of docs, SDKs, and CLIs.
- Error messages, debuggability, and observability.
- Onboarding flows and free-tier friction.
- API ergonomics and breaking-change discipline.
- Local dev environment quality.
DevEx is owned by some combination of product, engineering, and DevRel. At larger companies it often has its own org: “VP of Developer Experience” is now a common title at infrastructure and developer-tools companies.
Two related strands exist:
- External DevEx. The experience of customers of a developer product. This is the DevRel-adjacent meaning.
- Internal DevEx (Platform Engineering). The experience of a company’s own engineers using its internal platforms. Driven by separate frameworks (DORA, SPACE, DXI, DX Core 4) and separate vendors (LinearB, Swarmia, DX, Sleuth).
See Developer experience and DevEx measurement frameworks.
4. Developer Education
Definition. Producing the content and curricula that take a developer from “never heard of this” through “shipped to production” and onward to expert.
Primary work.
- Documentation strategy and information architecture.
- Tutorials, quickstarts, getting-started flows.
- Reference docs and API documentation.
- Video courses and screencasts.
- Workshops (live and self-paced).
- Sample applications.
- Certification programs.
Best fit person. Often a hybrid technical writer / instructional designer who can write code, prose, and curricula. At larger companies this is its own org (e.g. Stripe, Twilio, AWS, MongoDB all maintain large developer-education orgs separate from advocacy).
Why it is increasingly central. In product-led growth, documentation affects activation directly. A clear quickstart and a working code sample help developers reach a useful result during evaluation. See Documentation as product.
5. Developer Marketing
Definition. Marketing whose audience is developers. Sometimes labelled B2D (Business-to-Developer).
Primary work.
- Positioning and messaging tested against developer audiences.
- Developer-targeted content distribution (newsletters, podcasts, search, video, communities).
- Persona research grounded in actual developer interviews.
- Paid and organic acquisition channels respectful of developer norms.
- Coordinated launches (release notes, blog, video, social, community AMAs).
- Conference sponsorships, booth strategy, and side-events.
Developer marketing differs from consumer or traditional B2B marketing in tone, format, and channel. Its common forms include long-form architectural analysis, technical resources without lead-capture gates, and material published by named practitioners rather than an anonymous corporate account.
Best fit person. A marketer who has shipped code or worked closely with engineers. Or an engineer with marketing instincts. The pairing of the two is often the most effective developer-marketing org structure.
6. Developer Success (Enablement / Support)
Definition. The function that ensures developers who start using the product actually succeed in shipping with it.
Primary work.
- Helping new customers onboard technically: sometimes via 1:1 conversations, sometimes by building scaled enablement programs.
- Tracking adoption signals after signup.
- Identifying and unblocking churn risks.
- Operating community Q&A, Discourse forums, and Discord/Slack help channels.
- Coordinating with engineering on common bug patterns.
Distinct from traditional support in that the goal is adoption depth, not ticket resolution. Common at API and infrastructure companies (Twilio, Stripe, MongoDB, HashiCorp), where the line between “support” and “consulting” is blurry.
7. Community Management
Definition. The operation and nurturing of the spaces where developers gather around the product, the company, or the broader technology.
Primary work.
- Running official Discord/Slack/Discourse spaces with clear rules and active moderation.
- Welcoming new members, surfacing useful answers, recognising contributors.
- Programming events (AMAs, office hours, contest weeks).
- Coordinating with advocacy on local user groups and ambassador programs.
- Reporting community health upward (retention, response time, sentiment).
Community managers do not have to be deeply technical; they need to be tech-fluent, empathetic, organised, and able to sustain long-running programmes. Jono Bacon’s The Art of Community (2012) and People Powered (2019) remain widely used references.
See Developer community building and Community platforms.
8. Developer Programs
Definition. Structured initiatives that recognise, equip, and extend the contributions of the company’s most engaged external community members.
Examples.
- Microsoft MVPs (since 1993).
- AWS Heroes (since 2014).
- AWS Community Builders.
- Google Developer Experts (GDE).
- Google Developer Groups (GDG).
- MongoDB Champions.
- HashiCorp Ambassadors.
- GitHub Stars and GitHub Campus Experts.
- Oracle ACE Program (since 2003).
- IBM Champions.
- Cloudflare Developer Experts.
- Snyk Ambassadors.
- Auth0 Ambassadors.
- Datadog Ambassadors.
- JetBrains Academy Ambassadors and Content Creators.
Programs usually offer early access, a direct line to product, exclusive swag, travel sponsorship, a private community, and visibility through speaker placement and content amplification. Their cost can be low relative to their reach, but weak selection or support leaves members with a disappointing programme and little useful work to do.
See Ambassador programs for design principles, common failure modes, and case studies.
How the disciplines compose
Not every company has all eight as distinct roles. A small startup may have one Developer Advocate who informally does six of these. A 200-person DevRel org at a large platform company will have separate teams (and separate VPs) for each.
A useful rule of thumb for sequencing as a program scales:
- 0 to 1 people: One generalist Developer Advocate who can write, code, and speak.
- 2 to 5 people: Add a Community Manager and a Developer Educator (docs/tutorials).
- 5 to 15 people: Add specialists by domain (e.g. AI, mobile, data), and a content/program manager.
- 15+ people: Add Developer Marketing, Developer Success, regional advocates, and a Director/VP layer.
See DevRel org structures for sizing and reporting models.
Primary sources
- Lewko & Parton, Developer Relations: How to Build and Grow a Successful Developer Program (Apress, 2021).
- Mary Thengvall, The Business Value of Developer Relations (Apress, 2018).
- SlashData / Developer Marketing Alliance, State of Developer Relations reports (2022 to 2024).
- Daily.dev, “Developer Advocates vs Technical Evangelists” (2024).