Developer relations | DevRel Almanac

Developer Relations (DevRel) builds and sustains relationships between a company and developers who use, evaluate, or influence its products. Its responsibilities can include advocacy, education, community building, developer experience, and developer marketing. The work has two directions: helping developers succeed and representing their needs internally. Programmes also contribute to outcomes such as adoption, retention, revenue influence, product feedback, and brand trust.

DevRel is an applied discipline at the intersection of engineering, product, marketing, and community management. It works best with enough structural autonomy to represent developers across those functions.

The two-question test

Phil Leggetter’s classic framing: every DevRel team can be evaluated by how confidently it can answer two questions:

How much do our developers like us?
How many people are they telling about us?

Strong DevRel programs collect signals continuously to answer both. Weak programs default to vanity metrics (followers, stars, event attendance) that gesture at the answer without ever providing it.

The bridge metaphor

DevRel operates as a bidirectional bridge between the company and the external developer community:

External developers  ⇄  Developer Relations  ⇄  Internal teams
                                              (product, engineering,
                                               marketing, sales)

Outbound:

Explains what the product does, why it matters, and how to use it.
Translates technical capability into accessible understanding.
Models the kind of developer the company wants to attract.
Distributes expertise across content, code, talks, and 1:1 conversation.

Inbound:

Carries developer pain, confusion, joy, and feature requests back to product and engineering.
Identifies friction in onboarding, docs, APIs, and pricing before it shows up in churn.
Validates messaging against real audiences before marketing ships it.
Identifies active community members who may later become customers, partners, advocates, or hires.

When DevRel runs primarily in one direction, it becomes either evangelism-as-marketing (all outbound) or developer support (all inbound). Both are useful functions, but neither covers the full discipline.

The umbrella

In common usage, “DevRel” is an umbrella term covering several adjacent disciplines that often share staff and reporting structure:

Developer Advocacy. Public-facing technical practitioners who teach, demo, and represent developer interests internally.
Developer Evangelism. A more outbound-oriented variant emphasizing awareness and adoption, historically associated with sales-adjacent goals. (See DevRel disciplines for the advocate vs. evangelist distinction.)
Developer Experience (DevEx / DX). The end-to-end experience a developer has with a product. Often partly owned by DevRel, partly by product/engineering, sometimes by a dedicated DX team.
Developer Education. Documentation, tutorials, courses, videos, sample apps, certification.
Developer Marketing. Marketing whose audience is developers; respects technical norms and avoids consumer-marketing tropes.
Developer Success / Enablement. Helping developers move from “tried it” to “shipped it in production.” Closely related to customer success but with technical depth.
Community Management. Operating the spaces (Discord, forum, Slack, in-person) where developers connect.
Developer Programs. Structured initiatives (ambassador, champion, MVP, student, certified-expert) that recognise and equip top community members.

Different organisations carve the umbrella differently. See Four pillars framework.

Audience characteristics that make DevRel distinct

Developers evaluate products through technical use and often influence procurement as well as adoption. Several audience behaviours require specific DevRel practices:

They verify technical claims. Working code, accurate documentation, and direct engineering answers provide evidence for marketing claims; discrepancies are often visible in public issue trackers and forums.
Peer recommendations carry technical credibility. Advice from practitioners can influence evaluation more directly than broad advertising.
They evaluate products through use. Free tiers, working tutorials, and usable SDKs let developers test a product in their own environment.
They are simultaneously evaluator, end user, and procurement influencer. They often choose tools their employer buys, so “developer-led” and “B2B” overlap.
Their experience becomes public evidence. Developers contribute documentation, integrations, and answers, and also document product failures in public channels.

These behaviours explain why technical evidence and community participation matter alongside conventional marketing for developer audiences.

Boundaries with adjacent functions

Technical marketing is a sibling function producing case studies, technical content, and sales enablement aimed at decision-makers.
Conference speaking is one tactic among many.
Customer support has different incentives and operating requirements, although DevRel often runs first-line triage in community spaces.
Sales coexists with mature DevRel and may receive influenced pipeline from it.
Company fit matters. Products that are not developer-led probably do not need a DevRel team. The 2022 to 2024 layoff wave partly corrected premature investment by companies whose products did not require one.

When does a company need DevRel?

A useful heuristic: a company needs DevRel when developers are decision-makers, integrators, or amplifiers for its product. That includes:

API-first products (Stripe, Twilio, Postman, Auth0, Algolia).
Infrastructure and developer tools (HashiCorp, GitHub, Vercel, Datadog).
Cloud platforms (AWS, GCP, Azure, Cloudflare, DigitalOcean).
Databases and data infrastructure (MongoDB, Redis, Snowflake, Databricks, Neon, Supabase).
AI model/tool providers (OpenAI, Anthropic, Hugging Face, Cohere, LangChain, NVIDIA).
Open-source-led commercial products (Elastic, MongoDB, GitLab, Confluent).

Companies whose buyer is solely the CIO and whose product is a managed service that developers never touch directly typically do not benefit from a dedicated DevRel function and would be better served by technical marketing and customer engineering.

Primary sources

Mary Thengvall, The Business Value of Developer Relations (Apress, 2018).
Caroline Lewko & James Parton, Developer Relations: How to Build and Grow a Successful Developer Program (Apress, 2021).

Phil Leggetter, “AAARRRP — Developer Relations Strategy Framework,” 2016.
Jono Bacon, People Powered (HarperCollins, 2019) and The Art of Community (O’Reilly, 2012).
SlashData, State of the Developer Nation and State of Developer Relations reports.