Internal

Internal evangelism is the unglamorous, invisible, and often most important third of the evangelism job — the work of winning over your own organization. Everyone pictures evangelism as the public-facing work: the conference talks, the blog posts, the developer outreach. But before any of that matters, someone inside the organization has to convince the stakeholders who control the data, the budgets, the systems, and the priorities that APIs are worth doing at all. That internal persuasion is evangelism aimed inward, and I’ve argued for over a decade that it’s where most API programs actually succeed or fail. The external program gets the attention, but the internal evangelism is the foundation underneath it. You can’t build a thriving external developer ecosystem if you haven’t first won the internal fight to expose the capabilities, allocate the resources, and align the organization behind the API effort.

The internal-versus-external balance is something I framed early, and it’s central to how I think about evangelism. I wrote in 2011 that API evangelism is equal parts internal, partner, and public outreach — roughly a third each — and the internal third is the one most programs neglect. By 2014 I was writing that internal strategy was trumping external API efforts in many of the conversations I was having — meaning that organizations were discovering their API problems were internal before they were external. The flashy developer program couldn’t succeed because the internal alignment, the internal buy-in, the internal capability to actually expose and maintain the API, wasn’t there. Internal evangelism is the work of building that foundation, and it looks completely different from external evangelism — more politics, more patience, more one-on-one persuasion, less stagecraft.

The Amazon mandate is the canonical example of internal evangelism done with maximum force, and I’ve returned to it many times. I wrote in 2012 about the secret to Amazon’s success being internal APIs — the Bezos mandate that required every team to expose its capabilities through service interfaces, with no exceptions and no back channels. That mandate was internal evangelism by executive fiat: the organization was forced to adopt an API-first internal culture, and the external success of AWS grew directly out of that internal transformation. The lesson I drew, and stated in 2012 as the secret to a successful API being internal, is that the public API is downstream of the internal API discipline. Amazon could expose world-class external APIs because it had first done the internal work of making everything an API internally. Most organizations want the external success without doing the internal work, and that’s exactly backwards.

The practical tactics of internal evangelism are real and learnable, and I’ve documented them. Demo days, or “demo Fridays,” which I wrote about in 2011, are one of the most effective — regularly showing the organization what APIs make possible, building awareness and excitement internally through demonstration rather than abstract argument. Internal API search engines and catalogs, which I wrote about in 2014, help the whole organization (not just developers) discover and understand the internal APIs available to them. Developing internal API curriculum and workshops educates the organization. And the perennial question I addressed in 2011 — how do I convince my managers of the importance of having internal APIs — is the starting point for so many practitioners, because the internal sell to leadership is where every API program begins. The JCI/Panoptix case I covered in 2014 was about exactly this: selling not just the API but the overall approach internally, the harder and more important sell.

The four phases of internal evangelism is the framework I developed to capture how internal persuasion actually unfolds, and I wrote about it in 2019. The phases are silence, challenges, questions, and engagement — the predictable arc an organization moves through as you evangelize internally. At first there’s silence, indifference, no response. Then come the challenges, the technical and political pushback, the reasons it won’t work. Then, if you persist, come genuine questions — the sign that people are actually engaging with the idea. And finally engagement, real adoption, the organization starting to internalize the API approach. The crucial insight is that this takes time and repetition, and that the early silence and challenges are not failure — they’re stages you have to move through. Internal evangelists who give up at the challenge phase never reach engagement. The framework gives you the patience to keep going through the hard early phases.

There’s a hard-edged honesty I’ve brought to internal evangelism too, because it can be genuinely frustrating. I wrote a pointed piece in 2017 that your internal dysfunction is not my API problem — capturing the exhaustion of watching organizations blame their APIs for what are actually internal organizational failures. The API is often fine; the problem is that the organization can’t agree on ownership, can’t allocate resources, can’t align its teams, can’t make decisions. Internal evangelism frequently means confronting organizational dysfunction that has nothing to do with technology, and recognizing that no amount of API work will fix a fundamentally broken internal organization. The internal evangelist has to be part technologist and part organizational therapist, because the obstacles are usually political and cultural rather than technical.

The trajectory I find most striking is that internal APIs have quietly become the dominant reality, which makes internal evangelism more important than ever. I wrote in 2025 that increasingly people’s entire experience with APIs is only with internal APIs — most developers in most enterprises work with internal APIs far more than public ones. The public API economy gets the attention, but the vast majority of actual API activity is internal: services talking to services inside organizations, internal platforms, internal developer experiences. This means internal evangelism — getting organizations to do internal APIs well, to treat their internal APIs with the same discipline as public ones, to build internal API cultures — is where the real work increasingly is. I’ve long argued for treating all APIs like they’re public, applying the same care to internal APIs that you’d apply to external ones. The internal third of evangelism that I identified back in 2011 has turned out to be, for most organizations, the largest and most consequential part of the API story. The internal work was always the foundation; now it’s increasingly the whole building.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Internal

References

Guidance Details

Explore more

Discover APIs