Developer Advocate
Developer advocacy is the job engineers imagine is all conference talks and is actually mostly writing, sample code, and internal argument. This page covers what the work involves, what it pays, why the role is volatile, and how people actually get hired.
Typical Pay (US)*
$130kmedian** AI-estimated from general U.S. labor-market patterns — not measured data from the U.S. Bureau of Labor Statistics or any official source. Real pay varies widely by location, employer, experience, and timing.
Outlook
The writing half of this job has real exposure: routine tutorials, reference docs, and getting-started guides are exactly what language models produce competently, and Mochivia's dataset estimates automation exposure for the nearest technical-writing occupation at 0.50. What does not automate is credibility with a skeptical audience, live presence in a room or on a stream, community trust built over years, and being the person inside the company who files the API design complaint with evidence. Expect the role to shift further toward advocacy and away from documentation production.
What does a Developer Advocate do?
A developer advocate is an engineer whose output is other developers' success with a product. The concrete deliverables are documentation and tutorials, sample applications, SDK and API feedback, conference talks and workshops, videos, and presence wherever the product's developers already congregate. The job title sits inside what companies usually call DevRel, and it exists because technical products are bought and adopted by people who distrust marketing and respond to demonstrated competence.
The part that surprises newcomers is the direction the advocacy runs. Externally you help developers succeed with the product. Internally you are the person who tells the product team that the onboarding flow requires seven steps before a first successful API call, that the error messages are useless, and that the SDK's naming is confusing. Good developer advocates spend a meaningful share of their week filing issues and writing internal memos with evidence from real developers attached. Advocates who only do the outward half become marketers with a GitHub account, and the role stops being valuable to either side.
It is easy to confuse with four adjacent jobs. A technical writer owns documentation as a craft and goes deeper on it than an advocate does. A product marketer owns positioning and lead generation and is measured on pipeline. Support engineering is reactive and ticket-driven. A solutions engineer is attached to specific deals and revenue. Developer advocacy overlaps all four and is measured on none of their metrics cleanly, which is the honest structural weakness of the role: attribution is genuinely hard, so DevRel teams are frequently among the first cut when budgets tighten. Anyone considering this career should factor that volatility in rather than discover it.
The role suits engineers who like explaining things, can write clearly, and get energy from other people's progress rather than only their own shipped code. You do not need a large following to start, and the belief that you do keeps qualified people out. What you need is a body of public work: a handful of genuinely useful tutorials, one or two sample projects that solve a real problem, and evidence you can hold a room. It suits people badly if they need deep focus, dislike being visible, or want a role where the metrics are unambiguous.
A day in the life
- Write a tutorial that takes a developer from nothing to a working integration, then delete two of your own steps because the API changed and they are no longer needed
- Build a sample application against a pre-release SDK and file six issues about things that only surface when you actually use it
- Answer questions in the community forum and a Discord channel, and notice the same confusion appearing for the fourth time this month
- Write an internal memo arguing that the sign-up-to-first-API-call path is the real adoption problem, with quotes from developers attached
- Record and edit a short walkthrough video, which takes four hours for eight minutes of output
- Rehearse a conference talk and cut a third of the slides because the live demo needs more room to fail gracefully
- Review a colleague's docs pull request and push back on wording that assumes knowledge the reader does not have yet
How to become a Developer Advocate
- 1
Get real engineering experience first
~2-3 yearsTwo or three years building software is close to a hard requirement, because the audience detects a non-practitioner immediately. Advocacy without the ability to debug your own demo on stage does not survive contact with developers.
- 2
Start writing publicly on a real cadence
~6 months, ongoingAim for a dozen genuinely useful technical posts about problems you actually hit. Not thought leadership. The specific bug, the specific fix, the thing that was not in the docs. This is your portfolio and your writing practice at once.
- 3
Build and publish two sample projects
~2 monthsWorking applications built on a platform you care about, with a README that gets a stranger running in under ten minutes. These double as evidence of engineering ability and of your instinct for what confuses newcomers.
- 4
Learn to speak in front of people, starting small
~3-6 monthsA local meetup, an internal brown bag, a recorded screencast. Live technical presentation is a separate skill from writing, and the only way through it is repetition in low-stakes rooms.
- 5
Contribute to a community before you apply to it
~3 months, ongoingAnswer questions, review docs, file good issues for a product you already use. Most developer advocates are hired out of the community they were already helping, which is a far shorter path than cold applications.
- 6
Apply with evidence, and interview about the internal half
~2-3 monthsExpect a writing exercise and a live demo or talk. The question that separates candidates is what you would tell the product team after a month of watching developers struggle, so prepare a real answer.
Skills that matter
Learn the actual skills
Mochivia's structured roadmap walks you from fundamentals to job-ready — 15 minutes a day.
See the Roadmap