Advocacy and Developer Marketing
Rainkit sells one thing: an API that tells an app how likely rain is, hour by hour, for any spot in India. Its engineers are proud of it, but sign-ups are slow and the support inbox keeps filling with the same three confusions. So the company hires Meera as its first developer advocate. On her first day her manager asks, "So are you in marketing or in engineering?" Her honest answer is: a bit of both, and neither.
The rule
Advocacy runs both ways: product to developers, developers to product.
A developer advocate stands on a bridge between a company and the developers who use its product.
- Outward, Meera helps developers succeed with Rainkit. She explains it, writes examples, answers questions and shows what it is good for, and also what it is not good for.
- Inward, she speaks up for those developers inside Rainkit. She tells the product team where people get stuck, which features they keep asking for, and which error message made three people give up last week.
With only the first direction, the job becomes a megaphone. With only the second, it becomes a complaints desk. Advocacy is both at once.
Developer marketing is related but different. Its job is reach and adoption: making sure the right developers hear about Rainkit and try it. Aimed at developers, marketing has to change its tone, because developers tend to skip slogans and look for proof: a code snippet, a free tier, a benchmark they can rerun, honest limits. "The most powerful weather platform ever" persuades nobody. "A six-hour rain forecast in three lines of Python, free for 1,000 calls a day" gets tried.
The two roles work well together. Marketing decides where Rainkit should be seen; advocacy makes sure that what developers find there is true, useful and technically sound.
The shortcut
For any task, ask two questions: "Which way does the information flow?" and "Who benefits first?" Outward, with the developer benefiting first: advocacy. Inward, carrying developers' needs to the team: also advocacy. Outward, with sign-up numbers as the main goal: marketing, which advocacy can support but should never fake.
Write a tutorial on rain alerts for delivery apps
Outward, and a developer who follows it can ship a real feature. Advocacy.
The trap is treating advocacy as marketing with a friendlier face. The moment Meera hides a known bug or oversells a feature, developers stop trusting her, and a developer advocate without trust has nothing left to offer.
Drills
Answer fast — trust the rule.
Which of these is advocacy flowing inward, into the company?
Which line would work best in developer marketing for Rainkit?
A developer asks Meera whether Rainkit can forecast snowfall in Kashmir. It cannot. What should she say?
What happens to a DevRel role that only ever broadcasts outward?
Remember
- Advocacy runs both ways: product to developers, developers to product.
- Shortcut: ask which way the information flows and who benefits first.
- Trap: overselling or hiding limits. Developer marketing only works when it offers proof.