The API Program is a Club, Not a Catalog

In past Notes, I've pushed my share of pixels extolling the virtues of soft skills in creating successful API programs (e.g., "Standards Evangelization Isn't Optional",  "Solving API's Collective Action Problem," "Harmony Humans: Defining the Role of API Governance," etc.). These meetings, relationships, and acts of emotional labor are not glamorous work, but they're the glue that keeps shiny architecture hopes and dreams from getting lost in the shuffle.

Sure, your API leaders may be hyped to have finally established a centralized catalog or published a design standard, and they should celebrate! Those are no small feats. But when it comes to a long-lived, successful API program, completing those projects is where the real work starts.

The fact is that "build it and they will come" is not a usage strategy.  And adoption won't scale via enterprise mandate.

And yet, that's the default playbook: announce, align, enforce, and wonder why fervor is over faster than a refresh token.

The Slow Fade

Building alliances and maintaining a passionate body of practitioners are critical to improving technical maturity over time. And new efforts often easily attract a crowd; many people are naturally attracted to being part of something perceived as necessary. Someone brings donuts, ideas fly, Miro/Mural/FigJam/Lucidchart/Microsoft-Whiteboard screens blossom. Then, the sugar rush fades. Cans are kicked down the road. The same three loyalists show up while everyone else ghosts. 

Anyone who has chaired or led an API working group, Center of Excellence (COE), or Community of Practice (CoP) recognizes the struggle:

1. High Initial Energy: Things start with excitement. Issues are addressed. Many of the initial problems are overcome with little more than consistently applied enthusiasm.
2. The Drop-Off: A few weeks/months later, the organizer is begging, pleading, and cajoling people to show up. Priorities have shifted. The same handful of people attend every meeting. The group has stalled.

The challenge for these initiatives isn't the technical content; it's maintaining consistent experience. Even when people believe in the purpose, regular participation fades without structures that create belonging. I see otherwise really smart people trip over themselves here, again and again, because - unfortunately - a professional lifetime in the terminal arts doesn't prepare one to deal with the complexity we call human beings.

My core thesis is that an API Program is a community problem disguised as a technical delivery.

A Design Pattern for Belonging

Whether it's a D&D table, a running club, or an API guild, sustained participation follows the same blueprint: identity, rhythm, and recognition.

• Shared Identity: People show up when they feel part of something distinct.
• Predictable Rhythm: People trust what they can anticipate.
• Recognition: People commit to what acknowledges them.

When every creator is trying to appeal to a broader audience, I'm going to indulge my inner contrarian and speak even more narrowly to those responsible for an API community at their company. We can adopt simple design patterns to make participation more natural and self-sustaining. This isn't about politicking, manipulation, or micromanagement; it's about scaffolding trust. And it is totally something even an introvert like me can do.

Patterns for Program Engagement

1. Create a Shared Language

A community's language defines its culture. Create an internal shorthand that feels earned; something that people actually want to say, not the 14-syllable acronym nobody remembers (e.g., "CoP champions," "The 200 Club", "4xx Therapy" for coaching sessions). This language makes the participation feel like entering a familiar world. Use these consistently across channels (slides, invites, Slack) to reinforce identity.

You may not have this language all at once. It may take time for "coins of the realm" to emerge - the in-jokes, nicknames, etc. But when they do, hang on and treasure them. 

2. Build Simple Rituals

Predictability is underrated. Even a recurring 30-second "show-and-tell" of last week's best API effort can become a campfire everyone gathers around.

Rituals signal belonging and transition. Spend time thinking about how you show up. If you're the facilitator, that could be starting each meeting with the same brief opener - a highlight from the last session, or a "what we've learned" reflection. End consistently with a shared summary, thank-you round, or next-step pledge. Predictable rhythms build reliability, develop habitual calendar discipline, and build trust.

3. Show Confident Facilitation

Certainty, not control, is what draws people in. Leaders don't need every answer but must communicate with calm conviction about direction and progress (for an example of this, see my post from a few months ago, "Standards Evangelization Isn't Optional"). Small theatrical touches - narrating milestones, naming challenges - turn ordinary updates into moments of shared story.

4. Use a Recognizable Aesthetic

A clear visual and tone identity helps the group feel tangible. Consistent colors, slide templates, and even shared Slack emojis create continuity. The goal isn't branding for branding's sake, but cues that signal "you're in the right place."

During the ZIRP days, there might have been a budget for a custom logo, wearable swag, and laptop stickers galore. Unfortunately, it's a very different business climate, and there are fewer of those allowances to go around. If there's a silver lining, it's that consistent slides, a carefully manicured online space, and a personable tone can all be had for next to nothing. 

But if you can swing for stickers, you should totally swing for stickers.

5. Welcome and Reward Participation

Intentional onboarding keeps energy high. Personally invite new members and pair them with active participants. Recognize attendance and contributions - a shout-out in the meeting or a small token goes a long way. Acknowledge the effort.

There are several ways in which welcoming and rewarding may manifest. It might mean introducing a newcomer to an existing member who helps them publish their first API or navigate the portal registration. It could be celebrating each member's first successful pull request merged into the standards repo (a small Slack badge or flair for their email sig works). Or a leader might award points for attending sessions, mentoring others, or answering support questions, then formally recognizing those individuals whose points cross certain thresholds. 

Participation is habit-forming when it's noticed. You don't need elaborate incentive programs; just a steady hum of "we saw you, we appreciate that". The more visible the gratitude, the more likely others are to join the effort.

Summary: Stop Pushing Pixels, Start Pushing People

Belonging isn't accidental. When language, ritual, and recognition are intentionally designed, showing up becomes the easy choice. These aren't control mechanisms; they are the scaffolding of trust that lets people invest freely. Approach your community challenge accordingly. 

If you'd like to dig deeper into this topic, I suggest checking out the following items:

• [a book for wisen types unafraid of an academic tome] Etienne Wenger, Richard McDermott, and William M. Snyder. Cultivating Communities of Practice: A Guide to Managing Knowledge. Harvard Business School Press, 2002. A foundational reference on how intentional structure and identity sustain communities in business environments over time. You can find podcasts where Etienne and Beverly Wenger-Trayer discuss their most recent work.
• [another, more approachable book] Priya Parker. The Art of Gathering: How We Meet and Why It Matters. Penguin Random House, 2018. A moving exploration of why most meetings fail and how to, instead, pursue intentional group design (she's also got a high-level TED interview available). 
• [a YouTube video for the time-pressed scrollers] Brikoblin, "Using REAL CULT TACTICS to improve your D&D group!" YouTube, 2025. A surprisingly insightful look at engagement, belonging, and ritual - minus the headlines - filled with vivid examples to borrow.

Milestones

• The Marvel Developer Portal (with the Marvel Comics API) is shutting down. A staple of examples, tutorials, and hackathons for more than a decade, this news is understandable, but still a bummer. 
• Structured outputs are now available on the Claude Developer Platform API. That is, you provide specific JSON schemas, and Claude ensures responses match. Cool.
• Postman acquired liblab, an automation tool that generates Software Development Kits (SDKs).
• Meanwhile, Jean Yang, who was the founder and CEO of Akita, an observability startup acquired by Postman in 2023, has now left the company. 
• Benn Jordan has a great story on how hackers can access 80,000+ police cameras (and, yes, there's a pretty significant API aspect to the story). 

Wrapping Up

Thanks a bunch for reading. On my personal site, I've started posting some short stories. The latest, Hurricane David, is a corporate-gothic tech-tragedy set in a near-future Florida Archipelago. While the story itself is fiction, the events that inspired it are not. If that sounds like your jam (or you just want something else to do while coping with an RTO mandate), head over to my "Stories" page to get started.  

I'll catch you again in the next edition.

Till then,

Matthew (@matthew in the fediverse and matthewreinbold.com on the web)