Conversations

The most important thing I ever did as API Evangelist was talk to people. Not write posts, not build tools, not generate research — talk. Have conversations. The writing and the tools mattered, but they worked because they started conversations, and it’s the conversations themselves that moved things. Evangelism without conversation is broadcasting, and broadcasting alone doesn’t change minds or shift organizations. What changes things is the moment when someone who didn’t understand why APIs matter suddenly does, and that moment almost never happens in a blog post. It happens in a conversation, one-on-one or in a small group, where you can meet someone exactly where they are, speak their language, and walk them toward a different way of seeing.

I said it plainly in 2014 and have stood by it ever since: it’s not just about doing APIs, it’s about having a conversation about APIs. The organizations that succeed with APIs aren’t just the ones that ship the best technology — they’re the ones that keep a conversation going, internally and externally, about what they’re building and why. The conversation is what aligns stakeholders, surfaces problems early, builds the shared vocabulary that makes API strategy coherent, and keeps the human beings in the picture when everything else wants to reduce to a ticket or a spec. An API without a conversation around it is an undiscovered artifact.

The first challenge of API evangelism is knowing which conversation you’re having and with whom. I wrote in 2011 about the distinction between API evangelism and developer evangelism — they’re not the same thing, even though people use the terms interchangeably. Developer evangelism is about reaching the people who will actually integrate with your API, write the code, build the applications. API evangelism is bigger than that — it includes business stakeholders, product managers, executives, partners, non-technical audiences who need to understand the value without needing to understand the protocol. I wrote that same year that APIs are not just for developers, and I meant it as a challenge to the whole field: we were talking past enormous audiences who had a stake in these decisions but weren’t being included in the conversation. The evangelist’s job is to translate across those boundaries — to speak developer to developers, business to business people, and to broker the conversation between them.

The hardest conversation is always the internal one. By 2014 I was writing about internal strategy trumping external API efforts in many conversations I was having — the pattern where organizations build great external APIs but fail to have the internal conversation about alignment, resources, and organizational change. The external-facing developer program gets built while the internal stakeholders who control data, systems, and budgets haven’t been brought along. That’s a political failure before it’s a technical one, and it’s a conversation failure. The evangelist’s first job is often not the community meetup or the conference talk — it’s the meeting with the VP who controls the data the API needs to expose, the one where you explain why opening this up creates more value than it creates risk. Those internal conversations are unglamorous and under-documented, but they determine whether the external evangelism ever gets anything to talk about.

Prototypes are one of the best conversation-starters I’ve found. I wrote in 2014 about jumpstarting the API conversation using prototypes — the way a working demo, even a rough one, shifts a conversation from abstract to concrete faster than any presentation. A prototype says: this is what it would look like. People can react to a prototype in ways they can’t react to a proposal, and their reactions tell you what they actually care about rather than what they say they care about. The conversation a prototype generates is richer and more honest than the conversation a deck generates, because you’ve moved from persuasion into exploration. I used this approach constantly — whether it was a rough API implementation, a working collection, or a generated SDK — as a way to give people something to push against.

Storytelling is the form conversation takes at scale, and it’s the tool I’ve returned to more than any other. I developed what I called hacker storytelling back in 2012 — the practice of combining working code and projects with narrative, so that the stories aren’t just words but are demonstrated through real artifacts. This came from watching how the best evangelists in the field operated: they didn’t just talk about what was possible, they showed it, and the showing plus the story together were more persuasive than either alone. By 2013 I was writing about why API providers should tell stories about their platform, using Netflix as an example — not just documenting features but narrating the journey, explaining the reasoning, sharing what worked and what didn’t. The blog for your API is the most important signal you can send, I wrote in 2014. It’s how a provider shows whether they’re engaged and thoughtful or just throwing an endpoint over the wall and walking away.

The discipline of storytelling for evangelism has some specific requirements that distinguish it from marketing copy. I wrote a practical guide in 2015 about where to start with the storytelling drumbeat for an API — the consistent cadence of posts, tutorials, case studies, and updates that keeps an API alive in its community’s attention. The word drumbeat matters: it’s not about a single great story, it’s about the rhythm. Consistency signals health and commitment. I wrote in 2015 about how to build an API brand through consistent storytelling, and the honest point there is that it’s an organic process — you don’t build an API brand through a campaign, you build it through sustained presence over months and years. The organizations that want to shortcut the drumbeat with a launch announcement and then silence discover that the community moves on. The 2017 piece about robust public storytelling as a sign of API maturity put this more bluntly: if you’re not talking about your API process openly, you probably don’t have a process worth talking about.

The community forum as a conversation space deserves its own recognition, because it’s where I developed a specific practice that I’d recommend to any evangelist: turning forum posts into blog stories. I wrote about this in 2012 — the discipline of reading what developers are asking in your support forums and turning the most common, most revealing questions into full blog posts. This accomplishes several things at once: it answers the question for everyone, not just the one person who asked; it signals that you’re listening; it generates content that is guaranteed to be relevant because a real person already needed it; and it forces you to fully understand the question, which improves your own understanding of how your API is actually being used and where it’s actually confusing. The forum is a live feed of what conversations people need to have, and the blog post is how you have those conversations at scale.

The sustained storytelling assault is the phrase I used in 2016 writing about the banking industry — the idea that industry-level evangelism sometimes requires a long, patient campaign of conversation over years, not a single argument. Banking didn’t adopt open APIs because of any one conversation or any one conference talk. It moved because people like me, and others across the industry, kept having the same conversations in different rooms, writing the same arguments in different forms, until the cumulative weight of it shifted the Overton window of what was possible and normal. That’s what sustained evangelism looks like at an industry scale: relentless, patient, repetitive, and ultimately effective not because any single conversation was decisive but because the pattern of conversations changed the ambient assumptions of an entire sector.

The nuanced conversations are where I’ve found some of my most important work happens. I wrote in 2015 that when organizations are ready for a nuanced discussion about who has access to their API, I’m here — meaning that the easy early conversation about “should we have an API?” eventually gives way to harder questions about access tiers, partner relationships, data governance, regulatory requirements, and the politics of who gets to see what. Those harder conversations require more trust, more shared vocabulary, and more willingness to sit with ambiguity than the evangelism entry point does. Building toward those conversations is the long game: the early evangelism creates the relationship and the shared language that makes the harder conversation later possible.

API definitions, I wrote in 2015, broker critical conversations between business and developers building the next generation of web, mobile, and device applications. This is underappreciated: a good OpenAPI definition isn’t just a technical artifact, it’s a conversation tool. It gives business stakeholders something concrete to react to, gives developers something to build against, and gives everyone a shared reference point so the conversation stops being about abstractions. The machine-readable contract is also a human-readable conversation starter — here’s what this API does, here’s how it works, let’s talk about whether that’s right. The spec as a conversation facilitator is one of the most practical arguments for the investment in good API definition work.

Sharing stories from your API operations openly, I wrote in 2014, is essential — not just for external evangelism but for internal learning and the community at large. The instinct in most organizations is to share only the wins, but the failures and the lessons are more valuable. The community forms around people who are honest about what they’re learning, not around people who pretend everything is working perfectly. I lost my storytelling voice for a period, I wrote in 2013 — a candid admission that the voice and the discipline are things you can lose, that they require tending, and that without them the work becomes mechanical. The evangelist’s voice is not just a channel; it’s the thing that makes the conversation worth having.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Conversations

References

Guidance Details

Explore more

Discover APIs