Developer advocate

What it answers for

• Technical accuracy in public, under a company name.
• The community's difficulties reaching the people who can resolve them.
• Material that continues to work after the release it was written against.

What it is measured on

• Adoption signals: sign-ups, integrations built, documentation and sample usage.
• Community activity and sentiment.
• Product changes traceable to feedback the role carried, which is the honest measure and the hardest to attribute.

Who else has a stake

• The wider community, including the people who never post and read everything.
• Marketing, whose messages the advocate's credibility either supports or contradicts.
• Engineering, whose backlog receives what the advocate carries.

What it takes

• Engineering ability, since credibility comes from building the thing rather than describing it.
• Writing and speaking for an audience that will check the claims.
• The willingness to say a product does something partially, in public, on the company's account.
• Comfort with a contribution that is visible everywhere and attributable almost nowhere.

The published sources

• A survey of developer relations roles, placing the advocate at the intersection of customer success and product: writing sample code and reference integrations, running office hours, answering in community channels, filing detailed bug reports, and turning recurring developer pain into product proposals
• An account of developer relations as the umbrella term for the team building a community online and offline, covering advocacy, developer experience, events, community management and content
• A practitioner guide to developer relations, including internal advocacy — representing the developer's voice inside the company — as a core function alongside content, speaking and community engagement

  Developer relations has no professional body and no framework definition; its literature is written by practitioners. The titles vary across companies — developer advocate, developer evangelist, developer programs manager, developer experience engineer — for work that overlaps heavily, which is the same pattern the federal work-role material records for network operations.

Where it leads

• Technical instructorWho teaches it
• Product managerWho makes it
• Instructional designerWho teaches it
• Community managerWho teaches it

The work itself

The Practice covers how this work is done — triage, escalation, evidence, handover — across the whole corpus.

• Feeding the fix back into the designA fix applied to the instance leaves untouched the thing that produced the instance. Until it reaches the generator — the template, the standard build, the default, the procedure — the next one is manufactured by the same process, and the fix has bought exactly one device's worth of safety.
• Intake: what a good problem report containsMost of the time lost to an incident is lost before anyone starts working on it, in the gap between what the reporter said and what is actually wrong.
• Knowledge capture that somebody will actually findKnowledge capture fails at retrieval, not at capture. Organisations hold enormous amounts of written incident knowledge, indexed by cause and by who wrote it — while the person who needs it arrives holding only a symptom, which is the one thing nobody titled anything with.

Read The Practice