Developers

Developers are the audience that API evangelism exists to reach, and getting the relationship with them right is the difference between an API that thrives and one that languishes with great technology nobody uses. For all my insistence that APIs are not just for developers — that business stakeholders and end users and the broader public all matter — the developer is still the person who actually integrates, who writes the code, who turns your API from a published artifact into a working application. Evangelism is, at its core, the practice of earning developers’ attention, trust, and adoption. And the thing I learned early and have never stopped believing is that you cannot fake this. Developers have a finely tuned detector for inauthenticity, and the entire enterprise of developer evangelism collapses the moment they sense they’re being marketed to rather than genuinely helped.

The first distinction I drew, back in 2011, was between API evangelism and developer evangelism. They overlap but they aren’t the same. Developer evangelism is specifically about reaching the developers who will build on your API — the technical outreach, the documentation, the SDKs, the hackathons, the support. API evangelism is broader, encompassing the business and public audiences too. But the developer is the beating heart of both, because even when you’re persuading a business executive to adopt an API strategy, you’re ultimately making a case about enabling developers to build things. Understanding the developer as a distinct audience with distinct needs — different from how you’d talk to a buyer or a partner or a journalist — is the foundation of the whole practice.

The most important and most uncomfortable truth I’ve written about is that developers resist evangelism, and they’re right to. I wrote a piece in 2012 with exactly that title — developers resist API evangelism — because the word “evangelism” itself carries the whiff of salesmanship that developers instinctively distrust. The lesson isn’t to stop evangelizing; it’s to evangelize authentically. Developers don’t want to be pitched. They want to be helped. They want accurate documentation, working code samples, an API that does what it says, and a human being who actually understands their problem when they get stuck. The authentic evangelist succeeds by being genuinely useful, by being a developer themselves or at least deeply respecting the developer’s craft, and by treating the relationship as a long-term investment in mutual success rather than a conversion funnel. You can feel it, as I wrote in 2015, when an API evangelist is the real deal — and developers can feel it even more acutely than I can.

Not frustrating developers is the unglamorous foundation underneath all the strategy, and it’s where most programs fail before they even start. My very first substantial writing on this, in 2010, was about how to avoid frustrating your API developers — and the frustrations are mostly basic: broken or inaccurate documentation, confusing authentication, an API that doesn’t behave consistently, no clear path to get help, a registration process that throws up barriers before the developer has even made their first call. I wrote separately about why API registration processes suck, because the onboarding moment is where you lose people. Every point of friction between “I’m curious about this API” and “I made a successful call” is a place where a developer gives up and goes to a competitor. Evangelism that brings developers to a frustrating experience is worse than no evangelism, because you’ve spent your credibility delivering them to disappointment.

The developer champion — what I called the unicorn — is the highest-leverage relationship in all of developer evangelism. I wrote in 2011 about feeding the unicorns and nurturing developer champions, because every healthy API community has a small number of developers who genuinely love the platform, who advocate for it inside their own companies and across the community, who answer questions and write tutorials and show up without being paid to. These champions are disproportionately valuable and disproportionately fragile. A champion who feels used, ignored, or burned will quietly disappear, and you almost never get them back. The care and feeding of developer champions — recognizing them, supporting them, giving them early access and real influence, showcasing their work — is one of the most important things an evangelism program does, and it almost never appears on a roadmap because it doesn’t fit a funnel. Showcasing developers and their applications, which I was writing about as far back as 2010, is part of this: when you put a developer’s work in the spotlight, you reward them, grow their reputation, and signal to everyone else that this is a community where contribution is seen.

Meeting developers where they live is the principle that should govern where and how you do the outreach. I wrote in 2016 about focusing on interacting with the developer community where they already are — not demanding they come to your platform, your forum, your events, but going to GitHub, to Stack Overflow, to the meetups and conferences and Slack channels and subreddits where developers actually spend their time. This connects directly to the Twilio-derived principle I’ve cited constantly: be part of your community, do not just sell to it. The evangelist who shows up at the meetup to help debug someone’s integration builds more goodwill than the one who shows up to give a pitch. Developer evangelism done right is presence, participation, and genuine contribution to the spaces developers already inhabit, not a campaign to lure them into yours.

Hackathons and developer events are a specific and powerful evangelism vehicle, and I’ve thought hard about how to do them well. I wrote in 2011 that API contests and hackathons are a marketing vehicle — but I meant that descriptively, with eyes open about both the value and the limits. A hackathon gets developers hands-on with your API in a concentrated burst, generates real applications and real feedback, surfaces the rough edges in your onboarding, and builds relationships in person that sustain a community. But hackathons done cynically — purely as lead generation, with no genuine support or follow-through — produce resentment rather than adoption. The value is in the authentic engagement: developers building real things, getting real help, and walking away with a genuine relationship to the platform, not just a t-shirt and a vague pitch.

The institutional and human dimensions of developer evangelism matured a lot over the years, and I tried to document that maturation. It takes a team of evangelists to raise an API, I wrote in 2014 — one person can’t carry a developer program at scale; you need a team covering documentation, outreach, support, content, and community. By 2016 there were seventy-plus companies with open job postings for developer evangelists and advocates, evidence that the industry had recognized developer relations as a real discipline worth staffing. My deep research for the Department of Veterans Affairs in 2018 on developer outreach was an attempt to codify the whole practice for a government context — documentation, forums, sandboxes, metrics, staffing, the full apparatus of treating developers well at institutional scale. And I wrote about internal API evangelism as having its own phases, because inside large organizations the developers you most need to reach are often your own, and winning internal developer adoption is its own long campaign.

The human side is where I’ve landed most firmly, and it’s where I’d want any evangelist to focus. SOA versus API — the humans win, I wrote years ago, meaning that what distinguished the successful API movement from the heavyweight enterprise approaches that preceded it was a relentless focus on the human developer rather than the abstract system. Glitch, I wrote in 2017, is where you learn the essential human side of operating your API — watching real people, often beginners, try to build real things teaches you more about your developer experience than any analytics dashboard. The KPIs that matter, I argued in 2012, should be optimized for developer success, not just for monetization — because a developer who succeeds with your API is the source of every good outcome that follows, and a developer who fails is a cost no matter how you measure it. When I joined Postman as Chief Evangelist in 2019, and in everything I’ve written since about my personal evangelism algorithm and what it means to be an evangelist, the through-line is the same: developer evangelism is fundamentally about respect for developers and genuine investment in their success. Where is developer advocacy going, I asked in 2025 — and wherever it goes, it will only work if it stays rooted in that authentic, human, developer-first respect. The technology changes. The need to treat developers as people whose success is your success does not.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Developers

References

Guidance Details

Explore more

Discover APIs