API Evangelist API Evangelist
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC

Storytelling

Narrative as the most important tool in the API evangelism toolbox

Storytelling is the single most important tool in the API toolbox, and I’ve said it so many times that it has become one of the defining claims of my entire career. The technology never sells itself. The specification never explains its own significance. The platform never makes its own case. A story does all of that — it takes something abstract, technical, and inert and makes it matter to a human being by connecting it to what they care about. I’ve watched brilliant APIs fail for lack of storytelling and ordinary APIs thrive because someone told their story well, and the pattern is so consistent that I’ve built my whole practice of evangelism around it. If you take one thing from everything I’ve ever written about how to do APIs well, it should be this: tell the story, tell it consistently, and tell it in a way that’s genuine. Storytelling is where the abstract value of an API becomes something people can understand, believe, and act on.

Hacker storytelling was the framework I developed early to capture what makes API storytelling distinctive, and it’s still the core of how I think about it. I wrote about hacker storytelling in 2012 — the practice of combining real, working code and projects with narrative, so the stories aren’t just words but are demonstrated through actual artifacts. This is what separates API storytelling from marketing copy: the best API stories show as well as tell, pairing a compelling narrative with a real prototype, a working collection, a live demonstration. The hacker storyteller doesn’t just describe what’s possible; they build a small thing that proves it and then tell the story around it. That combination of genuine technical substance and genuine narrative is far more persuasive than either alone, because it earns credibility with the technical audience while making the value legible to everyone else.

The drumbeat is the discipline that makes storytelling actually work, and it’s where most people fail. I wrote in 2015 about where to start with the storytelling drumbeat for an API — and the word drumbeat is deliberate. Storytelling isn’t a single great story; it’s a sustained, consistent rhythm of stories over months and years. One blog post, one announcement, one demo doesn’t build anything. The consistent cadence — the steady production of stories, tutorials, case studies, and updates that keeps an API alive in its community’s attention — is what builds a brand and an audience. I wrote in 2015 about building an API brand through consistent storytelling, and the honest point is that it’s organic and slow: you don’t build a brand through a campaign, you build it through showing up with genuine stories, week after week, until the cumulative weight of them establishes your presence. The drumbeat is the difference between storytelling that builds something durable and storytelling that’s a one-time flash.

Storytelling operates at industry scale, not just for individual platforms, and that’s some of its most powerful work. I wrote in 2016 about the sustained API storytelling assault on the banking industry — the idea that shifting an entire sector’s relationship to APIs requires a long, patient campaign of storytelling, told in different rooms and different forms, until the cumulative weight changes what’s considered normal and possible. Banking didn’t adopt open APIs because of any single argument; it moved because people kept telling the same stories until the ambient assumptions of the whole industry shifted. The Netflix storytelling I admired in 2013 was about a platform telling the story of its own journey — not just documenting features but narrating the reasoning, the failures, the evolution — and demonstrating that public storytelling about your process is a sign of maturity, as I argued in 2017. The robust, honest, public telling of your API story signals that you’re a serious, engaged operator rather than someone who threw an endpoint over the wall.

The shortage of storytellers is a real and recurring problem, and I’ve called for more of them repeatedly. I wrote in 2017 that we need more API evangelists and storytellers — because there have never been enough people who can bridge the technical and the human through narrative. This is the scarce skill in the API world: not the ability to build the technology, which many people have, but the ability to make the technology matter to people through story. The storyteller takes the abstract and makes it concrete, takes the technical and makes it human, takes the feature and connects it to a reason someone should care. That skill is rarer and more valuable than the field generally recognizes, and the API programs and the broader industry are perpetually under-supplied with people who can do it well.

The honest, personal truth about storytelling, which I’ve been candid about, is that it’s a craft that requires tending and can be lost. I wrote in 2013 about losing my storytelling voice — a vulnerable admission that the voice and the discipline are not permanent possessions but things that have to be maintained through practice. When you stop telling stories, the muscle atrophies, and the work becomes mechanical. The hands-on storytelling blueprint I developed in 2021 was an attempt to make the practice teachable and repeatable — to give people a way to combine blog, video, images, interactive workspaces, and real executable artifacts into stories that let the audience do something, not just read something. Across everything I’ve written, the through-line is that storytelling is the heart of evangelism and the most important tool in the API toolbox — the craft of making the abstract matter to humans through narrative, sustained as a consistent drumbeat, grounded in genuine technical substance, and maintained through ongoing practice. The technology is necessary, but it’s the story that makes anyone care, and the storyteller who can reliably make people care is the most valuable person in the room. I’ve staked my career on that belief, and fifteen years of watching APIs succeed and fail has only confirmed it.

References