DevRel, explained by someone who never had the title

Definition

What devrel is

DevRel, short for developer relations, is the work of building a lasting relationship between a company and the developers who use its product. It runs in two directions. Outward, it helps developers succeed with the product through docs, sample code, talks and community. Inward, it carries what those developers say back to the people building the product.

That second direction is the part people forget, and it's what separates devrel from a content team. A devrel person who files the bug three users hit this week, with reproduction steps, is doing the job. One who writes a blog post about it and files nothing is doing half of it.

The job

What a devrel person does all week

Titles vary. Developer advocate, developer evangelist, community manager, devrel engineer. The work tends to land in the same buckets:

• Writing tutorials, sample apps and docs that answer real questions.
• Giving talks, running workshops, showing up at meetups.
• Answering people in the forum, the Discord, the GitHub issues.
• Trying the product as a newcomer and reporting where it hurts.
• Telling developers what shipped, in words they'd use themselves.

Which buckets get the most hours depends on the company. An API company with a big docs surface leans toward education. A company with an open source core leans toward community and contributors.

The confusion

DevRel vs developer marketing

They share an audience and a lot of tactics, and they answer to different questions. Developer marketing asks how many developers heard about the product and tried it. DevRel asks whether the ones who tried it succeeded, stayed, and would vouch for it. Marketing scales through reach. DevRel scales through trust, which is slower and harder to fake.

The tension is real. A devrel person whose talks turn into sales pitches loses the room, and their credibility is the whole asset. The developer marketing guide covers the reach side.

Org charts

Where devrel sits

Companies put devrel under marketing, under product, under engineering, or on its own. Each choice pulls the work toward its parent. Under marketing it drifts toward reach and events. Under product it drifts toward feedback and docs. Under engineering it drifts toward sample code and SDKs. None of these is wrong. It's worth knowing which pull you're under before you wonder why your goals look the way they do.

The hard question

Measuring devrel

This is the question every devrel team gets asked and nobody answers cleanly. Trust doesn't show up in a dashboard. What teams count instead is usually activity, like talks given and posts published, or outcomes close to the product, like developers who finished the quickstart or questions answered in the community. Activity is easy to count and easy to inflate. Outcomes are harder to attribute and closer to the point.

Mary Thengvall's book The Business Value of Developer Relations is built around exactly this problem, including how to make the case for community work inside a company that wants a number.

Small teams

DevRel for a team of one

If you build a developer tool alone, you are the devrel team, and the marketing team, and the support desk. The job shrinks to the parts that compound. Answer every issue like the person filing it is your only user, because some weeks they are. Keep the docs true. And tell people what shipped, every time, so the ones watching can see the project is alive.

That last one is where I kept failing. I'd merge a fix someone asked for and never tell them it landed. So I built Merge & Tell. It drafts the changelog entry and the posts from each merged pull request, and the ones I've set to go out on their own do. The result is the updates page on this site. It doesn't answer the issues for me. I'm still on the hook for those.

Sources

Further reading on developer relations

• DevRel 101, Alyss Noland on Heavybit. A getting-started guide for early teams, including how to measure the work.
• developerrelations.com. Talks, guides and podcasts by people who do the job.
• The Business Value of Developer Relations, Mary Thengvall, Apress, 2018. The book on making the case for it.

Honesty

What this page can't tell you

Pay, the job market, and whether devrel is a good career move right now. I don't have data on any of that, and the pages that claim to are mostly job boards. If you're deciding whether to take a devrel role, ask someone currently doing one at a company you'd consider. That conversation will be worth more than this page.