# DevRel Directory - full documentation
> The main place for Developer Relations: guides, tools, communities, and jobs for DevRel professionals.
# Start Here (https://devrel.directory/docs)
# Welcome to devrel.directory [#welcome-to-devreldirectory]
devrel.directory is an open knowledge base for Developer Relations.
It explains what DevRel is, how the roles differ, and how to build a program that holds up in practice.
The content is written for practitioners, cites its sources, and is free to use.
## DevRel in the AI era [#devrel-in-the-ai-era]
How DevRel changes when developers bring AI agents - the practical guide: [Agents Are Your New Developers](/docs/ai-era/agents-as-your-new-developers).
llms.txt, Markdown mirrors, and the structure that makes documentation retrievable and quotable by AI assistants: [Writing Docs LLMs Can Use](/docs/ai-era/docs-for-llms).
Why an MCP server is a DevRel surface, what to expose through it, and the work that makes one succeed: [MCP Servers Are the New SDK](/docs/ai-era/mcp-servers-as-devrel-surface).
Why classic web analytics undercount AI-driven adoption and what you can measure honestly instead: [Measuring Adoption You Cannot See](/docs/ai-era/measuring-ai-driven-adoption).
## Start with the fundamentals [#start-with-the-fundamentals]
What DevRel is and what it is not, with the research behind the definition: [Definition of Developer Relations](/docs/fundamentals/definition).
Why developer communities compound like network effects and what that means for a business: [The Importance of DevRel](/docs/fundamentals/importance).
Advocate, evangelist, developer experience, developer marketing: how the roles differ and where they overlap: [Roles and Responsibilities](/docs/fundamentals/roles-and-responsibilities).
Objectives, audience, and measurable goals for a DevRel program: [Crafting a DevRel Strategy](/docs/fundamentals/devrel-strategy).
How to build research-backed personas instead of guessing who your developers are: [Understanding Developer Personas](/docs/fundamentals/understanding-developer-personas).
## Put it into practice [#put-it-into-practice]
The core activity clusters, when each earns its place, and how to avoid activity soup: [DevRel Activities](/docs/practices/devrel-activities).
From the first fifty members to programs that scale, plus behaving well in communities you do not own: [Community Building](/docs/practices/community-building).
Content types, writing craft, distribution, and a pipeline a small team can sustain: [Content Creation](/docs/practices/content-creation).
## What is Developer Relations? [#what-is-developer-relations]
Developer Relations (DevRel) is the function that connects a company and the developers who build with its products.
Done well, it drives adoption, feeds honest feedback back into the product, and builds communities that outlast any single campaign.
"DevRel is more than just a job title - it's a strategic approach to building and nurturing relationships between companies and developers." - From our [Definition of Developer Relations](/docs/fundamentals/definition)
## More on the site [#more-on-the-site]
Longer pieces on strategy and planning live in the [blog](/blog).
What changed on the site and when: [changelog](/changelog).
The whole site is open source on [GitHub](https://github.com/fabianhug/devrel-directory/).
## This knowledge base is growing [#this-knowledge-base-is-growing]
The docs are being reworked and expanded section by section.
If a topic you need is missing or a page falls short, open an issue on GitHub or contribute directly - the [contributing guide](/docs/additional-resources/contributing) explains how.
---
# Contributing to devrel.directory (https://devrel.directory/docs/additional-resources/contributing)
# Contributing to devrel.directory [#contributing-to-devreldirectory]
devrel.directory is an open resource, and contributions from people who do DevRel work are what keep it useful.
## What contributions are welcome [#what-contributions-are-welcome]
* **Docs improvements**: corrections, sharper examples, or expanded sections anywhere in the knowledge base.
* **Directory listings**: tools, communities, and resources for the [directory](/directory), submitted through the [listing form](https://github.com/fabianhug/devrel-directory/issues/new?template=directory-submission.yml).
* **Job posts**: open DevRel roles for the [job board](/jobs), submitted through the [job form](https://github.com/fabianhug/devrel-directory/issues/new?template=job-submission.yml).
* **Event submissions**: DevRel conferences and meetups for the [events page](/events), submitted through the [event form](https://github.com/fabianhug/devrel-directory/issues/new?template=event-submission.yml).
## How changes land [#how-changes-land]
The site lives at [github.com/fabianhug/devrel-directory](https://github.com/fabianhug/devrel-directory).
Docs and code changes land as pull requests against that repository, which the maintainer reviews before merging.
Listings, jobs, and events go through the issue forms above and are added the same way after review.
## The editorial bar [#the-editorial-bar]
Docs contributions are held to a concrete standard: specific guidance, real examples, numbers where they exist, and honest tradeoffs.
Generic filler that could appear on any site gets rejected, even when it is well written.
The bar is strict for a structural reason: every docs page ships verbatim into the site's AI-facing mirrors at [/llms.txt](/llms.txt) and [/llms-full.txt](/llms-full.txt), and each page is served as raw Markdown at its own `.md` endpoint.
Thin content therefore does not just read badly on the page - it degrades how AI assistants represent the site to developers who never visit it directly.
## Getting help [#getting-help]
* Open an issue on [GitHub](https://github.com/fabianhug/devrel-directory/issues)
* Message [@0xfabs](https://x.com/0xfabs) on X
---
# Agents Are Your New Developers (https://devrel.directory/docs/ai-era/agents-as-your-new-developers)
## What changed [#what-changed]
For two decades, developer adoption started with a person: someone searched, read, evaluated, and typed the first API call.
That assumption is now quietly wrong.
An increasing share of first contact with a developer product is an AI system acting on a developer's behalf:
a coding agent scaffolding an integration inside an editor, a chat assistant comparing options and quoting docs, or an autonomous agent following a runbook end to end.
The developer is still in charge, but they arrive later: after a model has already read your docs, formed an opinion, and maybe written the first hundred lines against your API.
This is not a prediction, it is observable in traffic patterns most vendors already have:
AI crawlers and agent user agents in server logs, signups with no preceding web session, and support questions that quote model-generated code.
The practical shift for DevRel: your first user is often not a human anymore.
Your product now needs to make a good first impression on a machine that reads everything and forgives nothing.
## What agents need, versus what humans need [#what-agents-need-versus-what-humans-need]
Human developers tolerate ambiguity.
They skim, infer, hold context across pages, and forgive a stale screenshot if the idea is clear.
Agents fail differently, and what they need is stricter:
1. Deterministic quickstarts.
A step that "usually works" or depends on unstated environment assumptions will stall an agent every time.
Every prerequisite must be written down, in order, with no hidden state.
2. Copy-paste-complete snippets.
Code blocks that are runnable as-is, with imports, versions, and placeholders clearly marked.
An agent will run exactly what you wrote, including your typo.
3. Exact error messages.
Agents match errors verbatim against your docs.
Documenting the precise string of every common failure, with its fix, is now one of the highest-leverage docs tasks that exists.
4. Stable URLs and anchors.
Retrieval systems and model memories reference URLs; every broken link is an answer your product no longer appears in.
5. No marketing in the critical path.
A human skips the value proposition paragraph; a model treats it as signal and repeats it instead of the setup steps.
Keep positioning on marketing pages and keep task pages about the task.
Notice that every one of these also makes docs better for humans.
Optimizing for agents is not a separate track; it is the strictest version of docs quality you already believed in.
## The new funnel [#the-new-funnel]
The classic funnel was search, docs, signup, first call.
The agent-era funnel has different stages, and DevRel can influence every one of them:
1. Model training data.
Models learn your product from public text: docs, blog posts, forum answers, open-source code.
Influence: publish substantial, accurate, openly accessible content and keep it consistent, because contradictions in public text become contradictions in model answers.
This compounds slowly and is hard to reverse, in both directions.
2. Agent retrieval.
At question time, many assistants fetch live pages: your docs, your [/llms.txt](/llms.txt) index, community threads.
Influence: serve clean Markdown, keep an accurate llms.txt, make key pages reachable without JavaScript, and answer recurring questions in indexable places instead of ephemeral chat.
3. Tool docs and machine surfaces.
Agents that act, not just answer, work through machine-readable surfaces: OpenAPI specs, SDK types, MCP servers, CLI help text.
Influence: treat these as first-class documentation, because for an agent they are the product.
4. First successful call.
The agent runs the quickstart.
Either it works deterministically, or the developer watching concludes your product fights their tools.
Influence: instrument time-to-first-successful-call and treat every agent stall as a bug.
## Audit your quickstart with an agent [#audit-your-quickstart-with-an-agent]
The single most useful exercise: have a coding agent follow your quickstart cold, in a clean environment, with no help.
1. Start a fresh session with a capable coding agent and give it one instruction: "Integrate this product into a new project, following its documentation."
2. Watch where it stalls: the unstated prerequisite, the placeholder it cannot resolve, the step that assumes a dashboard click, the error message that appears nowhere in your docs.
3. Fix every stall point in the docs, not in the prompt.
The next thousand agents will not have your prompt.
4. Repeat monthly and after every breaking release, the same way you would run any regression test.
If an agent cannot complete your quickstart, an increasing share of your evaluations now fail before a human ever sees your product.
Teams consistently overestimate how well their docs survive this test until they run it.
## What this means for the DevRel role [#what-this-means-for-the-devrel-role]
The work shifts in emphasis, not in purpose.
The mission described in [the definition of DevRel](/docs/fundamentals/definition) stands: build trust with developers and remove friction between them and the product.
What changes is where the friction lives:
* Documentation work moves further up the priority list, because docs are now both the human interface and the machine interface.
* Community answers become training data: a correct, well-written answer in a public forum keeps teaching models for years.
* Developer experience work gains a new test subject: the agent-run integration, which is stricter than any human tester.
* Measurement needs new instruments, covered in [measuring adoption you cannot see](/docs/ai-era/measuring-ai-driven-adoption).
The rest of this section covers the concrete practices:
[writing docs LLMs can use](/docs/ai-era/docs-for-llms), [MCP servers are the new SDK](/docs/ai-era/mcp-servers-as-devrel-surface), and [measuring AI-driven adoption](/docs/ai-era/measuring-ai-driven-adoption).
## Related [#related]
* [Writing docs LLMs can use](/docs/ai-era/docs-for-llms) for the documentation practices in depth
* [Understanding developer personas](/docs/fundamentals/understanding-developer-personas) - agents arrive on behalf of personas you should still know by name
* [The importance of DevRel](/docs/fundamentals/importance) for the compounding logic that AI distribution accelerates
---
# Writing Docs LLMs Can Use (https://devrel.directory/docs/ai-era/docs-for-llms)
## Two audiences, one source [#two-audiences-one-source]
Documentation now serves two readers: the developer, and the AI systems answering that developer's questions.
The second reader consumes more of your docs than any human ever will, and it decides what to quote.
The good news: the two audiences want almost the same thing.
Clear structure, self-contained explanations, runnable code.
The difference is tolerance.
A human recovers from a vague heading or a screenshot of code; a retrieval pipeline just returns someone else's page instead.
## llms.txt and llms-full.txt [#llmstxt-and-llms-fulltxt]
The llms.txt convention gives AI systems a machine-friendly entry point to your site:
* `/llms.txt` is a Markdown index: the site's name, a one-line summary, and a curated list of links with descriptions.
It tells an agent what exists and where, without HTML noise.
* `/llms-full.txt` inlines the full documentation content as one Markdown file, for consumers that want everything in a single fetch.
This site practices what this page preaches:
[devrel.directory/llms.txt](/llms.txt) is the live index, and [devrel.directory/llms-full.txt](/llms-full.txt) is the full-content mirror.
Every docs page here is also available as raw Markdown by appending `.md` to its URL, and the page actions above let you copy the page or open it in an assistant directly.
Two honest caveats belong next to any llms.txt advice:
1. Adoption by AI vendors is uneven and changing; treat llms.txt as cheap insurance and a clear signal of intent, not a guaranteed pipeline.
2. An llms.txt that promises pages which 404, or describes content that no longer exists, is worse than none.
Generate it from your real content, never by hand.
## Structure that retrieves well [#structure-that-retrieves-well]
Retrieval systems pull chunks, not sites.
Whether your content surfaces depends on how well each chunk stands alone:
1. One concept per page.
A page that answers one question cleanly beats a mega-page where the answer hides in section four.
2. Self-contained sections.
Each heading plus its content should make sense without the surrounding page, because that is exactly how it will be quoted.
Write headings that state the topic ("Rotate an API key") rather than tease it ("Keeping things secure").
3. Descriptive frontmatter.
Titles and descriptions become index entries, search snippets, and llms.txt lines; write them as accurate one-line summaries, not slogans.
4. Code blocks with language tags.
Tagged blocks survive Markdown conversion and tell every consumer what they are looking at.
5. Text, not pixels.
Content locked inside interactive components, videos without transcripts, or images of terminal output is invisible to most of this pipeline.
Interactive elements can stay, but the information in them must also exist as text.
6. Stable anchors.
Heading anchors are how deep links and citations survive; renaming them casually breaks both.
## Markdown-first distribution [#markdown-first-distribution]
The durable strategy underneath all of this: keep a plain Markdown mirror of your documentation and let machines fetch it.
* Serve each docs page as raw Markdown at a predictable URL, next to the HTML version.
* Keep the mirror generated from the same source as the site, so it can never drift.
* Make copy-for-AI trivial: a copy-as-Markdown action on every page costs little and removes the last excuse for a model to work from a scraped, mangled version.
Markdown-first also future-proofs you.
HTML rendering fashions change; UTF-8 text with headings has outlived every one of them.
The test for all of this is empirical: paste a docs URL into an assistant and ask a real integration question.
If the answer misquotes or misses your docs, find out what the model actually received, then fix that.
## What not to do [#what-not-to-do]
The common failure modes, all observed in the wild:
* JavaScript-only content.
If the text renders only after client-side execution, a large class of crawlers and fetchers sees an empty shell.
* Paywalled or login-walled quickstarts.
Whatever is behind the wall does not exist in model answers; keep at least the evaluation path public.
* Screenshots of code and terminal output.
Unreadable to the pipeline, uncopyable for humans, stale within months.
Ship text with syntax highlighting instead.
* PDF-only documentation.
Technically parseable, practically mangled: layout, code, and tables rarely survive.
* Aggressive bot-blocking without allowlists.
Blanket rules written for scrapers routinely block the assistants your developers use; decide your crawler policy deliberately, as covered in [measuring AI-driven adoption](/docs/ai-era/measuring-ai-driven-adoption).
* Marketing prose inside reference pages.
Models compress; make sure what survives compression is the instruction, not the adjectives.
## A checklist to ship this quarter [#a-checklist-to-ship-this-quarter]
1. Generate `/llms.txt` from your content source and link it in your footer.
2. Add `/llms-full.txt` or per-page Markdown endpoints, whichever your stack makes easy; both is better.
3. Rewrite the ten most-retrieved pages for self-containedness: descriptive headings, complete snippets, exact error strings.
4. Add transcripts or text equivalents for anything that currently lives only in video or images.
5. Run the assistant test on your top five integration questions and file a docs issue for every wrong answer.
None of this requires new tooling budget.
It is editorial discipline applied with a new reader in mind, and it improves the docs for humans at every step - the same point [agents are your new developers](/docs/ai-era/agents-as-your-new-developers) makes about the shift as a whole.
## Related [#related]
* [Agents are your new developers](/docs/ai-era/agents-as-your-new-developers) for why the machine reader now matters
* [MCP servers are the new SDK](/docs/ai-era/mcp-servers-as-devrel-surface) for going beyond text into executable surfaces
* [Measuring AI-driven adoption](/docs/ai-era/measuring-ai-driven-adoption) for knowing whether any of this works
---
# MCP Servers Are the New SDK (https://devrel.directory/docs/ai-era/mcp-servers-as-devrel-surface)
## What MCP is [#what-mcp-is]
The Model Context Protocol (MCP) is an open standard that lets AI applications connect to external tools and data sources through a common interface.
A product ships an MCP server describing its capabilities as tools; any MCP-capable client, such as coding agents, desktop assistants, and IDEs, can then discover and call those tools on a developer's behalf.
The [specification and ecosystem documentation](https://modelcontextprotocol.io) cover the protocol itself; this page covers why it belongs on a DevRel roadmap.
The DevRel-relevant property: an MCP server makes your product usable by every agent-equipped developer without them reading anything first.
The agent reads the tool descriptions, the developer states an intent, and your product gets exercised.
That is an onboarding surface, whether or not anyone planned it as one.
## The new SDK, with the old lessons [#the-new-sdk-with-the-old-lessons]
SDKs earned a generation of DevRel attention because they were where developer experience was won or lost.
MCP servers now sit in the same position, with the same failure modes:
* An SDK with confusing method names produced support tickets.
An MCP server with vague tool descriptions produces agents that call the wrong tool, silently, at scale.
* An SDK with a broken install ruined evaluations.
An MCP server that fails auth setup ruins evaluations that no human even witnesses.
* A well-designed SDK taught the product's mental model through its structure.
A well-designed MCP server does the same for both the agent and the developer watching it work.
Treat the server as a product interface with documentation properties, not as an integration checkbox.
## What to expose [#what-to-expose]
Resist the temptation to mirror your entire API.
An agent choosing among eighty near-identical tools performs worse than one choosing among five sharp ones, and every extra tool description consumes context the agent needs for the actual task.
A practical starting shape:
1. The three to five highest-value actions.
The operations a developer would demo in their first hour: create the core resource, query it, trigger the flagship capability.
2. Docs search as a tool.
A `search_docs` tool that returns relevant documentation snippets turns your entire knowledge base into agent context on demand.
For many products this single tool outperforms everything else on the server.
3. Read-only introspection.
Safe tools that let an agent inspect current state ("list projects", "get usage") make every subsequent action smarter and are low-risk to expose.
4. Deliberately excluded: destructive operations without confirmation semantics, admin surface, anything you would not want executed by a probabilistic caller.
Start narrow; widen with evidence.
Auth deserves early design attention.
The smoother pattern today is scoped API keys or OAuth flows that the client initiates once and reuses; anything requiring manual token surgery per session will filter out most of your audience.
Whatever you choose, document the failure states exactly: agents quote error strings at their humans, so those strings are now user-facing copy.
## Tool descriptions are documentation [#tool-descriptions-are-documentation]
The text fields in your MCP server are read by a model every single time it decides whether and how to call you.
They deserve the same editorial care as API reference, and the same review process:
* State what the tool does, when to use it, and when not to, in plain declarative prose.
* Describe every parameter with its format, constraints, and a realistic example value.
* Say what the tool returns, including the shape of errors.
* Version and changelog the descriptions; a silent description change alters agent behavior as surely as a code change.
Write tool descriptions as if they will be read aloud to a competent developer who has never seen your product.
That is almost literally what happens.
## The DevRel work around a server [#the-devrel-work-around-a-server]
Shipping the server is the engineering half.
The DevRel half determines whether anyone uses it:
1. Examples that exercise it.
Publish transcripts and short videos of real tasks completed through the server, in the popular clients.
Developers evaluate MCP servers by watching them work.
2. Registry and directory presence.
Clients ship with registries and curated lists, starting with the official [MCP registry](https://registry.modelcontextprotocol.io); being listed accurately, with working install instructions per client, is table stakes distribution.
3. A quickstart per client.
Installation differs across editors and assistants.
One page per major client, each following the deterministic-quickstart rules from [agents are your new developers](/docs/ai-era/agents-as-your-new-developers), beats one generic page.
4. Feedback loop instrumentation.
Log which tools get called, which fail, and where agents give up, then feed that into the same product-feedback loop DevRel already runs for humans.
5. Community support surface.
Questions about the server will land in your community; make sure answers become searchable text, since those answers train the next model.
## Deciding whether to build one [#deciding-whether-to-build-one]
An honest gate, in the spirit of every other investment on this site:
Build one early when your product is developer-facing infrastructure, your API's core loop fits in a handful of operations, and your audience already lives in agent-equipped editors.
Wait when your product requires heavy human judgment per operation, when destructive actions dominate the API, or when you cannot yet resource the documentation and support work above.
A half-maintained MCP server with stale descriptions actively misleads agents and burns the trust the rest of your DevRel program builds.
Whichever you choose, decide it deliberately and revisit quarterly.
The measurement half of that decision lives in [measuring AI-driven adoption](/docs/ai-era/measuring-ai-driven-adoption).
## Related [#related]
* [Agents are your new developers](/docs/ai-era/agents-as-your-new-developers) for the funnel this surface serves
* [Writing docs LLMs can use](/docs/ai-era/docs-for-llms) for the documentation discipline the server depends on
* [DevRel roles and responsibilities](/docs/fundamentals/roles-and-responsibilities) for where this work sits in a team
---
# Measuring Adoption You Cannot See (https://devrel.directory/docs/ai-era/measuring-ai-driven-adoption)
## The measurement gap [#the-measurement-gap]
Classic developer marketing measurement assumes a visible journey: a person visits pages, analytics scripts fire, campaigns get credit, and the funnel reconciles.
AI-mediated adoption breaks every link in that chain:
* AI crawlers and assistant fetchers do not execute your JavaScript beacons, so that traffic is invisible to script-based analytics.
* Agentic browsers do run JavaScript, but their sessions land in your analytics indistinguishable from humans, inflating the "human" bucket instead.
* Answers are consumed inside chat interfaces; the developer may never load your site before signing up.
* When they do arrive, they arrive directly at a signup or install command, stripped of referrer context.
* The influence often happened weeks earlier, inside a model's training data, where no attribution system reaches.
The result: teams see flat or declining docs traffic while API signups hold or grow, then misread it as a content problem.
The traffic did not disappear; it moved to readers your analytics cannot see.
The dangerous response is forcing the old dashboard to stay green: blocking AI crawlers to protect pageviews, or walling docs behind logins to force attribution.
Both trade real adoption for measurement comfort.
The blocking decision is per class of machine traffic, not one switch:
* Training crawlers feed future model weights.
Blocking them is a slow-compounding opt-out of the funnel's first stage, affordable only if your category's training data already leans your way.
* Retrieval and assistant fetchers are answering a live developer question right now.
Blocking them turns real evaluations away at the door and is almost never worth the saved bandwidth.
* Agentic browsers ride full browser sessions.
You cannot block them without blocking humans, so plan for measurement contamination instead.
## What you can measure today [#what-you-can-measure-today]
None of these are precise.
Together they form a usable picture:
1. AI traffic in server logs.
Script-based analytics miss AI crawlers and fetchers, but your server logs do not.
Count requests by known AI user agents (model-provider crawlers, assistant fetchers, agent frameworks) and track the trend, not the absolute number.
Watch which pages they fetch most; that is your machine-readership ranking.
2. Machine-surface fetches.
Requests for [/llms.txt](/llms.txt), /llms-full.txt, per-page Markdown endpoints, and your OpenAPI spec are almost purely non-human signals, which makes them unusually clean indicators.
3. Dark-funnel signups.
Accounts created with no prior web session from that identity.
This bucket always existed; its growth rate is your best single proxy for chat-mediated adoption.
Agentic-browser evaluations can create a prior session, so treat it as a floor, not an exact count.
4. Self-reported attribution.
A free-text "how did you hear about us" on signup, actually read by a human monthly.
Developers say "asked Claude", "ChatGPT suggested it", "my coding agent used it" with surprising frequency, and the phrasing tells you which surface did the work.
5. Support and community tells.
Questions that quote model-generated code, or reference instructions you never wrote, indicate models are onboarding people onto your product, correctly or not.
## Leading indicators worth tracking [#leading-indicators-worth-tracking]
The lagging metrics above confirm what already happened.
The leading ones tell you where answers are forming:
1. Presence in model answers.
Monthly, run a fixed set of category prompts ("best way to do X", "compare tools for Y") across the major assistants, with search enabled and disabled.
Record whether you appear, how accurately, and what gets cited.
Keep the prompt set stable so the trend means something.
2. Accuracy of model answers about your product.
Ask the assistants your top ten real integration questions and grade the answers.
Wrong answers are a docs bug with a distribution channel; fix the source text they retrieve, then re-test.
3. MCP server installs and tool-call volume, if you ship one, per [MCP servers as the new SDK](/docs/ai-era/mcp-servers-as-devrel-surface).
4. Agent-framework and registry integrations.
Being packaged into agent toolkits and client registries is distribution that compounds ahead of any traffic you can see.
## Reporting honestly [#reporting-honestly]
The credibility rules from classic DevRel measurement apply double here, because every number is soft:
* Report direction and mix, not false precision.
"Machine fetches up 40 percent quarter over quarter, dark-funnel signups now a third of new accounts" is honest; a decimal-pointed AI-attribution percentage is fiction.
* Present it as triangulation: several weak signals agreeing beat one fabricated strong one.
* Keep definitions stable and written down, the same discipline as any [goal-setting framework](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr).
* Say what you cannot know.
Executives handle "attribution here is directional" better than they handle discovering it later.
The pitch to leadership is not "we can now measure AI adoption".
It is "adoption is moving somewhere our old instruments cannot see, here are the instruments that can, and here is the trend they show".
## A minimal instrumentation plan [#a-minimal-instrumentation-plan]
Shippable in a week, without new vendors:
1. Add a log-based count of AI user agents and machine-surface fetches to whatever dashboard you already run.
2. Add the free-text attribution field to signup and calendar a monthly reading of it.
3. Define the dark-funnel signup segment in your existing analytics.
4. Write the fixed prompt set for presence testing and run it for the first time.
5. Put a quarterly reminder on reviewing your crawler policy, so blocking decisions stay deliberate.
Then leave the definitions alone for two quarters.
Trend lines need time to become evidence, and this corner of measurement changes fast enough without self-inflicted definition drift.
## Related [#related]
* [Agents are your new developers](/docs/ai-era/agents-as-your-new-developers) for the funnel these instruments observe
* [Writing docs LLMs can use](/docs/ai-era/docs-for-llms) for improving what the machines retrieve
* [Goals planning with OKRs](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr) for wrapping these metrics in accountable goals
---
# Definition of Developer Relations (https://devrel.directory/docs/fundamentals/definition)
## A working definition [#a-working-definition]
Developer Relations is the function that owns the relationship between a company and the developers who build with its product.
The relationship runs in both directions.
Outward, DevRel earns developers' trust by removing friction between them and the product: documentation, onboarding, examples, support, community.
Inward, it represents developers' needs to product, engineering, and leadership with enough authority to change what gets built.
The academic framing agrees: Oliveira et al. \[2021] describe DevRel as a strategic function that builds and maintains relationships with developer communities, partner companies, and other key stakeholders through programs that engage and support developers.
The practitioner shorthand is shorter: help developers succeed with your product, and make sure your company hears what they need.
The litmus test is the direction of information flow.
A team that only pushes messages out is doing developer marketing.
The "relations" in the name means the channel carries feedback in - or it is not DevRel.
Trust is the working capital of the whole function.
Developers extend it slowly, verify it constantly, and withdraw it permanently when they catch a function optimizing for the company at their expense.
Every position in the rest of this page follows from protecting that capital.
## What DevRel is not [#what-devrel-is-not]
The definition gets muddier every year because adjacent functions borrow the label.
Four boundaries are worth defending explicitly.
### Not marketing with a hoodie [#not-marketing-with-a-hoodie]
Developer marketing is a legitimate discipline: campaigns, launches, paid reach, conversion.
The mistake is dressing it as DevRel - putting a technical-looking person on stage to deliver what is structurally a pitch.
Developers detect the switch immediately, and the cost lands on the whole function: once an audience decides your advocates are salespeople, no future talk, post, or forum answer from your company is read at face value.
The two disciplines can and should coexist, but they need different names, different metrics, and usually different people.
Marketing optimizes for reach and conversion this quarter.
DevRel optimizes for developer success and trust across years.
Measure one by the standards of the other and you break it.
### Not sales [#not-sales]
A DevRel team with a quota stops being believed, because its usefulness rests on the freedom to say "our product is the wrong fit for your use case."
A salesperson cannot say that sentence; an advocate must be able to.
Pipeline often follows good DevRel work - developers who succeed become champions inside buying decisions - but pipeline can be a consequence of the work, never its assignment.
The moment an advocate's compensation depends on a deal closing, every technical recommendation they make is compromised, including the honest ones.
### Not just conference talks [#not-just-conference-talks]
Talks are the most visible sliver of the job, which is exactly why they distort the picture.
The bulk of real DevRel work is unglamorous: rewriting the quickstart, answering the same question in the forum for the fortieth time, synthesizing feedback into filed issues, fixing the onboarding snag that stalls every new integration.
A team measured on talks delivered optimizes for airports, and a team hired for stage presence alone cannot do the desk work that actually moves adoption.
Treat speaking as one activity among many that must earn its place against a goal - the full activity map lives on the [DevRel activities page](/docs/practices/devrel-activities).
### Not the support queue [#not-the-support-queue]
DevRel answers developer questions, but it is not the support organization.
The distinction is what happens after the answer: support resolves the ticket, while DevRel asks why the question keeps arriving and fixes the doc, the error message, or the API design that generates it.
A DevRel team that becomes the de-facto support queue loses the time for exactly that second step, which is where its leverage lives.
Route the volume to support, and keep DevRel on the patterns.
One more boundary: DevRel is not a single job.
Advocacy, documentation, community, developer experience engineering, and developer marketing are distinct roles with distinct skills, and conflating them produces bad hires in both directions.
The role taxonomy has its own page: [roles and responsibilities](/docs/fundamentals/roles-and-responsibilities).
## Where DevRel should report [#where-devrel-should-report]
The honest answer: the reporting line matters less than the metrics it imposes, because metrics determine behavior.
But since the box on the org chart usually decides the metrics, the box is worth arguing about.
The default position for a developer-first company: DevRel should report into Product.
The inward half of the definition - carrying developer needs into roadmap decisions - requires a seat where roadmaps are actually decided.
A DevRel team inside Product can file the feedback where it becomes work; a DevRel team three reporting layers from product decisions can only write memos.
Engineering is a strong second home, and sometimes the better one when the work is docs-heavy and DX-heavy: SDK quality, API design feedback, reference documentation.
The trade-off is that engineering leadership rarely defends community and content work when headcount tightens.
Marketing can work, under two conditions that are frequently not met: leadership must be fluent in developer-audience norms, and the team's goals must genuinely be awareness rather than leads.
The predictable failure mode is inheritance - a DevRel team inside marketing inherits MQL targets and campaign calendars within a few quarters, drifts into lead generation, and burns the trust the function exists to build.
If your marketing organization can hold the line on that, the placement is fine; most cannot.
Sales is not a home for DevRel under any conditions, for the reasons in the previous section.
Three rules that hold regardless of the box:
1. The reporting line must never force lead or pipeline metrics onto the team.
2. DevRel needs a named executive sponsor who can defend multi-quarter payoffs, because most of the work compounds slowly.
3. The goals must be written down and tied to business outcomes - the [DevRel strategy page](/docs/fundamentals/devrel-strategy) covers how.
If you take one position from this page: never let DevRel report into an organization that is measured on this quarter's revenue.
The function's entire value is built on developers believing it is not trying to close them.
## The definition shifts with company stage [#the-definition-shifts-with-company-stage]
The one-paragraph definition holds everywhere, but what it means in practice changes with the company around it.
Hiring against the wrong stage's definition is one of the most common ways DevRel programs fail.
### Before product-market fit [#before-product-market-fit]
Here DevRel is a feedback loop with a person attached.
The job is to get the first hundred developers to a working result and report back, in specific detail, why everyone else failed.
The right hire is founder-adjacent: technical enough to fix docs and examples directly, close enough to the product team to change the product itself.
Community programs, conference circuits, and content calendars are premature at this stage - there is no community yet, and the product is still changing under every piece of content you write.
### Growth stage [#growth-stage]
Here DevRel is friction removal at scale.
The individual attention that worked for the first hundred developers cannot reach the next ten thousand, so the work shifts to leverage: documentation coverage, self-serve onboarding, a community where peers answer each other, content that answers the questions the team used to answer by hand.
This is the stage where [developer personas](/docs/fundamentals/understanding-developer-personas) and a written strategy stop being optional, because the team can no longer hold every developer in its head.
It is also the stage where [community building](/docs/practices/community-building) becomes a genuine program rather than a founder replying fast.
### Platform and enterprise scale [#platform-and-enterprise-scale]
Here DevRel is ecosystem stewardship.
The audience is no longer only your direct users - it is partner developers, agencies, marketplace builders, and companies whose businesses depend on your platform's stability.
The work adds new surfaces: partner enablement, deprecation policy, versioning discipline, and defending the ecosystem's long-term health against the company's short-term incentives.
At this stage the inward half of the definition is the harder half, because a platform that breaks its developers' trust at scale rarely gets it back.
## The definition shifts with product type [#the-definition-shifts-with-product-type]
Lewko and Parton \[2021] draw the most useful product-type distinction: developer-first versus developer-plus.
In a developer-first company, the developer is both the user and the effective buyer - API companies and developer tools.
Here DevRel sits close to the core product function, because docs, onboarding, and DX are not supporting material; they are most of the product surface a customer ever touches.
Underinvesting in DevRel at a developer-first company is underinvesting in the product.
In a developer-plus company, the product is bought and used by a broader audience, and developers extend it - platforms with app stores, plugin ecosystems, and integration marketplaces.
Here DevRel is an ecosystem growth function: its job is to make building on the platform attractive and profitable enough that third parties keep doing it.
The metrics shift accordingly, from direct adoption toward ecosystem health - active integrations, partner-built value, marketplace quality.
Open-source companies are a third case that cuts across both.
The community is simultaneously user base, contributor base, and free-tier audience, and DevRel manages the boundary between the open project and the commercial product.
The definition gains a stewardship duty toward people who will never pay, because their contributions and credibility are what make the commercial side worth paying for.
## The definition in the AI era [#the-definition-in-the-ai-era]
The mission does not change when the first reader of your docs is a model instead of a person: build trust, remove friction, carry feedback inward.
What changes is where the friction lives, because a growing share of first contact with developer products now happens through AI agents acting on a developer's behalf.
That shifts documentation and machine-readable surfaces further up the priority list and adds a new, stricter test subject for developer experience work.
The full argument lives in [agents are your new developers](/docs/ai-era/agents-as-your-new-developers).
## Related [#related]
* [Roles and responsibilities](/docs/fundamentals/roles-and-responsibilities) for the role taxonomy this page deliberately does not duplicate
* [The importance of DevRel](/docs/fundamentals/importance) for the business case and the compounding logic
* [DevRel strategy](/docs/fundamentals/devrel-strategy) for turning the definition into goals, audiences, activities, and metrics
* [DevRel activities](/docs/practices/devrel-activities) for the concrete work the definition translates into
* [Agents are your new developers](/docs/ai-era/agents-as-your-new-developers) for how the definition holds up when the first user is a machine
***
Sources & References:
* "Developing Successful Developer Relations Programs in Blockchain Data Companies: A Metrics-Driven Approach" by Fabian Hug | 2024
* [Raphael Oliveira, Camila Ajala, Davi Viana, Bruno Cafeo, and Awdren Fontão. Developer Relations (DevRel) Roles: an Exploratory Study on Practitioners' opinions.](https://dl.acm.org/doi/10.1145/3474624.3474628) September 2021. doi: 10.1145/3474624.3474628.
* "Developer Relations: How to Build and Grow a Successful Developer Program" by Caroline Lewko and James Parton, 2021
* [What is Developer Relations and why does it exist?](https://seanfalconer.medium.com/what-is-developer-relations-and-why-does-it-exist-37bf4ee6d3db) by Sean Falconer | October 2020.
* [DeveloperRelations.com - What is developer relations?](https://developerrelations.com/guides/what-is-developer-relations)
* [What is Developer Relations (DevRel)? A Complete Guide](https://www.jonobacon.com/2023/04/02/what-is-developer-relations-devrel-a-complete-guide/) by Jono Bacon | April 2023
---
# DevRel Strategy (https://devrel.directory/docs/fundamentals/devrel-strategy)
This page is the quick reference.
For the full walkthrough with worked examples, survey data, canvases, and a 30-60-90 day plan, read [DevRel Strategy - A Comprehensive Guide](/blog/2024-11-06-devrel-strategy).
## What a DevRel strategy is [#what-a-devrel-strategy-is]
A DevRel strategy is the written answer to four questions: what outcome the business needs, which developers you serve, what you will do for them, and how you will know it is working.
It is a living document, not a launch artifact - you revise it as the product, the community, and the market change.
Everything else in the DevRel toolbox - personas, journey maps, OKRs, 30-60-90 plans - exists to sharpen one of those four answers.
If you can state all four on a single page, you have a strategy; if you need a deck to explain it, you probably have a wishlist.
## Goals [#goals]
"Clearly define your goals. Is the goal to increase awareness of your stack? Build a loyal developer community? Gather actionable feedback for upcoming product development?" - Dani Passos
Goals tie DevRel to something the business already cares about: adoption, retention, support cost, product quality.
Pick two or three, give each a number and a deadline, and let everything else wait.
Example goals that pass that test:
* Cut median time from signup to first successful API call from 45 minutes to 15 by end of Q2.
* Get 50% of community support questions answered by peers within 24 hours by end of year.
* Land five developer-reported issues on the product roadmap every quarter.
* Grow traffic to problem-focused docs pages by 40% in six months.
* Reduce setup-related support tickets by 30% after the onboarding rework ships.
Two caveats on timeframes.
Goals set only for the next quarter produce a pile of initiatives with no long-term shape.
Goals set beyond 12 months are fiction in fast-moving spaces - plan in shorter cycles and reassess often.
For turning goals into OKRs with SMART key results, use the [goal planning guide](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr).
## Audience [#audience]
"Developers" is not an audience - it is millions of people with different stacks, skill levels, and decision-making authority.
Segment until you can name who you are serving, then validate that the segment is large enough, valuable enough, and reachable with your current resources.
Example segments that are specific enough to act on:
* Backend engineers at seed-to-Series-B startups integrating a payments API for the first time.
* Data engineers at enterprises evaluating your warehouse connector against two alternatives.
* Hackathon and student builders who need a working result in one afternoon.
* Technical leads who will never write the integration themselves but must approve it.
Segment along four filters: technical (stack and platforms), user (experience and authority), organization (company size and industry), and market (geography, language, regulation).
Then turn your top two to four segments into personas, so the whole team argues about the same imagined person instead of a vague crowd.
The [developer personas page](/docs/fundamentals/understanding-developer-personas) covers how.
Segmentation is not a one-time exercise.
Revisit it every six to twelve months, because the segment that matters today may not be the one that matters next year.
## Activities [#activities]
Activities are how the strategy becomes visible work - and they only count when they map to a goal and a segment.
Start from where your audience actually drops off in their journey, not from what the calendar offers.
Concrete activities, each tied to the kind of goal it serves:
* A quickstart that gets your primary segment to a working result in under 15 minutes (adoption).
* A weekly hour in the community and support queue, logging repeated questions (community health, feedback).
* A monthly feedback synthesis that turns the month's questions into filed product and docs issues (product influence).
* A hands-on workshop built for one named segment at the one conference they actually attend (awareness, evaluation).
* Fixing the single worst onboarding snag developers hit each week (developer experience).
Fewer, repeated activities beat many occasional ones: two things done every week outperform six done sporadically.
The full activity map, including when each cluster earns its place, lives on the [DevRel activities page](/docs/practices/devrel-activities).
## Metrics [#metrics]
"There's a myth out there that DevRel is hard to track. Sure, there are activities that we participate in that are hard to track or hard to prove the ROI of (since developers need 4+ touch points before they engage). However, DevRel as a function is not hard to track when you define your strategy clearly, set the appropriate OKRs based on your objectives, and create thorough metric tracking." - Tessa Kriesel
Pair every activity with one signal you would actually act on.
Metrics that work, with their caveats:
* Time to first successful API call: the best leading indicator of onboarding health, but only if you measure the real integration path, not the polished demo path.
* Quickstart completion rate: reveals where developers stall, though instrumenting it takes real work.
* Time-to-first-answer and share of peer-answered questions: honest community health signals, unlike raw member counts.
* Traffic on problem-focused queries and content-assisted signups: meaningful reach, where total pageviews alone are not.
* Active projects retained month over month: the adoption truth, but a lagging one - it moves quarters after your work does.
* Roadmap items traceable to developer feedback: the metric that proves DevRel's value to product and engineering peers.
* Developer satisfaction surveys: useful direction, weak precision - small samples and happy-user bias distort them.
Attribution in DevRel is genuinely fuzzy, because developers need multiple touchpoints before they engage.
That is an argument for choosing metrics carefully, not for skipping measurement.
## Common failure modes [#common-failure-modes]
### Activity without goals [#activity-without-goals]
The team does a little of everything because everything is defensible: a conference here, a Discord there, a blog post when time allows.
This is activity soup - always busy, rarely measurable, and first in line when budgets tighten.
The test: for every item on the calendar, name the goal it serves; if you cannot, it is serving the calendar.
### Metrics theater [#metrics-theater]
The quarterly report is full of numbers that can only go up: cumulative signups, GitHub stars, event attendance, newsletter subscribers.
Numbers that cannot go down cannot tell you anything is wrong.
The test: if a metric could never embarrass you, it cannot inform you either - report at least a few metrics that could.
### Strategy-as-slide-deck [#strategy-as-slide-deck]
The strategy was written once for an executive review, approved, and never opened again.
A strategy that does not change what the team does next week is decoration.
The test: revisit it quarterly and name what you started, stopped, or changed because of it; if the answer is nothing, you do not have a strategy in use.
## Related [#related]
* [DevRel Strategy - A Comprehensive Guide](/blog/2024-11-06-devrel-strategy) for the full narrative version of this framework
* [DevRel activities](/docs/practices/devrel-activities) for the complete activity map
* [Understanding developer personas](/docs/fundamentals/understanding-developer-personas) for the audience work in depth
* [Goal planning with OKRs](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr) for the goal-setting mechanics
***
Sources & References:
* [How to craft a great Developer Relations strategy](https://danipassos.substack.com/p/how-to-craft-a-great-developer-relations) by Dani Passos | February 14, 2024
* [My DevRel Strategy Breakdown](https://tessakriesel.com/my-devrel-strategy-breakdown/) by Tessa Kriesel | June 30, 2022
* "Developer Relations: How to Build and Grow a Successful Developer Program" by Caroline Lewko and James Parton, 2021
---
# The Business Case for DevRel (https://devrel.directory/docs/fundamentals/importance)
## The question this page answers [#the-question-this-page-answers]
[What DevRel is](/docs/fundamentals/definition) has its own page.
This page answers the harder question practitioners actually face: how do you justify DevRel investment to leadership, and how do you defend it when budgets tighten?
The uncomfortable context first.
In the 2024 State of Developer Relations survey, 61% of respondents said they find it difficult to prove their influence.
The same report found 62% of DevRel teams reporting to founders or C-level executives, and 20% directly to the CEO.
Read those two numbers together: DevRel sits unusually close to power, and too often shows up there without a business case.
That is a dangerous combination, because a function that is visible to executives and vague about its value is first in line when costs get cut.
The business case for DevRel is not "developers like us".
It is: developers decide which platforms win, their adoption compounds through network effects, and neglecting them creates real costs that land in other departments' budgets.
## Developers decide, then someone signs [#developers-decide-then-someone-signs]
The structural argument was made by RedMonk's Stephen O'Grady in The New Kingmakers back in 2013: developers, not their employers, have become the real technology decision makers.
Democratized access to software and infrastructure - open source, free tiers, cloud - means the people who build now choose the tools, and procurement formalizes choices already made.
The mechanics have only strengthened since.
SlashData estimated the global developer population at 47.2 million at the start of 2025.
A developer in that population can adopt your platform on a Tuesday afternoon: free trial, self-serve docs, working prototype before dinner, no salesperson involved.
By the time a contract reaches procurement, the technical evaluation is over and switching costs already exist.
If your product is something developers touch, you are in a developer-first go-to-market whether you fund it or not.
DevRel is the function that runs that motion deliberately, through [the roles the team page describes](/docs/fundamentals/roles-and-responsibilities) and the [activities that make it visible](/docs/practices/devrel-activities).
## The network effect, worked through [#the-network-effect-worked-through]
A network effect exists when a product gains value as more people use it.
For developer platforms the mechanism is concrete, not metaphorical:
* Every developer who succeeds leaves public exhaust: a Stack Overflow answer, a blog post, an open-source wrapper, example code in a public repo, a forum thread with the fix.
* That exhaust is onboarding material for the next developer, produced at no cost to you, and it never expires the way a paid campaign does.
* More adoption means a larger hiring pool that already knows your product, which lowers the cost for the next company to standardize on it.
* More integrations and community libraries make your platform the path of least resistance for adjacent use cases.
* And in the AI era, that same public corpus trains the models that now recommend tools and write integration code, so the flywheel extends to [developers who are agents](/docs/ai-era/agents-as-your-new-developers).
Each turn lowers the acquisition cost of the next developer while raising the value of joining.
That is the flywheel: more people building in an ecosystem makes the ecosystem more attractive to build in.
DevRel exists to start that flywheel and remove its friction - which is why the work looks like docs, [community](/docs/practices/community-building), and [content](/docs/practices/content-creation) rather than ad campaigns.
### A worked example: Twilio, in its own SEC filing [#a-worked-example-twilio-in-its-own-sec-filing]
The cleanest evidence is a company that built its business this way and then had to describe the machine to investors under securities law.
Twilio's Form S-1 states the model in one line: "we acquire developers like consumers and enable them to spend like enterprises."
It names the motion explicitly: "Our go-to-market model is primarily focused on reaching and serving the needs of developers. We are a pioneer of developer evangelism and education and have cultivated a large global developer community."
Now look at the funnel shape the filing discloses, as of June 30, 2016:
* Over 1,000,000 registered developer accounts.
* Over 100,000 paying customer accounts.
* Over 30,000 Active Customer Accounts, defined as generating at least $5 of revenue in the last month of a quarter.
Read that ratio correctly: roughly 97% of registered developer accounts were not meaningful revenue, and that was the design, not a failure.
The filing is explicit that "big ideas often start small", so developers were given free trials, self-service documentation, and free support to tinker years before a business problem arrived.
The payoff shows up one line down, in the expansion metric.
Twilio reported a Dollar-Based Net Expansion Rate of 155% for 2015 and 167% for the first half of 2016.
At 155%, an existing customer cohort doubles its revenue in roughly 19 months with zero new logos closed.
That is what "developers land small and grow" looks like when it finally reaches a financial statement.
When leadership asks why you would fund a million free accounts to get thirty thousand paying ones, this is the answer: developer-first businesses buy compounding expansion revenue with patience at the top of the funnel.
One honesty note, because this page argues against invented evidence in decks: Twilio proves the motion can work, not that it works everywhere.
Your version of these numbers depends on product quality, market timing, and execution - which is exactly why the case must be paired with [a strategy that names goals and metrics](/docs/fundamentals/devrel-strategy).
## What neglect actually costs [#what-neglect-actually-costs]
The costs of not doing DevRel do not disappear.
They move into other budgets, where nobody labels them.
### Support load [#support-load]
Every recurring developer question without a good doc or community answer becomes a support ticket, answered one-to-one, at cost, forever.
A canonical docs page or a well-run community thread answers it once and then keeps answering it.
The arithmetic is unforgiving: a question that arrives ten times a week and takes 30 support-minutes each burns about 65 hours a quarter - the ongoing price of never writing the one canonical answer.
Multiply by the dozen recurring questions every platform has, and "we can't afford DevRel" quietly becomes a support headcount line.
### Silent churn [#silent-churn]
Developers rarely complain before leaving.
They hit friction during integration, abandon quietly, and choose the competitor whose quickstart worked on the first try.
This churn never appears in a CRM, because the "customer" never became one - the deal that dies in a failed integration is invisible to sales reporting.
Without someone watching time-to-first-successful-call and onboarding drop-off, you learn about integration friction from win-loss analysis, a year late and one competitor behind.
### Docs decay [#docs-decay]
Documentation rots at the speed of your release cadence, and unowned documentation rots fastest.
Every stale page raises support load, extends onboarding time, and teaches developers that your platform cannot be trusted at exactly the moment they are deciding whether to trust it.
The AI era raises the stakes: stale and wrong pages are now retrieved and repeated by coding assistants, so a docs bug becomes misinformation with a distribution channel, per [writing docs LLMs can use](/docs/ai-era/docs-for-llms).
### Compounding in reverse [#compounding-in-reverse]
Network effects do not pause while you deliberate.
The public answer base, the integrations, the community expertise, and the model training data accumulate for whoever invests.
If that is your competitor, every quarter of your hesitation is a quarter of their flywheel - and catching up costs far more than keeping up, because you are then competing against compounded output.
None of these costs ever appear as a line item called "no DevRel".
They surface as support headcount, lost evaluations, and a developer brand people quietly route around - which is why the case has to be made before the damage is measurable.
## Arguing the case internally [#arguing-the-case-internally]
Proving influence is the top struggle in the survey data above, so treat the internal argument as part of the job, not an interruption to it.
Opinionated guidance on what belongs in the deck and what you should refuse to put there.
### Put in the deck [#put-in-the-deck]
* Two or three goals with numbers and deadlines, tied to outcomes the business already tracks: adoption, retention, support cost, product quality.
The [strategy page](/docs/fundamentals/devrel-strategy) shows what passes that test.
* The funnel-shape education.
Show the Twilio ratio and set the expectation up front that most developer engagement will never map to a closed deal, by design.
* A cost-of-neglect estimate in your own numbers: current recurring ticket themes in support hours, onboarding drop-off, stale-docs incidents.
Avoided cost is the budget argument finance actually respects.
* Leading indicators paired with lagging ones: time-to-first-successful-call and peer-answered questions now, retained active projects and expansion revenue later.
Say out loud that the lagging ones move quarters after the work does, and wrap both in [accountable OKRs](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr).
* A reporting cadence you will actually keep.
The same handful of honest metrics every quarter builds the credibility that a scramble at budget time cannot.
### Refuse to promise [#refuse-to-promise]
* Per-activity revenue attribution.
Developers need multiple touchpoints before they engage, and promising clean attribution sets a trap that springs at renewal time.
* Marketing-comparable lead volume in the first two quarters.
DevRel compounds and paid spend does not - that difference is the reason to fund it, not a defect to apologize for.
* Community size or pageviews as success metrics.
Numbers that can only go up cannot prove anything, a failure mode the [strategy page](/docs/fundamentals/devrel-strategy) calls metrics theater.
* Revenue targets DevRel does not control.
Sign up for the leading indicators it does control, and show the causal chain to revenue instead of claiming the whole number.
A budget defense assembled the week of the budget meeting has already lost.
Report the same honest metrics every quarter so the defense is on record before anyone asks for it.
If your measurement problem is that adoption increasingly happens where analytics cannot see it - inside AI assistants and agent workflows - the [measuring AI-driven adoption page](/docs/ai-era/measuring-ai-driven-adoption) covers how to report that honestly too.
## Related [#related]
* [Definition of DevRel](/docs/fundamentals/definition) for what the function is before you argue what it is worth
* [Roles and responsibilities](/docs/fundamentals/roles-and-responsibilities) for the team shape the investment buys
* [DevRel strategy](/docs/fundamentals/devrel-strategy) for turning a funded mandate into goals, audience, activities, and metrics
* [Community building](/docs/practices/community-building) for the practice that powers the network effect
* [Measuring adoption you cannot see](/docs/ai-era/measuring-ai-driven-adoption) for defending the numbers when AI hides the funnel
***
Sources & References:
* [Twilio Inc. Form S-1](https://www.sec.gov/Archives/edgar/data/1447669/000119312516733893/d237988ds1.htm) | U.S. Securities and Exchange Commission, filed October 7, 2016
* [The New Kingmakers: How Developers Conquered the World](https://redmonk.com/sogrady/2013/01/09/the-new-kingmakers-the-book/) by Stephen O'Grady | RedMonk, January 9, 2013
* [Global developer population trends 2025](https://www.slashdata.co/post/global-developer-population-trends-2025-how-many-developers-are-there) | SlashData, 2025
* [11th Annual State of Developer Relations Report](https://www.devrel.agency/post/announcing-the-11th-annual-state-of-developer-relations-report) | DevRel Agency, September 10, 2024
---
# DevRel Roles and Responsibilities (https://devrel.directory/docs/fundamentals/roles-and-responsibilities)
## The role landscape [#the-role-landscape]
DevRel job titles are notoriously inconsistent: the same work ships under advocate, evangelist, community, developer experience, and half a dozen hybrids.
This page maps the roles as researched and as practiced, then answers the questions hiring managers actually have: who to hire first, where the team reports, and what seniority looks like.
If you want the definition of the function itself first, start with [what Developer Relations is](/docs/fundamentals/definition).
## The classic four roles [#the-classic-four-roles]
In an exploratory study of 116 practitioners, Oliveira et al. \[2021] identified nine distinct DevRel roles, from advocates and evangelists to developer programs engineers and technical writers.
This site condenses them into four families that cover most job postings:
| Title | Necessary Skills | Examples of Work |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Developer Advocate | Deep technical understanding, communication skills, feedback gathering, problem-solving, advocacy. | Enabling developers to leverage the platform/Application Programming Interfaces (APIs), advocating for developers' needs to internal product teams, creating demos and code examples, finding solutions to product issues and bugs. |
| Developer Evangelist | Technical understanding, public speaking, event hosting, writing skills, social media management, feedback to product team. | Speaking at conferences, running events, writing blog posts, recording videos, overseeing developer social media presence, helping announce new features to the public. |
| Developer Experience (DX) | UX design, API/Software Development Kit (SDK) design, documentation writing, onboarding process design. | Owning onboarding flows, SDK/API design, and documentation, acting like product owners for anything developers use. |
| Developer Marketing | Marketing strategy, content creation, event sponsorship, ad campaign management. | Creating marketing campaigns and strategies to reach developers and technical audiences, content syndication, managing paid channels like Ad Words, event sponsorship. |
The taxonomy is from 2021 and the field has specialized since, but the table still holds as the skeleton.
Every newer title is one of these four rows with a narrower mandate or a bigger scope.
## Advocate vs evangelist: direction of travel [#advocate-vs-evangelist-direction-of-travel]
The two titles are conflated constantly in industry parlance, but the practical distinction is which way the person faces.
An advocate faces inward: they represent the developer community to the company, carrying feedback, friction reports, and filed issues to product and engineering teams.
An evangelist faces outward: they represent the company to the developer community through talks, posts, videos, and launch support, and traditionally sits closer to marketing (Hughes \[2022]).
Most practitioners do some of both, so the title signals which half is the job and which half is the side effect.
One wrinkle: "evangelist" has fallen out of favor at many companies for its connotations, so outward-facing work now often ships under the advocate title too.
Read the responsibilities in the posting, not the title on it.
## The modern role list [#the-modern-role-list]
Four titles from the wider role landscape, all of which now appear as distinct mainstream hires rather than folded into the families above.
### Community manager [#community-manager]
Owns the spaces where developers help each other: the forum or Discord, the champions program, moderation, and community events.
The skills are program design, moderation judgment, event operations, and enough technical literacy to triage questions and route the hard ones.
This role is the difference between a community that compounds and a Discord that decays; the [community building page](/docs/practices/community-building) covers the practice.
### Technical writer / docs engineer [#technical-writer--docs-engineer]
Owns documentation as a product: information architecture, reference accuracy, docs-as-code tooling, and the quickstarts that decide evaluations.
The docs engineer variant leans further into tooling - API reference generation, versioning, docs CI - and is the right shape when docs are large and change fast.
The role now has a second audience: AI assistants read the docs too, and [structuring documentation for LLMs](/docs/ai-era/docs-for-llms) is becoming part of the brief.
Where advocates create [content](/docs/practices/content-creation) that persuades, this role creates content that developers depend on.
### DevRel engineer [#devrel-engineer]
The most hands-on variant: builds sample apps, reference integrations, SDK improvements, and demo infrastructure rather than talking about them.
It overlaps with the Developer Experience row in the table, but as an IC engineering role inside DevRel instead of a product-ownership function.
New build surfaces keep appearing for this role, such as [MCP servers as a DevRel surface](/docs/ai-era/mcp-servers-as-devrel-surface) for the agent era.
Hire this shape when your bottleneck is working code - integrations, samples, tooling - rather than reach.
### Head of DevRel / Director [#head-of-devrel--director]
Owns the [strategy](/docs/fundamentals/devrel-strategy), the budget, the headcount plan, and the reporting-line conversation with executives.
The job is translation in both directions: business goals into a DevRel program, and DevRel results into terms the executive team funds.
It is a real management job, not a senior advocate with extra meetings - see the leveling section below.
## What every role shares [#what-every-role-shares]
Whatever the title, three responsibilities are non-negotiable across the whole function.
First, carrying feedback: every role hears developer friction, and every role is obligated to route it somewhere it gets acted on.
Second, writing: talks fade and demos rot, but written material keeps working, so writing ability is a hiring bar for every role on this page.
Third, using the product for real: a practitioner who has not personally hit the onboarding wall cannot represent the developers who do.
If a job description drops any of these three, it is describing a different job wearing a DevRel title.
## Who to hire first [#who-to-hire-first]
The right first hire depends on company stage, and getting the order wrong is one of the most common DevRel failure modes.
Live postings on the [jobs board](/jobs) show how companies are actually scoping these roles.
### Pre-seed and seed: founders first, then one generalist [#pre-seed-and-seed-founders-first-then-one-generalist]
Before product-market fit with developers, the founders are the DevRel team - they answer the questions, write the first docs, and give the first talks.
The first dedicated hire should be a senior generalist developer advocate: someone who can write, code, speak passably, and run the feedback loop alone.
Senior matters because a team of one sets its own strategy; generalist matters because the biggest problem changes every month.
Do not hire a Head of DevRel as the function's first employee.
A director with nobody to direct will either do IC work at a director's cost or build process for a team that does not exist yet.
### Series A to B: hire against the drop-off [#series-a-to-b-hire-against-the-drop-off]
Once the generalist is saturated, hire against the biggest drop-off in the developer journey, which your [personas work](/docs/fundamentals/understanding-developer-personas) should reveal.
If developers stall during evaluation because the docs are thin, the second hire is a technical writer or docs engineer.
If a real stream of user questions is going unanswered, it is a community manager.
If the samples and integrations are the bottleneck, it is a DevRel engineer.
A second advocate is the right call only when the first one's activities demonstrably work and simply need more coverage.
Beware the unicorn posting: one role asking for conference speaking, docs ownership, community management, SDK engineering, and pipeline targets.
That is four jobs from the table above compressed into one salary, and it predicts burnout for the hire and disappointment for the company.
### Growth and beyond: add a head, then specialize [#growth-and-beyond-add-a-head-then-specialize]
Around three or more ICs, the function needs a Head of DevRel - both to manage and to defend the budget with a coherent [strategy](/docs/fundamentals/devrel-strategy).
From there, specialization follows the goals: dedicated docs, dedicated community, dedicated developer marketing as a partner function.
The [business case](/docs/fundamentals/importance) has to be restated at every stage, because headcount that was obvious at seed gets questioned at scale.
## Where the team reports [#where-the-team-reports]
There is no consensus placement for DevRel, and the reporting line changes the job more than the job description does.
* Under engineering: the team gets technical credibility and a short path to fixing what developers complain about, but risks being treated as support overflow and measured against shipping metrics that do not fit.
* Under marketing: the team gets budget and distribution machinery, but gets measured in leads, and developer trust erodes fast once the content smells like campaigns.
* Under product: the team's core loop - developer feedback into product change - lands directly where decisions are made, and DX work has a natural owner.
* Standalone, reporting to the CEO or CTO: maximum autonomy and a clear signal that developers matter, but it only survives while that executive personally sponsors it, and it is usually the first structure dissolved in a reorg.
Our position: default to product when developers are the customer, with engineering as a close second.
Report into marketing only when awareness genuinely is the top goal, and negotiate developer-shaped metrics before accepting the org chart, not after.
Wherever the team lands, the placement test is simple: are the team's metrics ones it can honestly move, and does its feedback reach people who can act on it?
If either answer is no, the reporting line is wrong regardless of which department it points to.
## Seniority and leveling [#seniority-and-leveling]
Titles vary, but the leveling logic is consistent across companies that do this well.
* IC (advocate, writer, community manager, DevRel engineer): owns specific [activities](/docs/practices/devrel-activities) and one measurable signal per activity, and executes within an existing strategy.
* Senior IC / lead: owns a whole program area - the content program, the community, the DX backlog - plus its roadmap, and mentors other ICs without necessarily managing them.
* Head / director: owns strategy, budget, hiring, and the executive relationship, and is judged on business outcomes rather than activity output.
Two rules of thumb.
First, do not create a manager layer before there are roughly three ICs to manage; before that, seniority should mean broader ownership, not reports.
Second, keep a senior IC track open - forcing your best advocate into management to get promoted is how you lose your best advocate.
A note on reading postings: "Developer Advocate" can mean anything from entry level to principal, so weight the scope described over the title granted.
Three questions reveal the real level: what the role owns, who it reports to, and which signal it is measured on.
## Related [#related]
* [What Developer Relations is](/docs/fundamentals/definition) for the function these roles serve
* [DevRel strategy](/docs/fundamentals/devrel-strategy) for deciding what the roles should work on
* [DevRel activities](/docs/practices/devrel-activities) for the work each role executes week to week
* [The jobs board](/jobs) for how these roles are scoped in live postings
***
Sources & References:
* [Raphael Oliveira, Camila Ajala, Davi Viana, Bruno Cafeo, and Awdren Fontão. Developer Relations (DevRel) Roles: an Exploratory Study on Practitioners' opinions.](https://dl.acm.org/doi/10.1145/3474624.3474628) September 2021. doi: 10.1145/3474624.3474628.
* [What Does a Developer Evangelist Do?](https://draft.dev/learn/understanding-the-role-of-a-developer-evangelist) by Karl Hughes | May 2022
* [Best practices for Developer Relations Programs to measure success of an API platform](https://www.moesif.com/blog/developer-relations/measure-success/Best-practices-for-Developer-Relations-Programs-to-measure-success-of-an-API-platform/) by Derric Gilling | January 2020
* "Developing Successful Developer Relations Programs in Blockchain Data Companies: A Metrics-Driven Approach" by Fabian Hug | 2024
---
# Understanding Developer Personas and Needs (https://devrel.directory/docs/fundamentals/understanding-developer-personas)
## What a persona is for [#what-a-persona-is-for]
A developer persona is compressed research: everything you have learned about one segment, condensed into a single named character the whole team can argue about.
Without one, every planning meeting quietly optimizes for a different imagined developer - the one each person happens to know best.
With one, "would Dana read a 40-minute conceptual guide before her deadline?" is a question with an answer.
Personas come after segmentation, not instead of it.
The [DevRel strategy page](/docs/fundamentals/devrel-strategy) covers how to segment your audience and validate that a segment is worth serving - do that work first, then turn your top two to four segments into personas.
This page covers the turning-into part.
Two rules before anything else.
No data = no persona.
Every field in a persona must trace back to something you observed - an interview, a ticket, a usage cut.
A persona built from assumptions is a stereotype with a template around it, and it will confidently steer you wrong.
And cap yourself at three or four personas.
Beyond that, nobody remembers them, nobody uses them, and the exercise becomes documentation theater.
If you feel the pull toward a fifth, your segmentation is probably too fine-grained for your current resources - merge before you multiply.
## The template [#the-template]
Ten fields, each with a reason to exist.
If a field does not change a decision you make, it does not belong - that principle is also why the [what to cut](#what-to-cut) section exists.
1. **Handle**: a memorable name plus role label, like "Deadline Dana, backend engineer at a Series A startup".
Rationale: the handle is what makes the persona usable in conversation; nobody says "segment 2b" in a planning meeting.
2. **Segment**: which validated segment from your strategy this persona compresses.
Rationale: keeps the persona anchored to the audience work instead of drifting into fiction.
3. **Triggering situation**: the concrete event that brings this developer to your product.
Rationale: developers do not wake up wanting your tool; they hit a problem, and your onboarding must meet that exact moment.
4. **Job to be done**: the outcome they need, stated in their words, not your feature list.
Rationale: this is the sentence your quickstart, homepage, and first tutorial must answer.
5. **Stack and constraints**: languages, frameworks, deployment targets, and the tools they already live in.
Rationale: decides which SDKs you prioritize and which language your examples lead with.
6. **Domain experience**: how familiar they are with your problem space specifically, not how senior they are in general.
Rationale: a staff engineer who has never touched payments needs the idempotency explainer just as much as a junior does.
7. **Authority**: whether they choose the tool, recommend it, or implement someone else's choice.
Rationale: determines whether your content must convince them or arm them to convince someone else.
8. **Success definition**: the moment they would call the integration done.
Rationale: this is the finish line your time-to-first-success metric should measure toward.
9. **Failure triggers**: the specific frustrations that make them abandon and pick a competitor.
Rationale: retention work starts with knowing exactly where trust breaks.
10. **Evidence and review date**: links to the interviews, tickets, and data cuts behind each claim, plus when the persona was last validated.
Rationale: the evidence field is what separates a persona from a guess, and the date is what stops it from fossilizing.
Notice what is not in the template: age, gender, city, hobbies, or a photo.
More on that below.
## A worked example [#a-worked-example]
The persona below is an illustrative example for a fictional payments API.
It is not a real research study, and the specifics are invented to show what a completed template looks like.
Your persona must be filled with your own evidence, not adapted from this one.
**Handle**: Deadline Dana, backend engineer at a seed-stage startup.
**Segment**: backend engineers at seed-to-Series-B startups integrating a payments API for the first time.
**Triggering situation**: the founder committed to launching paid plans this quarter, and Dana picked up the "add checkout" ticket in this sprint.
**Job to be done**: "Get card payments working in production before launch, without becoming the payments expert on call for it forever."
**Stack and constraints**: TypeScript on Node, Postgres, deploys to a PaaS; heavy AI-assistant use for unfamiliar domains; no dedicated infra or security team to lean on.
**Domain experience**: five years of solid backend work, zero payments exposure - idempotency keys, webhook verification, and PCI scope are all new vocabulary this week.
**Authority**: de facto chooser; the founder will approve whatever Dana recommends after a one-paragraph Slack summary.
**Success definition**: a test-mode charge succeeding the same afternoon she starts, and a production checkout flow live before the launch date.
**Failure triggers**: webhooks that behave differently in sandbox and production, error messages that do not match the docs, and any pricing surprise she has to explain to the founder after the fact.
**Evidence and review date**: in a real persona, this field links to the eight interview notes, the tagged export of 150 support tickets, and the activation-funnel cut behind the claims above, plus a review date about six months out.
The example shows the payoff: from this one page you can derive the quickstart's target time, the first tutorial's topic (webhook handling, sandbox to production), the docs' vocabulary level, and the one-paragraph summary Dana needs for her founder.
A persona that cannot generate decisions like these is not finished.
## The research that feeds the template [#the-research-that-feeds-the-template]
Three methods cover most of what a persona needs.
Each answers different questions, and each has blind spots you should be honest about.
### Practitioner interviews [#practitioner-interviews]
Talk to five to eight developers per segment - fewer misses patterns, and returns diminish quickly past ten.
Source them from recent signups, support-ticket follow-ups, and community members, and deliberately include people who evaluated you and walked away, because your fans are the least representative sample you have.
A 30-to-45-minute call with a small thank-you gift card is the standard format, and expect the full round plus synthesis to take two to three weeks of calendar time.
What interviews tell you: motivations, decision processes, vocabulary, objections, and the triggering situations that no analytics event captures.
What they cannot tell you: prevalence.
Five people saying the same thing is a pattern worth checking, not proof that most of your audience feels it.
### Support-queue and community-thread mining [#support-queue-and-community-thread-mining]
Read the last 100 to 200 support tickets and community threads and tag each with the question type and whatever role signals appear.
This is a focused day or two of work, and it yields the exact language developers use when stuck - which is also the language your docs and error messages should use, as the [content creation page](/docs/practices/content-creation) argues.
What mining tells you: recurring pain points at real volume, where documentation fails, and which concepts confuse which kinds of users.
What it cannot tell you: anything about developers who bounced silently.
The queue only contains people who cared enough to write in, so it systematically overweights your most persistent users.
### Signup and usage data cuts [#signup-and-usage-data-cuts]
Cut your activation funnel by the dimensions that might define segments: company size, SDK language, referral source, and where in onboarding people stall.
If analytics are already instrumented, this is an afternoon; if not, budget real engineering time before the persona work starts.
What data cuts tell you: which segments actually exist in volume, and precisely where each one drops off.
What they cannot tell you: why.
The funnel shows the cliff, and only interviews and tickets explain the fall.
### Triangulate before you write [#triangulate-before-you-write]
A claim earns its place in a persona when at least two methods agree on it.
Interviews said webhooks are scary, tickets are full of webhook debugging, and the funnel shows a stall at webhook setup - now "webhook friction" belongs in the failure triggers field.
One method alone gets written down with an explicit caveat or parked until you can check it.
The [community](/docs/practices/community-building) is a standing research asset here: the questions people ask every week are a continuous, free stream of persona evidence.
## What to cut [#what-to-cut]
Most persona templates in the wild are marketing hand-me-downs, and the classic critique is Claire Hunsaker's DevRelCon talk "Personas: you're doing it wrong".
Three things to delete on sight:
* **Demographics**: age, gender, and city do not change a single decision about your docs, SDKs, or onboarding.
Experience, stack, and authority do, so spend the space there.
* **Stock photos**: a photo adds fake specificity, invites bias about who a "real" developer looks like, and communicates nothing the handle does not.
* **Fictional biographies**: "Dana enjoys hiking and craft coffee" is decoration.
Hobbies have never changed a content plan, and every invented detail trains the team to treat the researched details as equally invented.
The test for any field: if it changed tomorrow, would you do anything differently?
If not, cut it.
## Negative personas [#negative-personas]
A negative persona documents who you deliberately do not serve, so the team stops paying attention to loud but wrong-fit feedback.
For the fictional payments API above, a negative persona might be the hobbyist building a side project with no revenue - lovely people, vocal in the community, and structurally unable to become customers of a per-transaction product.
One or two negative personas are enough, and they earn their keep the first time someone proposes an initiative aimed squarely at people who will never convert.
Negative does not mean ignored.
It means you consciously choose not to optimize the roadmap and the content calendar for them, which is a strategy decision the [goals framework](/docs/fundamentals/devrel-strategy) should back up.
## Keeping personas alive [#keeping-personas-alive]
Personas expire, because products, markets, and audiences move.
Revisit each one every six to twelve months, alongside the segmentation review the strategy page recommends, and check the evidence links: if the newest source behind a persona is two years old, it is describing your former audience.
Retire personas whose segments stopped mattering - a wall of outdated personas is worse than none, because the team still trusts them.
Personas only pay off when they leave the DevRel team.
Put them where product, docs, and marketing plan their work, and reference them by handle in reviews - "would Dana get past step three?" is the sentence that makes the whole exercise worth it.
One boundary worth naming: AI agents increasingly evaluate and consume developer products on developers' behalf, and that audience needs its own treatment - see [agents as your new developers](/docs/ai-era/agents-as-your-new-developers) - but the personas on this page are about the humans who still make the adoption decisions.
## Related [#related]
* [DevRel strategy](/docs/fundamentals/devrel-strategy) for the segmentation work that comes before personas
* [Content creation](/docs/practices/content-creation) for writing to a reader you can name
* [Community building](/docs/practices/community-building) for the ongoing evidence stream that keeps personas current
* [DevRel Strategy - A Comprehensive Guide](/blog/2024-11-06-devrel-strategy) for how personas fit the full strategy walkthrough
***
Sources & References:
* "Personas: you're doing it wrong" by Claire Hunsaker | [https://developerrelations.com/strategy-and-metrics/personas-youre-doing-it-wrong](https://developerrelations.com/strategy-and-metrics/personas-youre-doing-it-wrong) | DevRelCon San Francisco 2019
* "Putting names to faces - Developer Personas" by DevRel Agency (Developer Go To Market Series) | [https://www.devrel.agency/post/personas](https://www.devrel.agency/post/personas) | April 26, 2023
* "What are developer personas? Your complete guide" by Teresa Garanhel | [https://www.developermarketing.io/the-complete-guide-to-developer-personas](https://www.developermarketing.io/the-complete-guide-to-developer-personas) | October 22, 2024
---
# Community Building (https://devrel.directory/docs/practices/community-building)
## Why community compounds [#why-community-compounds]
A developer community is the only DevRel asset that answers questions while you sleep.
Every solved thread becomes searchable capital, every active member lowers the load on the next one, and the resulting network effects are the core of [why DevRel matters](/docs/fundamentals/importance) commercially.
That is the payoff.
The cost is that community is slow to start, easy to fake with vanity numbers, and impossible to outsource.
## Do you actually need one yet? [#do-you-actually-need-one-yet]
Be honest about this gate before creating anything.
A community space earns its existence when three things are true:
1. Developers are already using the product in production, or seriously trying to.
2. They ask questions with answers worth preserving.
3. Someone on your side will show up every day for the first months.
If those are not true yet, a community space becomes an empty room with your logo on it, and an empty room actively signals that nobody uses the product.
A support channel is not a community.
If every thread is answered by an employee and members never talk to each other, run it as support and do not label it community.
Until the gate is met, participate in external communities instead: it reaches developers where they already are, at a fraction of the cost.
## Choosing the home [#choosing-the-home]
Every option trades reach against ownership.
* GitHub Discussions: lives next to the code, indexed by search engines, zero extra accounts for developers.
Weak for real-time chat and casual presence.
* Discord: excellent for real-time energy and voice events, familiar to most developers.
Content is unsearchable from the outside and effectively disappears; treat it as ephemeral by design.
* Slack: comfortable for B2B audiences that live in Slack at work.
Message history limits and workspace sprawl make it a poor archive.
* A forum such as Discourse: the best long-term archive, fully owned, search-indexed.
Higher setup and moderation cost, and it feels slower socially.
A practical pattern: one real-time space for presence plus one indexable space for durable answers, with the discipline to move solved chat threads into the indexable one.
The worst pattern is four half-alive spaces.
## The cold start: your first fifty members [#the-cold-start-your-first-fifty-members]
Communities do not start with scale, they start with hospitality.
Do things that do not scale:
1. Invite people personally: your first users, beta testers, the developers who filed thoughtful issues.
A personal note beats any announcement.
2. Be present daily: founders and DevRel answering within the hour sets the tone for everything after.
3. Seed real content: post the questions you get by email, with answers, so the room never looks empty.
4. Create one ritual: a weekly office hour, a Friday showcase thread, a monthly call.
Rituals give people a reason to come back.
5. Welcome individually: greet every new member by name for as long as that is physically possible.
Expect the 90-9-1 shape: roughly ninety percent of members read silently, nine percent respond, one percent create.
Design for the readers too; they are adopting your product even when they never post.
## Growing past the founder era [#growing-past-the-founder-era]
Once strangers answer strangers, shift from hosting to building programs:
* Office hours and AMAs: scheduled access to your team, cheap to run, reliably productive.
* Showcase channels: members demoing what they built, which doubles as a content and case-study pipeline.
* Champions or ambassador programs: give your most invested members early access, a direct line to the team, and a stage.
Design incentives around recognition and access rather than payment; paying for advocacy converts your most credible voices into contractors.
* Community-sourced content: guest posts and talks by members, reviewed for accuracy by your team.
Set the guardrails early:
* A short, enforced code of conduct from day one.
Publishing it after the first incident is too late.
* Moderation coverage: name who acts, and how fast, when something crosses a line.
* An explicit escalation path from community questions into your issue tracker, so recurring pain becomes [product feedback](/docs/practices/devrel-activities) instead of folklore.
## Showing up in communities you do not own [#showing-up-in-communities-you-do-not-own]
Most of your audience will never join your space.
They are on Stack Overflow, Reddit, Hacker News, and in other products' Discords, and how you behave there shapes your reputation more than anything you do at home.
What works:
* Answer questions about your problem space, not just your product, and be genuinely useful.
* Disclose who you are every time; a bio line and a plain "I work on X" is enough.
* Follow each community's self-promotion rules to the letter.
* Bring value first: share the fix, then link the deeper guide if it genuinely helps.
What burns trust permanently:
* Drive-by promotion in threads you never participated in before.
* Undisclosed employees "recommending" the product.
* Copy-pasted marketing responses to nuanced technical questions.
In someone else's community you are a guest.
Guests who show up only to sell stop being invited.
## Measuring community health honestly [#measuring-community-health-honestly]
Member count is the weakest possible signal: it only ever goes up, and it says nothing about life inside.
Track behavior instead:
* Active participants per week or month: people who posted, replied, or reacted.
* Time to first response for new questions, and who responded.
* Member-answered ratio: the share of questions resolved by non-employees.
This is the single best indicator that a community, not a support desk, exists.
* Returning participants: members active this month who were also active last month.
* Qualitative signals: unprompted show-and-tell, members defending nuance in public threads, inside jokes.
Set targets for these the same way you set any goal, with explicit measurement definitions, as laid out in the [OKR planning guide](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr).
If a metric can be inflated by an announcement blast, it is a marketing metric, not a community health metric.
## Related [#related]
* [DevRel activities](/docs/practices/devrel-activities) for where community fits among the other clusters
* [Content creation](/docs/practices/content-creation) for turning community questions into durable content
* [Understanding developer personas](/docs/fundamentals/understanding-developer-personas) for knowing who you are hosting in the first place
***
Sources & References:
* [The 90-9-1 Rule for Participation Inequality in Social Media and Online Communities](https://www.nngroup.com/articles/participation-inequality/) by Jakob Nielsen | Nielsen Norman Group, 2006
* [The Art of Community](https://www.jonobacon.com/books/artofcommunity/) by Jono Bacon | O'Reilly, 2nd edition 2012
* [The Business of Belonging: How to Make Community Your Competitive Advantage](https://www.wiley.com/en-us/The+Business+of+Belonging%3A+How+to+Make+Community+Your+Competitive+Advantage-p-9781119766124) by David Spinks | Wiley, 2021
---
# Content Creation (https://devrel.directory/docs/practices/content-creation)
## Content is leverage [#content-is-leverage]
For most DevRel teams, content is the highest-leverage activity available.
A good guide works around the clock, scales without headcount, and compounds: through search for years, and now through AI assistants that answer developer questions with whatever material explains the problem best.
The bar, however, has moved.
Developers skim, verify, and bounce fast, and generic content is now free to produce and therefore worthless.
What earns attention is content that is specific, runnable, and honest about tradeoffs.
## Content types and the job of each [#content-types-and-the-job-of-each]
Different formats do different jobs.
Confusing them is how docs end up with tutorials that read like reference and blog posts that read like ads.
* Quickstart: from zero to one working call in minutes.
Job: prove the product works and respect the reader's time.
* Tutorial: a guided path to a meaningful outcome, with the reader following along.
Job: teach by doing.
* How-to guide: a focused recipe for one task the reader already understands.
Job: unblock.
* Conceptual explainer: how the system thinks, its model and its boundaries.
Job: build the mental model that prevents the next ten questions.
* Reference: exhaustive, accurate, boring on purpose.
Job: answer precise questions precisely.
* Blog essay: opinion, experience, architecture stories, honest postmortems.
Job: reach and trust, especially with people not yet using the product.
* Video and livestreams: demos, walkthroughs, launch streams.
Job: show real usage, including the stumbles; the recording becomes an asset.
* Example repositories: complete, running applications developers can clone.
Job: be the starting point people actually build from.
The [Diátaxis framework](https://diataxis.fr) formalizes much of this split and is worth reading once.
Use it as a lens, not a bureaucracy.
## Writing for developers [#writing-for-developers]
The craft rules that separate content developers use from content they close:
1. Lead with working code.
Developers read prose to understand the code, not the reverse.
2. Make every snippet copy-paste complete: imports, versions, and setup included, no invisible prerequisites.
3. Show exact error messages.
Errors are what people search for; matching their text verbatim is free search traffic and instant recognition.
4. State versions and dates.
Nothing destroys trust like a tutorial that silently broke two releases ago.
5. Write for scanning: descriptive headings, short paragraphs, code blocks with language tags, one idea per section.
6. Keep marketing out of the critical path.
A quickstart that pauses to celebrate the product loses the reader at the pause.
7. Edit ruthlessly.
First drafts explain what you did; good drafts explain what the reader needs.
Test every tutorial by following it yourself in a clean environment, top to bottom, before publishing.
Every step where you improvise is a step where readers get stuck.
These same properties (self-contained sections, exact errors, runnable snippets) are also what make content usable by AI assistants, which increasingly sit between your docs and your developers.
[Writing Docs LLMs Can Use](/docs/ai-era/docs-for-llms) covers that shift in more depth.
## Distribution: where content meets developers [#distribution-where-content-meets-developers]
Publishing is not distribution.
A realistic distribution model for a developer audience:
* Search is the durable channel.
Target the problem queries developers actually type, including error messages, not brand terms.
* Your own channels are the asset you keep: docs, blog, newsletter, RSS.
Every platform channel is rented ground.
* Social platforms reward channel-native formats.
A link dump performs poorly everywhere; a short standalone insight with the link in follow-up performs fine on most platforms.
* Developer norms punish growth hacks.
No engagement bait, no fake questions, no reply-guy automation; disclose who you are, as in [community spaces](/docs/practices/community-building).
* Consistency beats virality.
One useful post a week for a year outperforms one lucky hit, and it is plannable.
The repurposing tree makes one effort feed many channels: a conference talk becomes a blog post, the post becomes a code sample, the sample becomes three short posts and a newsletter section.
Plan the tree when you plan the talk, not after.
## A pipeline a small team can sustain [#a-pipeline-a-small-team-can-sustain]
Content programs die of ambition more often than laziness.
A sustainable loop for a team of one or two:
1. Intake: keep one list fed by community questions, support tickets, sales objections, and release plans.
Recurring questions are commissioning briefs someone already wrote for you.
2. Selection: pick by audience impact and search demand, not internal excitement.
3. Cadence honesty: commit to the rhythm you can hold on a bad week.
Biweekly and reliable beats weekly and abandoned by March.
4. Technical review: every piece gets an accuracy pass from someone close to the code.
5. Publication checklist: metadata, code tested, links checked, one internal link to related material.
6. Refresh loop: revisit the top pages quarterly; updating a high-traffic guide usually beats writing a new one.
## Measuring content [#measuring-content]
Content measurement is directional, not precise, and pretending otherwise erodes trust in every number you report.
Leading indicators:
* Search rankings and impressions for the problem queries you target.
* Traffic to problem-solving pages, weighted by whether the page is on the adoption path.
* Quickstart and tutorial completion, if instrumented.
Lagging indicators:
* Content-assisted signups and activation: accounts whose session history touched key content before converting.
* Recurring support questions disappearing after the answering guide ships.
Attribution will be incomplete: developers read on one device and sign up on another, and AI assistants increasingly consume content on their behalf.
Report ranges and trends, note the blind spots, and set targets with explicit measurement definitions as in the [OKR planning guide](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr).
Pageviews alone reward clickbait.
Pair every traffic number with a behavior that indicates the reader got somewhere.
## Related [#related]
* [DevRel activities](/docs/practices/devrel-activities) for how content fits the wider program
* [Community building](/docs/practices/community-building) for the question-to-content feedback loop
* [Understanding developer personas](/docs/fundamentals/understanding-developer-personas) for writing to a reader you can name
***
Sources & References:
* [Diátaxis: A systematic approach to technical documentation authoring](https://diataxis.fr) by Daniele Procida
* [Docs for Developers: An Engineer's Field Guide to Technical Writing](https://docsfordevelopers.com) by Jared Bhatti, Zachary Sarah Corleissen, Jen Lambourne, David Nunez, and Heidi Waterhouse | Apress, 2021
* [Google developer documentation style guide](https://developers.google.com/style) | Google
---
# DevRel Activities (https://devrel.directory/docs/practices/devrel-activities)
## The activity map [#the-activity-map]
DevRel work becomes visible through activities: the talks, posts, community threads, and feedback loops a team runs week after week.
Activities are not a strategy.
A [strategy](/docs/fundamentals/devrel-strategy) decides which developers you serve and what outcome the business needs; activities are how you get there.
The most common failure mode in DevRel is activity soup: doing a little of everything because everything is defensible.
A team stuck in activity soup is always busy, rarely measurable, and first in line when budgets tighten.
Pick a small set of activities that map to your current goal, run them long enough to judge honestly, and say no to the rest out loud.
This page maps the core activity clusters, what each one is good for, and how to choose between them.
## The six clusters [#the-six-clusters]
### 1. Content [#1-content]
Writing and producing material developers use to evaluate and adopt your product: quickstarts, tutorials, guides, reference material, blog posts, videos.
Content is the highest-leverage activity for most teams because it scales without headcount and compounds over time through search and, increasingly, AI assistants.
It earns its place from day one.
Signals it is working: rising traffic on problem-focused queries, quickstart completion, content-assisted signups.
Failure mode: publishing what the company wants to say instead of what developers are trying to do.
The full practice has [its own page](/docs/practices/content-creation).
### 2. Community [#2-community]
Creating and tending the places where developers using your product help each other: your own space, and your presence in spaces you do not own.
Community compounds like a network: every answered question becomes searchable capital, and every active member lowers the load on the next one.
It earns its place once there is a steady stream of real users asking questions, and not before.
Signals it is working: falling time-to-first-answer, member-answered questions, returning participants.
Failure mode: opening a Discord because everyone has one, then presiding over an empty room.
The full practice has [its own page](/docs/practices/community-building).
### 3. Speaking and events [#3-speaking-and-events]
Conference talks, meetups, workshops, webinars, and hackathons: high-touch moments where a person represents the product to a room.
Events create trust and reach density that content alone cannot, and they generate raw material for weeks of derivative content.
They earn their place when you know which audience attends and what you want them to do afterwards.
Signals it is working: qualified conversations, workshop completions, follow-up adoption you can trace to the room.
Failure mode: conference-driven development, where the calendar sets the roadmap and the team measures itself in booth hours.
Events are the most expensive activity per developer reached.
Treat every acceptance as a spend decision, not a reward.
### 4. Developer feedback and product influence [#4-developer-feedback-and-product-influence]
The inward-facing half of DevRel: collecting what developers struggle with and turning it into product and documentation changes.
This is the activity that separates DevRel from marketing.
It earns its place immediately, because it makes every other activity smarter, and it is how the team proves value to engineering and product peers.
Signals it is working: filed issues that get fixed, roadmap items traceable to community input, shrinking lists of repeated questions.
Failure mode: collecting feedback into a document nobody reads, which quietly teaches developers that talking to you changes nothing.
### 5. Developer experience work [#5-developer-experience-work]
Improving the product's first-run path: onboarding flows, error messages, sample apps, SDK ergonomics, and the documentation surrounding them.
Some organizations make this its own role, as covered in [roles and responsibilities](/docs/fundamentals/roles-and-responsibilities).
It earns its place when the data shows developers stalling between signup and first success.
Signals it is working: time-to-first-successful-call going down, fewer support tickets on setup steps.
Failure mode: shipping polish for the demo path while the real integration path stays rough.
### 6. Ecosystem and partnerships [#6-ecosystem-and-partnerships]
Integrations, co-marketing with adjacent tools, guest content, and champion programs that give your most invested users a bigger stage.
Ecosystem work multiplies reach through other people's audiences.
It earns its place after the basics work: partners amplify a good developer experience, they cannot fix a bad one.
Signals it is working: adoption arriving through integration paths, champions producing content you did not ask for.
Failure mode: logo-collecting partnerships that produce a press release and nothing else.
## Choosing activities by journey stage [#choosing-activities-by-journey-stage]
Different activities move different stages of the developer journey.
Start from where developers actually drop off, which your [personas work](/docs/fundamentals/understanding-developer-personas) should tell you.
* Awareness: talks, essays, podcasts, and being genuinely useful in external communities.
* Evaluation: comparison-friendly docs, honest quickstarts, sample apps that resemble real use.
* Activation: onboarding fixes, error message work, time-to-first-success instrumentation.
* Retention: release communication, changelogs, office hours, community support.
* Advocacy: champion programs, showcases, conference CFP support for community members.
If you cannot name the stage an activity serves, it is probably serving the calendar.
## A sample week for a team of one [#a-sample-week-for-a-team-of-one]
A realistic split for a solo DevRel practitioner with a shipped product and an early community:
1. Two mornings on content: one substantial piece in progress at all times.
2. One hour a day in the community and support queue, answering and logging patterns.
3. One afternoon on feedback synthesis: turn the week's questions into two or three concrete product or docs issues.
4. One afternoon on developer experience: fix the single worst snag developers hit that week.
5. A monthly, not weekly, slot for events and partnerships.
The exact split matters less than the discipline: recurring blocks, one owner, one measurable signal per activity.
## Prioritization heuristics [#prioritization-heuristics]
* Few over many: two activities done every week beat six done occasionally.
* Repeatable over spectacular: a talk is a moment, the recording plus the write-up is an asset.
* Measurable over comfortable: prefer the activity whose effect you can observe, even roughly, using goals set the way the [OKR planning guide](/blog/2024-10-29-devrel-team-goal-planning-strategy-okr) describes.
* Downstream of strategy: when someone requests an activity, ask which goal it serves before asking when.
* Keep a stop-doing list: every quarter, name one activity you are ending and say why.
## Related [#related]
* [Crafting a DevRel strategy](/docs/fundamentals/devrel-strategy) for deciding which goals the activities serve
* [Content creation](/docs/practices/content-creation) and [community building](/docs/practices/community-building) for the two deepest clusters
* [The importance of DevRel](/docs/fundamentals/importance) for the business case behind the work
***
Sources & References:
* [The Business Value of Developer Relations](https://www.devrelbook.com) by Mary Thengvall | Apress, 2018
* [The AAARRRP Developer Relations Strategy Framework](https://www.leggetter.co.uk/aaarrrp/) by Phil Leggetter | 2017
* [Developer Relations: How to Build and Grow a Successful Developer Program](https://link.springer.com/book/10.1007/978-1-4842-7164-3) by Caroline Lewko and James Parton | Apress, 2021