The Long Tail of experience in communiies of practice

Part of the value of communities of practice is proividing access to the Long Tail of experience

There is a tendency in many companies to see Knowledge as being the province of the Experts.

As a result, they set up expert centres to look after the knowledge, and expert networks to share knowledge between experts around the organisation.

However one of the big culture shifts within Knowledge Management is the recognition that Knowledge is the province of all Knowledge Workers, not just the experts. Expert networks will access only a small part of the knowledge of the organisation, the remainder  (the “Long Tail”) will be held by the non-expert Knowledge Workers.

Take the example shown in the graph here. The graph represents 50 workers within an organisation, with varying levels of experience from 30 years to 1 year. Initially the company decides that they will share knowledge by setting up a small network between the four experts – those with 15 or more years of experience (the red bars). Between them, these experts have 88 years of experience.

After a while, the company decides to replace the expert network with a full community of practice, where all 50 of the knowledge workers take an active role. The total years of experience within the community is now 274 – more than three times the experience than that held by the experts alone.

The value of this added experience comes when it is applied to knowledge in the work context. Knowledge is contextual – the application of knowledge changes on where it is applied, and when, and to what. The larger community has seen many more contexts, and the person who gives the advice is not necessarily the person with the longest experience, but the person with the most relevant context. Maybe that person has only been in the company a year or two, but if they have had relevant experience within that short time, they can answer the question, offer the advice, and add real value.

This is the concept of the long tail of knowledge.

The “long tail” is a term that has has gained popularity in recent times as describing the retailing strategy of selling a large number of unique items with relatively small quantities sold of each – usually in addition to selling fewer popular items in large quantities. The long tail of knowledge is a knowledge sharing strategy of offering a huge amount of knowledge transfer opportunities, with relatively small numbers of each particular question/answer exchange. It allows niche knowledge to be sought and found, provided the community of practice is large enough and broad enough.

Large online communities of practice allow access to the Long Tail.

Small expert groups access only the short head.

View Original Source (nickmilton.com) Here.

Why is a Charter so important to a Community of Practice?

One of the most important elements for a successful community of practice is the Charter. But why is this?

Setting up an online Community of Practice can sometimes feel like going out to sea in an open boat. You are never sure what is going to happen. There are lots of unseen forces out there. All will be well if things are calm, but what if things get stormy? How will you cope with bad behaviour, or with apathy? Will you, and the community, become overwhelmed, or swamped?

These are valid worries. As I explained in this post, there is something about online dynamics that means that sooner or later, things will start to degenerate, and conversation becomes trivial, argumentative, entrenched or off-topic to an extent that the community cannot deliver its purpose. This is where the Charter comes in.

Our KM surveys identified the community charter as one of the items that made most difference to the effectiveness of a CoP (see chart above).  When group dynamics start to degenerate, the CoP leader can use the charter as a reference point and a definition of the agreed ways of working in the CoP – the unofficial “rules of engagement” if you like. It can be used as a reminder of how the CoP members collectively decided how they want to work together, and as a touchstone for community culture.

So some of the early activities you need to set up to safeguard the life of the community are as follows:

1) Agree a charter, or “rules of engagement”. This should cover the aims and objectives for the community, the roles and processes that will be employed, and also the behaviours the community members expect of each other. The great things about the charter are that firstly the new community members are clear about “what they are joining”, and secondly the community sets boundaries so that it is clear when people stray beyond them. The charter should be a foundational document for any community, and it acts as a shield against things going wrong.

2) Appoint a facilitator, or moderator. This person is appointed by the community, to help it run well. The facilitator is not a dictator, nor a policeman, and is the oil in the community wheels, and the social energy source for the community. However if serious trouble arises (flame wars, insults, spam, persistent off-topic material) the facilitator is the person who deals with it on behalf of the community; initially by reminding the offender of the charter, and at a last resort removing offending posts or even asking the offender to leave the community.

3) Regularly revisit the charter, and check that the community is working well, and adding value to the members. If the charter needs tweaking, then call a meeting of the community to rewrite it, or conduct an online discussion.

View Original Source (nickmilton.com) Here.

The heart and soul of a Community of Practice

What makes a group of people into a Community of Practice?

Recently I read a document which asserted that the employees within an organisation are naturally a community of practice, because they all work together in service of the same organisational goal.

That immediately struck me as wrong, but why was it wrong?

Certainly the employees fall under Wenger’s definition of a Community of Practice – namely “groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly.” Employees in a company may be passionate about what they do, they may learn to do it better, and they may interact regularly with each other as part of their work. But for me, this alone is not enough for them to be a community of practice.

The extra point that is needed, is a sense of group identity based around practice.  

The members of a community of practice identify with the domain of practice, and therefore with the other practitioners. They talk about “we” when they talk about practitioners in the knowledge domain. That’s a different “we” from “we who work for this company”- its “We, the engineers”, “We, the geologists” and “We, the admin assisitants”.

This sense of identity needs to be supported by interactions that are specifically about the domain. Even if you say “we, the engineers”, there is not necessarily a community of practice of engineers unless there is an interaction among that engineering community, related to the practice of engineering, and concerned with engineering issues. The interactions, these conversations about engineering, make the community a reality.

So the employees within an organisation are not naturally a community of practice, until they develop a sense of identity around a domain, and interact within each other to discuss and improve their practice withuin that domain. Without these two factors, they remain individual contributors, reliant on their own knowledge.

Of course there is more to being successful as a CoP than just identity and interaction (see my post on the 10 success factors for CoPs), but interaction and identity are the heart and soul.

View Original Source (nickmilton.com) Here.

4 ways in which communities of practice can be embedded

Here is a really interesting article about the ways in which Communities of Practice can be embedded in an organisation

Coins embedded in a tree @ Longshaw Estate, DerbyshireThe article is  about the management of Networks of Practice  in the development sector, and how to draw the balance between managing them too much, or too little.

The authors (Marlous Agterberg, Bart van den Hooff, Marleen Huysman and Maura Soekijad from the University of Amsterdam) come up with an interesting model, where they recognised four forms of “Embeddedness” which they believe are important to the effective operation of these networks. They describe these as follows

  • Organizational embeddedness: the extent to which the knowledge shared in the network is relevant for and integrated in the formal organization. Further divided  as follows
    • Institutionalization – the extent to which outcomes of the network can be applied in the formal organization as rules, routines, strategies, etc
    • Relevance for organization Extent to which knowledge sharing in the network is considered valuable for the organization
  •  Embeddedness in practice: the extent to which the knowledge shared in the network is relevant for and integrated in the  local and daily practices of network members. Further divided into 
    • Relevance to practice – Extent to which knowledge sharing in the network is immersed in the daily local practices of members ‘
    • Common practices – Extent to which the network members use the same practices
  •  Relational embeddedness: the extent to which the network is embedded in the social ties  and elements such as trust, mutual expectations, and identification. Further divided into 
    • Group feeling – Extent to which members feel they belong to the same group 
    • Trust –  Feelings of safety and trust in the network 
    •  Reciprocity – Willingness of network members to help other members
    • Face-to-face contact – Amount and possibilities of face-to-face contacts among network members
  • Structural embeddedness: the extent to which network members are connected to one another and know who knows what and how to reach them. Further divided into 
    • Connectedness – Extent to which members are connected to one another
    • Know who is where and knows what – Extent to which members know who knows what in the network and how to reach these people

These are all very interesting, and should be considered when setting up, running or managing communities of practice.

View Original Source (nickmilton.com) Here.

An unmoderated community is its own worst enemy

Here is a very interesting talk, by Clay Shirky, the writer on Internet Technologies and Society

Public Enemy In the talk, he points out that over the history of online collaborative groups using social software, there is a predictable pattern which emerges time after time in open unmoderated groups, namely that the behaviour of the group will (if unchecked) subvert the purpose of the group.

He mentions three behaviours;

the first is that the group will move away from chatting about the purpose of the group, to online jokey, rowdy or flirtatious behaviour.

The second is that the group will move away from chatting about the purpose of the group, to ranting about a “common enemy”.

The third is that the group will select a person or a document or principle to “venerate” to the point where it becomes unchallengeable. The second and the third are, I think, the reasons behind the silo mentality that creeps into online groups.

What happens as a result of these tendencies, is that the conversation becomes trivial, entrenched or off-topic to an extent that the group cannot deliver its purpose. Either the group is shut down, or stays at a trival or entrenched level, or else it develops a system of internal governance, such as a moderator, tiers of contribution, a constitution or a charter. This system of internal governance will act to protect the aims of the group from the behaviours of the individuals (the groups “own worst enemy”) and is generally the only chance for survival of the group.

Clay’s point is that you cannot separate the social issues within the group from the technological issues. The technology becomes a new playground on which the old battles are fought. And yet he says that time-and-again organisations will introduce a new technology, expect certain behaviours to emerge as a result, and be surprised and frustrated by the fact that “the users don’t behave like they should”.

He concludes three things

  1. As you cant separate the social from the technical issues, then ensure the group addresses the social issues from the start. This is where the bedrocks of Communities of Practice come in – the facilitator moderator, the community charter, the behaviour ground-rules.
  2. There will always be a core group. Clay calls these “members” as opposed to “users”, and they are the people who care about the purpose of the group.
  3. The core group has rights that trump the rights of the individual. Generally it is the core group that writes and “enforces” the charter.

I think this is an excellent reminder NOT to just introduce a social technology and “expect knowledge to be shared”. History has shown, time and again, that this does not happen.

Instead you need to plan for the social dynamics, operate the group as a community of practice, appoint a core team from the start, and a leader, and develop a charter that sets the purpose of the group, and lays out some ground rules to protect the group from its own worst enemy – itself.

View Original Source (nickmilton.com) Here.

Analysing questions and answers in communities of practice

Analysis of search trends is common in KM – and you can use a similar approach to analyse community questions and answers.

Many organisations analyse internal searches of their Intranet or Knowledge Base, using tools similar to Google Analytics to find out what peopele are searching for, and what they find through those searches.

However your Intranet search engine is not the only tool for finding knowledge – manage aorganisations also use question and answer forums in their communities of practice.

We tried a similar approach of analysing queries in a big online community of practice recently. The queries to the community forum were already characterised into topics, because when you submit a search to this particular community of practice you have to choose which topic it is related to. So that saved us having to assign categories.

We divided these topics into four quadrants;

1. Topic categories where there were few questions, but each one got lots of answers. These tended to be areas of common knowledge, where most people knew the answer and only a few new people did not. For these topics, we could write guidelines or faqs for the benefit of the new staff

2. Lots of questions, lots of answers. These were the important and evolving Knowledge topics where it was worth while setting up community meetings so that we could start to exchange and document best practice (maybe a knowledge exchange, maybe a knowledge market).

3. Lots of questions, few answers. These were the problem areas, where some more research or action learning was needed to start to develop solutions.

4. Few questions, few answers. Our assumption was that these are not particularly important areas, but that it was worth watching them in case they developed into problem areas.

This was a very useful analysis and led to a greater understanding of the important evolving and problem topics within the community, as well as helping to suggest some community activities in order to improve their knowledge.

View Original Source (nickmilton.com) Here.

Sites don’t build communities; communities build sites

It takes more than a SharePoint site to build a Community of Practice.

Image from wikimedia commons

Not for the first time, we recently ran a Knowledge Management  Assessment for an organisaton which claimed to “have lots of communities of practice”. When we pressed her a little more to find out what she meant by this term, we found that for her, a Community of Practice is a SharePoint site with a list of contributors, a blog, and a wiki. Then when we went online to look at these “communities”, the vast majority were entirely empty. Quite silent. No activity at all.

It takes far more than a SharePoint site to build a Community.

The key is in the word Community. Community is a feeling – it is a feeling of having something in common. It is a feeling of trust and of loyalty. Communities of practice deliver value in organisations because they set up structures of dual loyalty. A community member is loyal to their work team, but also loyal to their community, and this loyalty and trust is what enables the communities to be a conduit of knowledge between one work team and another.  The site is a tool they use to support the sense and feeling of community, not something that creates this feeling.

Providing a set of community tools and expecting community behaviours to emerge is a variant of the “Build it and they will come” argument. It’s like building a village hall in sectarian Northern Ireland, and expecting a multi-sect community to develop.  For many organisations, there are internal divisions and silo walls to overcome before anyone even thinks about sharing knowledge with each other.

They key is to build the community first, often through hard work and much face-to-face interaction,  and let them build the hall. Or the website/blog/wiki/whatever.  The community builds their own site.

Below is the vision I like to offer to communities of practice when it comes to building and populating their site. This is not something you do for the community, it is something the community does for itself.

Provide lots of sites, and you just end up with empty sites. Provide a sense of community, and the site will be built.

View Original Source (nickmilton.com) Here.

Communities of Pratice at World Vision

I blogged recently about the evolution of Communities of Pratice at Shell, and how they moved from free-for-all to a more managed approach. Here is a similar evolution at World Vision.

Image from Wikimedia commons

The decision between a managed approach to communities and an unmanaged bottom-up approach is an important one. Early in the history of the topic, the unmanaged approach seemed the default, but watching the evolution of communities, it seems that this is not necessarily the best way. I have already blogged about how Shell switched their approach from managed to unmanaged, found it resulted in a drop-off in community activity, and went back to a managed approach, Here is a similar story from the charity World Vision.

The story was presented by Jack Merklein at KM Australia last month, and you can find Jack’s PowerPoints here (thanks to my colleague Ian Fry for notifying me of this story).

Jack sees Communities of Practice as fundamental to World Vision’s KM program, and a “force multiplier” for the organisation.  At the moment World Vision has 27 communities of practice organised on a voluntary bottom-up basis, with largely part time support, and over a hundred voluntary interest groups. They are finding this approach less than optimal, with a lack of guidance and training for the CoP coordinators, resulting in inefficiencies and limited learning.

They plan to move to a managed approach.

Under the new approach they plan the following

  • Each of World Vision’s 5 sectors of operation will have no more than two CoPs each – ten in total 
  • Each CoP must first be justified by a business case and have a KM Manager overseeing the CoP
  • The interest groups will be put on hold, and replaced by a focus on centres of competency 
  • A KM/CoP advisory committee will meet to set direction for KM/CoP strategy for the Partnership 
  • Business management of World Vision’s intranet, which hosts the CoPs, will transition to the KM team

The plan is underway, and one of the next steps is development of a Knowledge Management strategy aligned with the mission and objectives of World Vision, which guide the CoP Business Case implementation and other policies/procedures for CoPs

We will watch the development of CoPs at World Vision with interest.

View Original Source (nickmilton.com) Here.

Communities of practice – managed or unmanaged?

Is the best approach to 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 contract, 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?

Shell’s experience

Let’s look at some real experience. As part of a Linked-In discussion on “Communities of practice, limited or unlimited”, 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.” 

 “1 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.

View Original Source (nickmilton.com) Here.

Skip to toolbar