DevRel Roles and Responsibilities

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.

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:

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

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

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

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 covers the practice.

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 is becoming part of the brief. Where advocates create content that persuades, this role creates content that developers depend on.

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 for the agent era. Hire this shape when your bottleneck is working code - integrations, samples, tooling - rather than reach.

Head of DevRel / Director

Owns the 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

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

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 show how companies are actually scoping these roles.

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.

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 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.

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. From there, specialization follows the goals: dedicated docs, dedicated community, dedicated developer marketing as a partner function. The business case has to be restated at every stage, because headcount that was obvious at seed gets questioned at scale.

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

Titles vary, but the leveling logic is consistent across companies that do this well.

• IC (advocate, writer, community manager, DevRel engineer): owns specific 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

• What Developer Relations is for the function these roles serve
• DevRel strategy for deciding what the roles should work on
• DevRel activities for the work each role executes week to week
• The jobs board 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. September 2021. doi: 10.1145/3474624.3474628.
• What Does a Developer Evangelist Do? by Karl Hughes | May 2022
• 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