Of Community Practice

Building Something That Actually Lasts

Most communities of practice die within eighteen months. Not because people stop showing up, but because the structure was never designed to handle the transition from casual interest to actual working relationship. I learned this the hard way back in 2014 when I tried to set up a community for senior developers across three time zones. We had six months of weekly video calls, solid attendance, real conversation, and then everyone just... stopped. No dramatic falling out. No conflict. The momentum just ran out. The problem was we had built a discussion group, not a community of practice. There's a difference.

A community of practice is a specific kind of grouping. It's not a networking event, not a support forum, and not a project team. It's a group of people who share a domain of interest, interact regularly, and develop a shared repertoire of resources — practices, tools, stories, frameworks — that they draw on together. Etienne Wenger defined it clearly in the nineties, but the definition doesn't tell you what it actually feels like to run one. The first thing you need to get right is the domain. This is the non-negotiable anchor. Without a clearly defined area of shared interest, you're just running a social club and hoping something educational happens. I've seen too many organizations try to create "communities of practice around leadership" or "communities around agility." These are so broad they contain nothing. A tight domain — say, API gateway pattern design in microservices architectures — creates natural boundaries for what gets discussed, what gets documented, and what gets shared. People know whether they belong without having to ask.

The Core Mechanics of Of Community Practice

Once you have a domain, three structural elements do the heavy lifting: mutual engagement, joint enterprise, and shared repertoire. These aren't aspirational goals. They're operational requirements. If any one of them is missing, the group devolves into something else. Mutual engagement means people show up consistently and interact with each other, not just with a central figure. I spent years watching communities where everyone talked to the facilitator and nobody talked to each other. That's not a community. That's a lecture series with a chat box. The fix is deliberate peer-to-peer structures: pairing people up to co-facilitate sessions, rotating discussion leads, creating sub-groups that report back. It takes more coordination upfront. It pays off in month four when the facilitator gets sick and the community doesn't collapse. Joint enterprise is the shared commitment that emerges over time. Members negotiate what they're doing together. It's not set in stone at launch. In my experience, the joint enterprise of a healthy community shifts noticeably every six to eight months as members bring new problems to the table. The trick is letting it evolve rather than clamping down on scope creep. I once tried to keep a community focused strictly on database optimization because that's what we started with. Within six months, members were bringing questions about query-level infrastructure, cloud cost modeling, and team scaling. When I pushed back, attendance dropped forty percent. When I let the domain expand to include all performance-related concerns, it recovered and grew. The community knew what it was before I did.

Shared repertoire is the output side — the artifacts, templates, playbooks, and internal language that accumulate. This is where most communities fail to demonstrate value. They have great conversations and then nothing exists afterward. I solved this by requiring every session to produce one tangible artifact: a decision record, a refined checklist, a mini-case study. Not long-form documentation. Something that took fifteen minutes to write and would be immediately useful. After a year, the repository of these artifacts became the reason new members joined. They could see the accumulated knowledge.

What Nobody Tells You About Membership

Attendance is a terrible metric for community health. I tracked it religiously for two years across three different communities before I realized it was misleading. You can have ninety percent attendance at monthly meetings and still have a community that's failing. What matters is the ratio of passive participants to active contributors, and how that ratio changes over time. In a working community, you want roughly twenty percent of members doing the heavy lifting — facilitating, documenting, mentoring newcomers — and eighty percent participating at a lower intensity. This is normal. It's also how every sustainable community functions. The problem occurs when that twenty percent burns out, which it does within twelve to eighteen months if you don't rotate responsibilities. I started using a simple rotation system: each quarter, three new people take on facilitation or documentation roles. It feels awkward at first. People resist. But after the first rotation completes, the community's energy measurably improves because the knowledge isn't concentrated in two or three people anymore. Another metric I track that surprises people: the newcomer integration rate. How many new members have their first meaningful contribution within thirty days? If it's below fifty percent, the community is either too insular or too loosely structured. Too insular means existing members have established patterns that newcomers can't enter. Too loose means there's no entry point at all. I solved this for my second community by creating a structured onboarding artifact — a one-page guide that explained the domain, the current priorities, and one small task a newcomer could complete in their first week. It was called "your first contribution." Participation from new members doubled within three months.

A Specific Problem and the Workaround

Here's something I encountered that didn't appear in any of the textbooks. About fourteen months into running a community focused on distributed systems design, I noticed a quiet split forming. Half the members were coming from large enterprise backgrounds where they had dedicated platform teams. The other half were from startups where they wore every hat. They were discussing the same problems but using completely different frames of reference. Enterprise people assumed infrastructural support existed. Startup people assumed everything was built in-house. Conversations were becoming frustrating for both sides. Nobody was wrong. They were just operating from different assumptions about what resources were available. The workaround wasn't to bridge the gap philosophically. It was practical. I introduced a simple pre-discussion format called "context tagging." Before bringing a problem to the group, members added a short tag describing their environment: team size, budget constraints, tech stack maturity, regulatory constraints. This took thirty seconds to write. It changed everything. Suddenly, the enterprise architects understood why the startup people made certain tradeoffs, and the startup people understood why the enterprise people were more conservative. The discussions became more productive because the context was explicit rather than assumed. We kept this format for the remaining two years of that community's life, and it was the single most effective structural change I made. This approach — making implicit context explicit through lightweight tagging — generalizes to almost any cross-organizational community. The friction rarely comes from disagreement about solutions. It comes from unspoken differences in constraints and starting conditions.

When Communities of Practice Don't Work

I need to be clear about this because most guides on Of Community Practice don't mention it: this model fails in several common scenarios, and knowing when to avoid it saves months of wasted effort. First, it doesn't work when the domain is purely procedural and has a single correct answer. If your organization needs people to learn a specific compliance process, a training module works faster and more reliably than a community. Communities excel at ambiguous, evolving domains where experience matters more than procedure. Use them for judgment calls, not checklists. Second, communities fail when participation is mandatory. I watched an organization require all senior engineers to attend their community's biweekly sessions. Within four months, the quality of discussion degraded significantly. People who were there because they had to be started dominating conversations with performative contributions, while the people who actually cared about the domain withdrew. Voluntary participation is not a nice-to-have. It's structurally necessary. The signal of genuine interest is what keeps the group honest.

Third, and this is the one people miss: communities of practice struggle when the organization's incentive structure actively punishes the behaviors the community encourages. If your company measures individual output and rewards private knowledge retention, no amount of community-building work will overcome that. I saw this play out at a consulting firm where partners were evaluated on billable hours. Their "community of practice" for knowledge sharing became a monthly compliance checkbox. Nobody prepared anything. The session ran twenty minutes. The actual knowledge transfer happened on Slack at midnight between people who wanted to do it regardless of the formal structure. The formal community was theater. The informal one was real. In cases where the incentive structure is the problem, the alternative is usually to work within the informal networks rather than trying to build formal ones. Identify the people who are already sharing knowledge voluntarily. Give them a small budget, a recurring calendar slot, and administrative cover. Don't call it a community of practice. Call it a working group. The structural outcome is the same. The psychological framing is different, and that framing matters when organizational culture is hostile to the concept.

Starting From Zero

If you're building one of these from scratch, the sequence matters more than the details. Start by identifying five to eight people who already interact informally about the domain. Not people who *should* interact. People who already do. Map that existing network. Then have a single conversation with them about whether they want to make it regular and intentional. That's it for phase one. Do not write a charter. Do not define membership criteria. Do not set up a communication platform. These all come later, and introducing them too early creates the impression that this is another organizational initiative rather than a genuine gathering of people who already care about the same things. The impulse to formalize quickly is natural. It's also the most common reason early communities stall. After three to four weeks of regular interaction, if the group is still meeting voluntarily, then introduce structure. A shared document repository. A rotating facilitation schedule. A quarterly artifact review. Each of these takes approximately twenty minutes to set up and ten minutes per session to maintain. The maintenance burden is real but manageable if the domain stays tight and the membership stays below thirty active participants.

Beyond thirty, the shared repertoire becomes hard to navigate, and sub-groups naturally form anyway. At that point, you're managing a federation of communities rather than a single one. That's a different operational problem with different tradeoffs.