Skip to content →

Reflecting on Communities of Practice – Part 2

This blog is a continuation of my Part 1 reflection on communities of practice (CoP). I continue here with 7 additional points.

a cluster of wood chess pawn in various colors

Here goes…

  1. There are many tactics for identifying members to seed a new community. These include:
    • Solicit members via existing newsletters, distribution lists, and any related communities.
    • Advertise “coming soon” on any existing intranet sites or pages related to the community topic.
    • If the company has a people directory with the required capability, search for employees who list the community topic as one of their interests or skills.
    • Identify employees who write about the community topic on internal (e.g. Yammer) or external (e.g. Twitter or LinkedIn) social media.
    • Check project records for employees staffed on any company projects related to the community topic.
    • Target membership in any related departments or teams.
    • Check if any employees are members of related professional societies.
    • For communities based on role (e.g. project managers), use the Human Resources (HR) system to identify employees who serve in the targeted role.
    • If the company has Social Network Analysis (SNA) capability, use the network analysis to identify employees connected with previously identified candidates.
    • Ask each person that joins the community for their recommendation of whom else to invite.
    • One of the most successful communities that I supported was conceived at a face-to-face meeting during an international conference. Many of the company’s employees attended the conference from around the world and most either didn’t know each other or had never met in person. Someone had the good sense to arrange a break-out session, open only to the company’s employees, during the conference. At the close of the meeting, there was a groundswell of interest to keep in touch and to continue learning from each other. As a member of the support staff, I received an email the next day that requested my support to stand-up a new community with the initial membership being those that attended the conference.

  2. When developing a new community, one important set of decisions relate to how open the community will be. Points for discussion include:
    • Does joining the community require approval? In general, consistent with my diversity point #4 in Part 1, the answer should be ‘no’. What I have, however, used with positive results is a simple required online form, where the form is similar to what is used for many public Facebook and LinkedIn groups. The form is an opportunity to learn about the new member’s interests, expectations, and what expertise they might have to offer the community. Anyone that completes the form becomes a member automatically…no further approval required.
    • Will the community support a social media channel that is visible to all employees? In general, I am a proponent for this. If the company is using the Microsoft suite, the visible-to-all-channel could be a ‘public’ Yammer group. The community can then also host a private Microsoft Teams site. This combination allows for non-members to ask questions related to the community topic and the visible-to-all page also serves as a membership recruitment tool.
  3. It is important to periodically (typically quarterly or biannually) survey the community members to obtain feedback on how the community is doing relative its mission, goals, and (most importantly) providing value to the membership. The survey can also be used to identify speakers or topics for future community meetings, identify community success stories, and to ask for additional volunteers to help run the community.
  4. The support team should maintain a comprehensive online list of all known communities. The list should include columns for community description, community type, maturity level, leader name(s), and a link to the community’s online presence or a form to join the community. Listing communities in development is another way to attract founding members as covered in point #13 above.
  5. I’ve occasionally seen some tension between local communities and company-wide communities on the same topic. The typical scenario where I have hit this is when one or more local communities emerged from grass-roots interest on a topic. Then, at a later date, there is a “corporate” initiative to build a community on the same topic. If the transition isn’t handled carefully, the local communities can feel “taken over”, or threatened, by the broader company-wide initiative. This risk can be mitigated by maximally seeking input from the local communities leading up to the launch of the company-wide community. The aim is to have the existing communities feel like they are seeding and guiding the company-wide effort, and gaining strength from connection with a larger and more diverse membership, contrast to being taken over. As a vision for the desired end-state, I use a model of a professional society where there is the International parent group and then many, largely autonomous, individual chapters.
  6. Similarly, I have experienced tension when someone wants to start a new community that is dedicated to a topic that is nearly the same as an existing community. Stan Garfield extensively discusses this in To control or not to: only you can prevent redundant communities.
  7. In Part 1, I advocated for a support group that takes up some of the administrate workload and educates the community leader and core team regarding CoP leading practice. Another tension I have experienced is the support team being perceived as bureaucracy that slows down community development, contrast to a valuable facilitator and partner. Some of the ways support teams can slip into bureaucracy include:
    • Requiring lengthy forms and approvals before granting a “green light” to proceed with community development
    • Delays in assigning someone from the support team to support the emerging community
    • A perceived “heavy hand” relative to the policing to avoid duplicate communities (reference point #18 above)
    • A perceived “heavy hand” relative to demanding openness (reference point #14 above)
    • An excessively long and dry community guidebook that leader and core team are expected to read
    • Not deeply listening for the underlying needs of the community leadership

When the support team is perceived as a roadblock, there is a risk of emerging communities going underground and off the radar. This “hiding from corporate” can lead to using unapproved software tools and limiting the potential value to the broader organization from the community.

That’s all for Part 2. Part 3 is already starting to percolate. We’ll see.

More further reading

Published in Knowledge Management Portfolio


Leave a Reply

Your email address will not be published. Required fields are marked *