Communities of Practice for AI: An Operating Model

A financial-services client I worked with last year did everything the launch playbook told them to. They created an AI channel, wrote a warm announcement from the CIO, pinned a getting-started guide, and invited four hundred people. For about a week it was busy. Then it wasn’t. By the third week the only posts were the automated ones from the tool that had been wired up to celebrate milestones nobody was reaching. When I asked what had happened, the honest answer from the person nominally in charge was that they had assumed the community would run itself once it existed. It existed. It did not run.

That is the single most common mistake in AI adoption, and it is worth naming precisely: a channel is not a community of practice, and standing up the channel is not standing up the community. The workforce-readiness framework argues that proficiency is built socially, through people learning from each other doing real work, and that the social layer is the move most programmes skip. This is the operating model for that layer. Not the theory that it matters, which is well established, but the mechanics of how one is actually run so that it survives past the launch email and starts producing the behaviour change it exists to produce.

The four roles

A community of practice is an operating model, and an operating model has roles. There are four that matter, and the failure to fill any one of them shows up quickly.

The sponsor is a leader senior enough that their protection of the community’s time is credible. Their job is not to run it or to post in it. Their job is to make the steward’s time real and to defend the ritual when delivery pressure comes for it, which it will. A community without a sponsor is a hobby, and hobbies lose to deadlines.

The steward runs it. This is the load-bearing role, and the mistake worth naming is choosing the wrong person for it. The steward is not necessarily the strongest engineer or the earliest adopter. They are the most connective person available, the one who knows who is trying what across teams and takes pleasure in introducing the two. They seed the channel, they surface results, they grow the prompt library, they respond so the room is never empty, and they do all of this on protected time that a line in their objectives makes legitimate. A brilliant technologist with no time and no mandate is not a steward; they are a volunteer who will burn out by the second quarter.

The core contributors are the ten or fifteen percent who post without being asked. Every community has them latent within it, and the steward’s early job is to find them and give them a stage. They are the proof that the community is real, because a result posted by a peer is worth more than any amount of encouragement from a leader.

And then there is everyone else, the majority who read and rarely post, and whose conversion from reading to doing is the actual point of the whole exercise. The error is to treat their silence as failure. A lurker who tries a challenge in private because they saw a colleague do it has been changed by the community even though they never posted in it. The visible feed is working on the invisible majority, and that is by design.

The prompt library is the shared asset

Every durable community of practice is organised around a shared asset that gets better over time, because a shared asset that improves is the reason to come back. For an AI community, that asset is the prompt library: the collection of prompts that colleagues have found actually work, on real work, organised so the next person can find and reuse them.

The library is what converts one person’s ten-minute win into everyone’s ten-minute win. Someone works out the prompt that reliably turns a messy set of meeting notes into a structured ticket, they post it, and now that problem is solved for the whole function rather than for one afternoon for one person. Multiply that across every repetitive language-shaped task in the organisation and the library becomes the single most valuable artefact the programme produces, more valuable than any course, because it is specific to your workflows and it compounds.

It needs light governance, and the operative word is light. A short review so that genuinely bad or unsafe prompts do not become canon, a clear rule about what data may go into the tools these prompts drive, and a structure by function so the library stays navigable as it grows. Over-governing it is its own failure: if contributing a prompt requires an approval workflow, nobody contributes, and the library ossifies at whatever the steward seeded it with. Bias hard towards contribution, correct at the margin, and let the library be a living thing rather than a controlled document.

Run it on rituals, not enthusiasm

The reason communities die is that they are launched on enthusiasm, and enthusiasm is front-loaded and decays. What carries a community through the flat middle, after the novelty has worn off and before the habit has set, is rhythm. A predictable, repeating set of rituals gives people a reason to show up that does not depend on how excited they happen to feel that week.

The core ritual is the challenge of the week: one runnable mini-challenge per week, posted by the steward, with an explicit nudge to complete it and share the result. It gives the community a heartbeat and a reason to return. Around it sit lighter rituals that cost almost nothing and matter more than they look: a short monthly show-and-tell where two or three people demonstrate something they got AI to do on their real work, and open office hours where the steward and the core contributors help anyone who is stuck. None of this requires production. It requires that it happens on the same day every week without fail, because the reliability is the point. A ritual that happens when someone remembers is not a ritual.

Seed the first month yourself

The most useful single piece of advice for a new community, and the one most likely to be ignored, is that the steward personally seeds essentially all of the first thirty days. An empty channel is a strong signal that this is not worth anyone’s time, and that signal is self-fulfilling. So the steward posts the first challenges, posts their own results including the ones that did not work, adds the first twenty prompts to the library, and responds to every early contribution quickly enough that contributing feels rewarded rather than shouted into a void.

This maps onto the oldest reliable model of how people build capability at work, the rough seventy-twenty-ten split, in which the large middle share comes from learning through other people. Corporate programmes chronically underfund that middle share and pour the budget into formal courses instead. The community of practice is the mechanism that funds the twenty, and the seeding period is the cost of getting it running. Somewhere around the second month, if the rituals are real and the seeding was diligent, contribution crosses over from the steward to the members. That crossover is the milestone that actually matters, more than the member count and far more than the launch-day attendance. Before it, the community is being kept alive. After it, it lives.

Federate before it becomes noise

A community works because it feels like a room where people recognise each other and a result is legible as one specific colleague’s win. That property degrades with scale. Somewhere between fifty and a hundred active members, a single feed becomes noise, the signal stops reaching the people it would help, and, counterintuitively, participation falls as the community grows.

The answer is not a bigger central community. It is federation: per-function or per-division communities, each with its own steward and its own library section tuned to that function’s real work, connected by a thin coordinating layer where the stewards themselves meet to compare notes and promote the best challenges and prompts across boundaries. Sales learns differently from engineering and its useful prompts are different prompts; forcing both into one feed serves neither. Centralise the standards, the data rules, and the best cross-cutting material. Federate the actual practice down to where the work is specific. The coordinating layer is what keeps a federation from fragmenting into disconnected silos, and it is usually just the stewards in a room once a month, which is a cheap price for coherence.

The verdict

A community of practice is not a channel you create; it is an operating model you run. It has a sponsor who protects the time, a steward who does the connective work on that protected time, a prompt library that compounds, and a rhythm of rituals that carries it through the flat middle where enthusiasm has faded. Get those right and the social layer of adoption, the one Gartner’s diagnosis points straight at when it warns of a workforce that is compliant but not capable, actually functions. Get them wrong, or assume the channel runs itself, and you will have a silent feed and a story that your people were not interested, when the truth is that nobody was ever made responsible for the community’s life.

Where this connects: the community runs on the mini-challenge library, it needs the protected learning time to be real or its rituals get eaten, and its health is read through the leading indicators in the adoption measurement set. All four are one programme, and it sits inside the workforce-readiness framework that explains why the social layer is the part you cannot skip.