Quick answer
Developer advocacy is the practice of helping developers succeed with a product in public: writing tutorials, giving talks, answering questions and demoing real use, while carrying their feedback back to the product team. A developer advocate is who does it.
Developer advocacy
DefinitionAdvocacy replaced evangelism as the preferred word because the job changed. An evangelist promoted a product to developers; an advocate works for developers, inside the company, and the promotion follows from being useful. In practice the day is tutorials, livestreams, conference talks, community answers, sample apps, and a steady flow of "developers keep hitting this" to the product team.
Also called: Developer advocate, Developer evangelism.
What does a developer advocate do all week?
Writes a tutorial that solves a real problem with the product. Records a stream or a short video of the same. Answers questions in the community, on social and in GitHub issues. Prepares a talk for a meetup or conference. Keeps the sample apps running against the latest release. And files, with evidence, the three things developers hit this week that the product should fix.
The mix depends on the product and the person; the constant is that an advocate is an engineer whose job is other engineers' success. The moment the role becomes "say nice things about the product in public", developers notice and the credibility is gone.
How is advocacy different from evangelism?
Evangelism, the older term, was one-way: promote the product to developers. Advocacy is two-way: help developers succeed with the product, and advocate for them inside the company. The name changed because the job changed, and because developers stopped trusting people whose only job was promotion.
In practice the test is simple. An evangelist's talk ends with a pitch; an advocate's talk ends with a working example and a GitHub link. An evangelist reports reach; an advocate reports what got fixed.
Common mistakes
- Measuring advocates by talks given rather than developers activated.
- Hiring for stage presence over engineering depth.
- Sending feedback to product with no path for it to ship, so advocates stop collecting it.
- Leaving good tutorials on the company blog where only followers see them.
How developers experience it
- They follow individuals, not companies; the advocate is the brand.
- They test the sample app before they believe the talk.
- They notice when an advocate admits what the product cannot do, and trust the rest more.
What makes a developer advocacy program work?
- A named audience. Which developers, on which stacks, with which problems. "Developers" is not an audience.
- A publishing rhythm. A tutorial a fortnight beats a burst of ten before a launch and silence after.
- A feedback loop that visibly ships. Developers keep talking to advocates whose feedback changes the product.
- Distribution for what gets made. An advocate reaches the room, the thread, the stream; the rest of the stack needs the content put in their feed.
- A measure beyond applause: activations from content, questions answered, changes shipped.
On daily.dev
How it works on daily.dev
An advocate's tutorial reaches the people who attended the talk. On daily.dev the same post runs as In-Feed Ads to the developers following that tag, and the verified company page keeps them following after the conference is over.
Explore my optionsDeveloper advocacy vs developer evangelism
| Capability | Developer advocacy | Developer evangelism |
|---|---|---|
| Direction | Two-way: help developers, carry feedback inside | One-way: promote the product to developers |
| A talk ends with | A working example and a repo link | A pitch and a sign-up link |
| Reports on | Developers activated, questions answered, changes shipped | Reach: talks given, impressions |
| Credibility comes from | Engineering depth and honesty about limits | Stage presence |
| Still used? | The current term | Older term, mostly retired |