Should selection of communities of practice be managed, or unmanaged?

Is the best approach to setting up and selecting Communities of Practice a managed one, or an unmanaged one?

There has always been a polarity of views between those who see Communities of Practice as something that should be allowed to flourish naturally and unmanaged, springing up as a bottom-up initiative in response to user demand, and those who see communities as more powerful when they are aligned with the business strategy, and managed from the top down to provide a valuable resource to their members.

In this top down selection , the company decides on strategic knowledge areas, and deliberately selects communities to support these, assigning leadership and core members and securing resources. This allows resources to be spent supporting the communities which will have most value to the company, but sometimes these top down communities may not align with the interests of the workers.

In contrast, in the bottom-up selection, the company enables the organizations with community tools, and watches for communities that form spontaneously around an area of business need. These CoPs are often high energy, but may not coincide with areas of knowledge which are strategic for the business. Also it is all too common to find multiple CoPs starting up which cover the same topic as each other, and communities that initially flourish then wither and die.

Given that we have two stakeholder groupings in KM (management and knowledge workers) and both need to be satisfied, and given that satisfying one without the other can lead to instability in your KM program, how do we choose which way to support our CoPs?

   

I think it is pretty well established that communities, once in place, need management, so long as it is self-management. A community without self-management may deteriorate into rancour or fandom (see  “a group is its own worst enemy“) or fade away (see “what happens when the facilitator is removed“). A community with too much management from above may also die (see “how over-management can kill a community“). The ideal is a light management from within – from a community leader and core group, and a self-determined community charter. 

I think it is also well-established that there are two stakeholder groupings for Communities of Practice – the community members who work in the practice area, and the management team responsible for the practice area. Therefore whether the selection of CoPs is managed or unmanaged, any CoP should ideally meet a need from the membership, and a need from the management. (see Siemens experience on the “customer trap” for KM).

That still leaves us with the question of the balance between managed and unmanaged selection of the portfolio of communities. 

Shell’s experience

Let’s look at some real experience. As part of a 2007 Linked-In discussion on “Communities of practice, limited or unlimited” (now no longer available), we have a useful story from Arjan van Unnik, who was head of Knowledge Management at Shell.

“In my experience the decision about “limited”or “unlimited” turned out to be an underestimated parameter … I managed a portfolio with some 35,000 users (no pre-registration – everybody personally requested membership for 1 or more communities).  ….Initially we carefully managed the CoP’s, based on skillpools. Than the step was made where everybody via the IT department could request a community. The fragmentation resulted in roughly 35% reduced activity in the communities. I had to implement corrective actions and increase the management of the portfolio.” 

 “One of the biggest breakthroughs was when we combined this unmanaged set of 100+ CoP’s into a managed set (15+ years ago, and violating all theories about CoP’s). Other companies that are successful in CoP’s (Fluor, Schlumberger) also manage their portfolio. I’ve heard about a company that did not manage their portfolio, ending up in more CoP’s than number of staff… Not managing the portfolio indeed implies the risk of ending up in a situation that again staff do not know which communities to join – we had that as well back in 1997, before we started to manage the portfolio”.

So Shell tried both approaches – managed and unmanaged. The switch from managed to unmanaged led to a reduction in activity, leading Shell to switch back again.