Prompted by a job opportunity, today I compiled some of my thinking around communities of practice (CoP).
The following points are informed by my many years of supporting individual communities and company-wide CoP initiatives. I assume that you are already familiar with communities of practice basics, including their potential benefits. If this is not the case, please see the ‘For further reading’ section below.
- Communities are groups of people that come together by choice around a shared topic of interest. In the case of communities of practice (CoP), the shared interest is the “practice”, which can be either a role (e.g. Product Managers, Business Analysts, Project Managers, etc.) or a product, service, skill, or technology area (e.g. Contract Manufacturing, Strategy Consulting, Machine Learning and Artificial Intelligence, etc.).
- Communities of practice are distinct from the company’s formal organizational structure. Departments or functions are not communities of practice, albeit they may exhibit some characteristics of a community (e.g. a sense of belonging, or a commitment to shared-learning).
- While never dictated, community participation should be encouraged via company leadership support, internal marketing, and member recognition — both informal recognition and recognition as part of the company’s formal performance management framework. I have also seen gamification successfully used in a CoP to encourage participation in community activities.
- Communities should be maximally welcoming. Diversity in company function (e.g. Sales or Engineering), gender, age, company rank (career level), experience, work location, etc. is positively correlated with community value. Within the community, all voices are equal and breaking down organizational silos is one of the value propositions of communities.
- Communities may leverage technology; however, shared technology alone does not make a community. A valuable community might meet in person and use no technology at all. An equally valuable community might rely only on email and conference calls. More advanced technology such as online workspaces and enterprise social network software are “nice to haves”. Technology should never be confused to be the community. For example, a mailing list alone doesn’t make a community, although a community might use a mailing list. The community is the membership and their sense of shared identity and purpose. Period.
- The community members must be visible to everyone in the community, and (if desired) those outside of the community. To this end, a community should have some form of membership directory that provides member photos, work location, contact information, formal role, any community role, interest areas, etc. The directory is one tactic, of many, for helping community members strengthen their connections with each other. Ideally, the community directory is dynamically created from a pre-configured search of the broader organization’s people directory.
- An organization’s community of practice initiative should have a clear definition of what success looks like for an individual community. CoP maturity models such as the two listed in the ‘For further reading’ below, and the next few points in this list, can be used to inform the definition of success. I like to think in terms of a “needs work”, “okay”, “good”, and “great” assessment at the various stages of a community’s evolution / maturity. All communities do not need to strive for the ultimate maturity. For example, in less strategic communities informal and self-supporting is fine indefinitely.
- I have found that a monthly cadence for community meetings is about right for most communities. For these meetings, all members, as well as guests, are invited. Initially, these meetings tend to be individuals or groups presenting what they are working on (or what they recently completed) related to the practice. Marketing, or other functions, might review upcoming events as part of the standing agenda. In all, the meetings are mostly “broadcast” communication. Then, as the community matures and the members become more comfortable with each other, discussion (and even debate) should become more frequent during the meetings. Also, with maturity, more outside speakers should be added to the meeting agenda.
- Also as a community matures it should begin to take on projects that increase the practice’s capabilities. For example, documenting leading practices and creating templates and toolkits.
- I have found that there is a sweet spot for the amount of support a community receives from a central organization such as a knowledge management function. Support staff can free community membership from administrative tasks such as logistics for community events and maintaining the community’s intranet presence. The support staff should also educate community leaders regarding CoP best practices. The support staff should never allow themselves to become the driver of the community, where the community would collapse if not for support staff taking charge. Community leadership must lead and if there isn’t sufficient interest from community membership, then the community should be allowed to die a natural death.
- There is another sweet spot between top-down intentional community formulation based on the organization’s strategic needs and bottom-up energy from the potential members for a particular community. In an ideal world, future community members are already reaching out to each other and sharing content and knowledge outside of the organization’s formal community program. The top-down chartering then acts as an accelerator by bringing in support staff and leadership support to help take the grass-roots community efforts to the next level of maturity.
- Related to the previous points, CoPs need active leadership from within the membership ranks. In addition to an overall leader, communities should consider forming a core team of five to ten individuals that are deeply committed to the success of the community. The core team and the community leader define community goals, set meeting agendas, and ensure that all questions related to the practice area obtain timely and complete answers. A representative from the support staff should also be a member of the core team. The core team will typically meet weekly for no more than 30 minutes to address any needs from the membership, review progress on initiatives, and plan future activities.
Compiling the above prompted me to think of many more points that I could cover. For Part-1, I’ll bring this to a close with the dozen above. I hope this initial brain-dump has provided some value to others leading communities of practices or CoP initiatives. I’d also love to add to my CoP knowledge by learning from your experiences.
Continue to Part 2.
For further reading:
- Want to manage tacit knowledge? Communities of practice offer a versatile solution, by Shawn Callahan. A nice six-page introduction to communities of practice.
- Cultivating Communities of Practice, by Etienne Wenger, Richard McDermott, and William M. Snyder (2002). Both this book and Leveraging Communities Practice after all these years are still solid introductions to communities of practice, and both remain on my bookshelf as references.
- Leveraging Communities of Practice for Strategic Advantage, by Hubert Saint-Onge and Debra Wallace (2003). Compared to Cultivating Communities of Practice, this book is 50% longer and more prescriptive in the details. The book includes many tables and example work products, e.g. for a community charter and for membership recruitment emails.
- Working Knowledge Community of Practice Maturity Model, by Bill Kaplan.
- Tacit’s Community of Practice Maturity Model, by Emily Webber. The model is from Emily’s Building Successful Communities of Practice, which I have not read yet other than the free sample available from Amazon.