Advocacy

Developer advocacy is one of the most misunderstood roles in the API industry, and also one of the most important. At its best it is a two-way bridge: someone who carries the message of a platform outward to the developer community, but who also carries the real needs, frustrations, and priorities of developers back inside the organization. At its worst it is a marketing function wearing a technical costume — someone whose job is to generate enthusiasm for a platform without any actual authority to change it. The difference between those two things is what the entire profession has been quietly arguing about since 2010.

I started calling myself an API Evangelist in 2010, and spent years thinking carefully about what that meant. My framing, which I wrote down in 2011, was that the role required three overlapping skill sets: technical ability (you had to be able to code, to understand what developers were actually experiencing), business development (you had to understand the commercial context and be able to speak credibly to it), and sales and marketing (you had to be able to tell a compelling story and get it in front of the right audiences). The best advocates I knew were former engineers who had moved into lead or architect roles, developed an understanding of business operations, and could explain technical concepts to non-technical audiences without losing the developers in the room. That combination was rare, and the shortage of people who could do it well was real — I was getting two or three job offers a week from companies trying to fill the role.

But I also held a simpler definition of the work. I described API Evangelist as an API luminary — someone who shines a light on what others are doing. Storytelling was the core of it. Not the stories the marketing department wanted told, but honest stories about how the space was evolving, what was working, what was failing, who was building interesting things. That kind of storytelling required independence and it required trust, and those two things are in constant tension with a corporate employer who has messaging objectives.

The early Twilio model was the gold standard for what advocacy looked like done well. Twilio had boots on the ground at developer events — hackathons, conferences, startup weekends. Their evangelists showed up not to speak at people but to sit down next to them and write code. John Britton was a visible example of this: live-coding demos, genuine technical depth, presence at the events where developers were actually gathering. I wrote in 2011 about the contrast with government open data programs, which had done the work of building APIs but had no advocacy element to go with them. They needed someone to take those resources from town to town, to be present at the places where developers gathered. Twilio knew how to do that. The government did not.

The structure of advocacy was something I thought about from the beginning as having three parts in roughly equal proportion: internal, partner, and public. Internal meant educating your own company — making sure the product team, the legal team, the executive team understood what developers needed and why. This was often the hardest part and the most neglected. At Mimeo, where I was doing API work early on, we ran Demo Fridays where we showcased potential integrations and use cases for people across the organization. That kind of internal evangelism created awareness, generated feedback, and built the internal constituency that any serious API program needed. Without it, the API team operated in a vacuum and external advocacy was building on an unstable foundation.

The partner tier was about helping the businesses and developers who were integrating your platform succeed — not just technically, but in understanding how to position the integration, how to make it valuable, how to grow it. Public advocacy was the visible part: blogging, speaking, contributing to open source, being present in the conversations where the community gathered. All three mattered. Concentrating on only the public-facing dimension, which was the temptation for companies that thought of advocacy as a form of marketing, produced an evangelist who was good at generating buzz and bad at changing anything.

By 2012, companies like Iron.io were articulating a philosophy that went further: in an API-driven company, everyone is a developer evangelist. The argument drew on Jeff Bezos’s internal Amazon mandate — all teams will expose their data and functionality through service interfaces — and extended it to culture. If the API was how your company exposed itself to the world, then every decision about product, infrastructure, pricing, and documentation was an advocacy decision, and everyone who made those decisions was doing advocacy work whether they acknowledged it or not. I found this framing useful, though it could also become a way for companies to avoid hiring dedicated advocates by asserting that advocacy was everyone’s responsibility and therefore no one’s specifically.

The 2016 snapshot of the profession showed how dramatically it had grown. I did a quick search one afternoon and found seventy companies with open job postings for developer evangelist or developer advocate roles. Google, Twilio, Stripe, Heroku, GitHub, Facebook, Microsoft, Amazon, Shopify, Dropbox — the entire tier of platform companies had decided they needed dedicated people in this function. Keith Casey, a Twilio alum whose judgment I trusted, identified the critical questions to ask before taking one of those roles: what group does the evangelist report to, what are they measured on, and what existing channels are currently working. Those questions cut to the heart of the role’s actual power and likely longevity. An evangelist who reports to marketing, is measured on lead generation, and is being asked to amplify channels that are already performing is not really doing advocacy — they are doing demand generation with a technical veneer. The same role in a different organizational configuration, reporting to product or engineering, measured on developer success metrics, given room to feed real feedback back into the product — that is something different.

I also wrote in 2016 about what the role cost the people doing it. I had a health crisis that year — fatty liver, the result of years of overwork at a pace that wasn’t sustainable. I wrote about it directly because I thought the next generation of evangelists deserved to know the real risk. The role, done honestly, is consuming. You are trying to maintain genuine relationships with a large and distributed community, stay technically current across a fast-moving space, produce consistent content and presence, travel to events, and simultaneously fight internal battles for resources and credibility. The evangelists who burned out weren’t the weak ones. They were often the ones who took the mission most seriously.

My work at Postman as Chief Evangelist gave me a vantage point to synthesize what I had learned about the craft. I wrote in 2019 about the common building blocks of the work: blog posts, social media engagement, Q&A in developer forums, email outreach, meetup talks, conference presentations, webinars, images, videos, tutorials, white papers, code samples, repositories, prototypes, and artifacts — OpenAPI and AsyncAPI specifications, Postman collections, things developers could actually take and use. None of it was secret. The magic, if there was any, came from the storytelling layer that made it coherent and compelling. Consistent application of these tools, pointed in the right direction, over a long period of time — that was advocacy.

The hardest tension in the work was always the same one: whose side are you actually on? An evangelist employed by a platform is paid to advance that platform’s interests. A developer advocate in the truest sense of the word is supposed to advance the interests of developers — which sometimes means criticizing the platform, surfacing uncomfortable feedback, or advocating for changes the business doesn’t want to make. Most roles in practice sat somewhere uncomfortable between those two positions. The best advocates I knew were ones who had negotiated enough internal trust and credibility that they could bring hard feedback in without being dismissed, and enough independence that they could speak honestly about the platform’s limitations without being muzzled.

By 2025, I was writing that developer advocacy had dwindled from its peak. The Google Trends data showed interest declining back toward pre-2016 levels. Funding for DevRel programs had contracted as companies tightened belts and marketing budgets got cut before product budgets. The advocacy that remained was increasingly platform-centric — people hired to promote a specific tool or product — rather than genuinely developer-centric. I wrote that what the space needed was a different kind of advocacy: solidarity among developers across platforms, collective power not organized around any single company’s interests, voices that could push back on the industry as a whole rather than cheerleading for their employer’s quarterly numbers.

The structural problem is that genuine developer advocacy — the kind that represents developer interests back to power, that fights for stable APIs and fair pricing and honest documentation and clear deprecation policies — requires someone who is willing to be inconvenient. Platforms want advocates who make developers enthusiastic about the platform. Developers need advocates who make platforms accountable to developers. Those are related but distinct jobs, and the history of the field is largely the history of that tension playing out inside individual roles, individual companies, and individual careers.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Advocacy

References

Guidance Details

Explore more

Discover APIs