Why asking for knowledge contributions is so important.

One of David Snowden's principles is that "Knowledge can't be conscripted, it can only be volunteered". However waiting passively for voluntary contributions is the wrong way to spread knowledge. Ask for volunteers instead.

I Know The Answer!
Originally uploaded by ngader

Knowledge can't be conscripted, it can only be volunteered, and often it won't be volunteered until someone asks for it.

This is an outcome of the problem of the Unknown Knowns. Often people don't don't realise they have learned something, until they are asked about it, or have the chance to discuss it.

Sometimes you find organisations who have set up a system whereby people are required to identify new knowledge themselves, and then to add it into a knowledge repository. The system effectively says "if you have learned something, please share it here". 

I am not a huge fan of volunteer systems like this; I don't even like them for collecting innovation suggestions. I think you capture only a small proportion of the knowledge this way, because people are often not aware that they have learned anything, and if they are aware, they often discount the learning as "not important". Also, self-written knowledge is often superficial, because there hasn't been the depth of dialogue and questioning to get to the root lesson.

I am not arguing for forcing people to share knowledge, but I am suggesting that you don't wait for the volunteers to come to you. Instead you give people question-based opportunities where they are prompted to become aware of what they know, and which provide a safe and encouraging environment for them to share it. This is a different sort of system, where people are asked what knowledge they have to offer. 

There are three main approaches for doing this; reactive, scheduled, and point-of-need.

The reactive approach requires someone to identify particular successes and failures from which to learn. The failures can be obvious, such as HSE incidents or significant project overruns, and many companies have mandatory processes for reviewing these failures. But how do you spot the successes? This is where you can become more proactive. 

 Maybe you can use your company benchmark metrics, and pick the best performing units for review. Perhaps you could work with the knowledge from the manufacturing plant that never had an accident, as well as from the one with frequent accidents. Maybe you can look for the best sales team, and look to learn the secrets of their success. Or maybe you can do both successes and failures - I did a very interesting study not long ago for an organisation that measures staff engagement using the Gallup survey. We picked the ten top scoring sales teams, the ten bottom scoring teams and the ten teams which had shown the most improvement over the previous year, and interviewed the team leader and a team member from each one, so they could share the secrets of successful staff engagement.

Another organisation we have worked with uses global consultants and Technical Directors to identify opportunities for learning and knowledge transfer. They travel the world, reviewing activity at different centres, and will identify good practice which needs to be repeated, as well as opportunities to learn from mistakes. They then ask the local team how they achieved their success, and what knowledge they can share with others. 

An alternative approach, common within project-based organisations, is to schedule learning reviews and knowledge exchange within the activity framework. Each of these reviews involves asking the team to voluntarily share what they have learned.  These reviews could be

• After Action Reviews on a daily basis during high-intensity learning, or after each significant task 
• Peer Assists early in each project stage, or during project set-up
• Retrospects (or some other form of Post Project review) at the end of each project stage, or at each project review gate
• A Knowledge Handover meeting at the end of a project, to discuss new knowledge with other projects
• A Technical Limit meeting during the detailed planning stage, to bring in knowledge from people with detailed experience
• A Retrospect (or some other form of review) at the end of a bid process, when the company knows if the bid has been successful or unsuccessful.

There are many advantages to the scheduled approach. Firstly, success and failure are components of every project, and if every project is reviewed, lessons may be identified which can avoid the big mistakes later on. Secondly, if lessons identification is scheduled, it becomes a clear expectation, and the company can monitor if the expectation is being met. This expectation is common in many organisations, thought the rigour with which the expectation is met seems to vary. Finally, by scheduling and facilitating the learning dialogue, you can uncover the knowledge that nobody knows they know, until they start to discuss it.

The final approach is the point-of-need approach. This is where someone realises they need knowledge, and the ask the relevant community of practice for help. This is often a very effective way to transfer knowledge, and represents a "just in time" rather than a "just in case" approach. It can be run in parallel with the scheduled knowledge discussions mentioned above.  A McKinsey study I reference here claimed that direct requests for help between colleagues drive 75 to 90 percent of all the help exchanged within organizations.

So don't rely on people volunteering their knowledge spontaneously - instead set up scheduled processes which provide a request and a context for volunteering. Ask for volunteers - that's the way knowledge gets shared.

8 demand-side principles for Knowledge Management

In 2008 David Snowden published a landmark article on 7 KM principle, mainly focusing on the supply side of knowledge management. The post below, upcycled from 2012, aims to present similar principles from the demand side. 

Principles by Nick Youngson 
CC BY-SA 3.0
 Alpha Stock Images

David's 2008 post is currently (Nov 2020) unavailable, but his principles are as follows:

1. Knowledge can only be volunteered it cannot be conscripted. 
2. We only know what we know when we need to know it.
3. In the context of real need few people will withhold their knowledge.
4. Everything is fragmented. We evolved to handle unstructured fragmented fine granularity information objects, not highly structured documents.
5. Tolerated failure imprints learning better than success.
6. The way we know things is not the way we report we know things.
7. We always know more than we can say, and we will always say more than we can write down.

All except number 5 addresses the expression and presentation of knowledge.  There is of course another side - the demand side, or the user side - which represents the transition from expressed knowledge to conscious understanding and to unconscious knowing. Here I offer a set of principles which apply to the other side of the equation - the learning side

These principles are based on our own experience in Knoco, and there is some overlap with the established “principles of learning” used in the educational field.

Here are our principles

1. People don’t pay attention to knowledge until they actually need it. People won’t  absorb knowledge until they are ready, and they won’t be ready until they feel the need.  I could give you detailed driving instructions of the quickest way to travel from Bath in Somerset to Woking in Surrey, but you wouldn’t retain them because they are of no immediate value to you. Then one day, you are at a garden party in Bath and your boss calls and says “can you get to Woking as quickly as possible, we have a potential big deal to close and I need you here right now”. THEN you will be highly receptive to the knowledge. The consequence of this "attention when needed" is that it is more effective to set up “just in time” knowledge sharing processes than “just in case” knowledge sharing processes (although these also have their place).

2. People value knowledge that they request more highly than knowledge that is unsolicited.  I don’t know the psychology behind this, but it seems to be true.  The best way to get knowledge into people’s heads seems to be by answering their questions. The old fashioned “show and tell” is far less effective than “question and answer”, and the blog is less effective than the discussion forum.  The company where the most questions are asked, is often the company that learns the quickest.  This principle is behind the design of most effective knowledge management processes, the majority of which are based on dialogue, and the primary focus of communities of practice should be answering questions rather than publishing ideas.

3. People won’t use knowledge, unless they trust its provenance.This is the “not invented here” principle, which is a very strong factor in knowledge management terms.  People won’t use knowledge they don’t trust, and they don’t trust knowledge if they don’t know where it has come from.  They need either to trust the individual who gave them the knowledge, or the organisational construct (such as the CoP) which provided the knowledge.  The source may be an expert, or a wiki (many people trust Wikipedia for example, despite its shortcomings), or a community of practice, and building credibility and trust has to be a key activity when building these constructs as part of the knowledge management initiative.

4. Knowledge has to be reviewed in the user’s own context before it can be received.  One of the knowledge receiver’s first questions is “is this relevant to me?” Everybody always feels their own context is different (even though the difference is often less than assumed), and they need to test the knowledge for relevance before they really pay attention.  We were recently facilitating a peer assist, where people were bringing knowledge from Africa, from India, from China, to be used in an Indonesian context.  For each of the learning points, we needed about half an hour to an hour’s discussion around context, before we could even approach discussion of how imported knowledge might be used. This means that transferring knowledge in a written form is difficult, unless you can introduce a process by which people can interrogate this within their own context.

5. One of the biggest barriers to accepting new knowledge is old knowledge.  This is the curse of prior knowledge. People have to unlearn, before they can learn.  Old assumptions, old habits, “the way we have always done it in the past” may all have to be challenged before people can absorb and make sense of new knowledge.  This can be hard work! As an example, see the story about the war of the hedgerows, where the U.S. Army completely missed the implication of the Normandy hedgerows, assuming they would not be a factor in tank and infantry warfare after the D day landings

6. Knowledge has to be adapted before it can be adopted.  If people are provided with guidance, tips and hints, or even a “recipe to follow,” they will always tweak it and adjust it in order to “make it theirs”.  Sometimes this tweaking and adjusting is necessary to fit the knowledge to their own context; sometimes it is unnecessary in practical terms despite being necessary in emotional terms.  So when you are providing people with guidance, tips and hints or even a “recipe”, you have to give them some idea of where they can still adapt it, and where dangerous tinkering should be avoided. Otherwise they may "adapt" the wrong thing. We see this all the time in our Bird island exercise - they all want to tinker with the final design, and you have to let them tinker, but try to guide them to tinker in non-fatal ways!

7. Knowledge will be more effective the more personal it is.  The more personal, emotional, and highly charged the learning situation, the more the knowledge will be easily adopted.  Discussion, story telling and coaching can be personal, and motional and highly charged, but it becomes difficult to translate this into the written word.  The use of stories is very helpful, the use of video even more so.  Obviously this has profound implications for knowledge transfer mechanisms.

8. You won’t really KNOW it until you DO it.  We very often see in lessons learned meetings, teams that say  “we picked up this learning from the previous project, we tried it and it really did work!  That was a great learning for us”.  When they picked it up they knew it intellectually; after they had tried it they knew it practically and emotionally.  Seeing is believing, trying is trusting, doing is internalising.  This sort of positive reinforcement of learning is a massive boost for your knowledge management program; as people try things and find they work, this reinforces the belief that knowledge from others is of real practical value.

How collaboration can simplify

Collaboration adds simplicity in a complicated world. 

Simplifying through collaboration is the topic of a Ted talk by Yves Morieux, embedded below, in which he gives us 6 rules to simplify work. Watch the talk to get the context, but here are his 6 rules (with more explanation here)

1. Ensure people in the organisation full understand what others really do. 
2. Look for cooperation - reinforce managers as integrators, by removing layers so that managers are closer to the real work. 
3. Empower everybody to use their judgement and intelligence. 
4. Create tight feedback loops that expose people to the consequences of their actions. 
5. Increase reciprocity, by removing the buffers that make us self-sufficient.
6. Reward those who cooperate and blame or sanction those who don't cooperate. 

Do these sound familiar? Rules 1,2,4,5 and 6 are all components of Knowledge Management, and Knowledge Management is needed to support Rule 3. Yves is not reinventing KM, but showing how a knowledge enabled, connected and collaborative organisation is like an adaptive nervous system rather than a rigid skeleton of roles and structures.

Yves explains that as these 6 rules are brought into play, organisations begin to be able to manage complexity not through adding more and more complex structures and requirements, but by allowing people to take ownership of issues and sort them out together, rather than passing them on to someone else.

Yves finishes his talk by explaining how CEOs can help support the 6 rules of complexity, and gives us this story, which should resonate with all KM practitioners

The CEO of The Lego Group, Jorgen Vig Knudstorp, says, blame is not for failure, it is for failing to help or ask for help. This changes everything. Suddenly it becomes in my interest to be transparent on my real weaknesses, because I know I will not be blamed if I fail, but if I fail to help or ask for help.

This is very similar to Elon Musk's email to his staff. Both give the vision of an organisation empowered and obliged to seek knowledge from wherever it may be found. And this is the basis of Knowledge Management. 

The Asker/Helper culture - why these are the core behaviours of KM

A recent McKinsey article, if you read it carefully, suggests that the core KM behaviours for group effectiveness are Asking and Responding.

The McKinsey article entitled Givers take all: The hidden dimension of corporate culture is a really interesting article, describing a study by Harvard psychologists of the US intelligence system in order to determine what makes intelligence units effective. By surveying, interviewing, and observing hundreds of analysts across 64 different intelligence groups, the researchers ranked those units from best to worst, and looked at what made the best ones so good.

Conclusions of the study are as follows:

• The single strongest predictor of group effectiveness was the amount of help that analysts gave to each other.

• Across these diverse contexts, organizations benefit when employees freely contribute their knowledge and skills to others (what McKinsey refers to as a Giver culture, where knowledge is freely shared, in contrast to a Taker culture, where it isn't)

• Giver cultures depend on employees making requests; otherwise, it’s difficult to figure out who needs help and what to give. In fact, studies reviewed by psychologists Stella Anderson and Larry Williams show that direct requests for help between colleagues drive 75 to 90 percent of all the help exchanged within organizations.

So in fact the single strongest predictor of group effectiveness is the amount of "asking for help" that happens, and the Giving/Helping response. So it would be more accurate to talk about an Asker/Helper culture rather than a Giver culture.

It is possible to develop an Asker/Helper culture - the article talks about an exercise called a Reciprocity Ring, which is a face to face version of the Question-driven communities of practice we see operating so successfully as part of mature knowledge management programs. Peer Assist is the archetypal Asker process, which always generates a Giver response. Many of the standard Knowledge Management interventions act as culture change agents in their own right to promote the behaviours of asking and of giving.

So if you are interested in creating the KM culture which is "the single strongest predictor of group effectiveness" - remember that knowledge sharing is 75% to 90% of the time a response to Asking.

Aim for the Asker/Helper culture (as I suggest in this video).

Feedback loops in the Knowledge cycle

Last week I described a "Pull cycle" for knowledge - let's now look at the feedback loops in that cycle.

You can find description of the cycle here. This is a cycle based on knowledge demand (unlike the supply-side cycles you normally see) and includes the following steps;

• The cycle starts with a problem, and the identification of the need for knowledge to solve the problem (the "need to know")
• The first step is to seek for that knowledge - to search online, and to ask others
• Seeking/asking is followed by finding
• However generally we tend to "over-find". Unless we are lucky, or there is a very good KM system, we find more than we need, so the next step is to review the results and select those which seem most relevant in the context of the problem.
• This found knowledge then needs to be integrated into what is already known about the problem, and integrated into solutions, approaches, procedures and plans.
• Finally the integrated knowledge needs to be applied to the problem.

In the picture above, I have added the monitoring and feedback loops to each step, which work like this:

• After the behaviour of asking/seeking, you feedback firstly whether there was any asking/seeking (so the organisation can track the behaviours of knowledge seeking) and you monitor and feed back the topics that people are asking about or searching for. You can for example analyse questions in a community of practice, or queries to a helpdesk, and you can analyse search terms from the corporate search engine logs. These will give you some ideas of the knowledge needs in the organisation, which knowledge supply has to match. 

• After the finding step you feedback whether  you found the knowledge you needed, or not. This feedback will help identify gaps in the knowledge base where the knowledge needs are not being met, and can trigger the creation of new knowledge assets of articles.
• After the review step you feed back whether the knowledge was relevant or not. In reality this feedback will be merged with the previous step. 

• After the Integration step you feed back on the quality of the knowledge you found. This feedback will identify knowledge assets or knowledge articles which need to be updated.

• After the Apply step, you feed back whether the knowledge was actually applied. This will help identify the most applicable and useful knowledge assets and articles. 

• Finally, after the problem solution step, you feed back how much difference the knowledge made, and how much value was realised through problem solution. This allows you to track the value of the entire pull cycle and the entire knowledge management framework. 

Many of these monitoring and feedback loops are well developed in the customer-focused KM approaches such as KCS (Knowledge Centred Support), but any KM approach can apply these as part of their own KM metrics framework.

It is through the feedback associated with the steps that you can tell whether KM is actually working.

"You are obligated to ask" - Elon Musk's email

Even in the most progressive organisations, sometimes the boss needs to drive a "culture of asking." Here is how Elon Musk did it.

Image from wikimedia commons

Musk's email is quoted here, and seems to have been sent in response to a dissatisfaction with default communication and knowledge sharing habits at Tesla.

There are 6 things I want to point out regarding this email, which I have highlighted in the text of the email

below.

1. Musk is setting the expectation for lateral communication and knowledge flow, rather than the vertical communication seen in many other organisations (which I describe as knowledge hedge-hopping).
2. He makes his expectation very clear, and backs it up by spelling out the consequences ("Any manager who allows this to happen, let alone encourages it, will soon find themselves working at another company").
3. He places this expectation in the context of problem-solving and asking for help ("Anyone at Tesla can and should email/talk to anyone else according to what they think is the fastest way to solve a problem for the benefit of the whole company"). Musk is looking to drive a culture of "open asking".
4. He makes this expectation very eplicit. It is not a request, it is an obligation.
5. He separates out this behaviour of problem-driven asking from "random chit-chat", and sees it as key to competitiveness.
6. He recognises that the default "hedge-hopper KM" behaviour is driven by a natural human tendencies which needs to be "fought" in support of the corporate good.

Here is the email quoted in the link above (the text in bold below was highlighted by me, not by Elon Musk)

Subject: Communication Within Tesla 

There are two schools of thought about how information should flow within companies. By far the most common way is chain of command, which means that you always flow communication through your manager. The problem with this approach is that, while it serves to enhance the power of the manager, it fails to serve the company. 

Instead of a problem getting solved quickly, where a person in one dept talks to a person in another dept and makes the right thing happen, people are forced to talk to their manager who talks to their manager who talks to the manager in the other dept who talks to someone on his team. Then the info has to flow back the other way again. This is incredibly dumb. Any manager who allows this to happen, let alone encourages it, will soon find themselves working at another company. No kidding. 

Anyone at Tesla can and should email/talk to anyone else according to what they think is the fastest way to solve a problem for the benefit of the whole company. You can talk to your manager's manager without his permission, you can talk directly to a VP in another dept, you can talk to me, you can talk to anyone without anyone else's permission. Moreover, you should consider yourself obligated to do so until the right thing happens. The point here is not random chitchat, but rather ensuring that we execute ultra-fast and well. We obviously cannot compete with the big car companies in size, so we must do so with intelligence and agility. 

One final point is that managers should work hard to ensure that they are not creating silos within the company that create an us vs. them mentality or impede communication in any way. This is unfortunately a natural tendency and needs to be actively fought. How can it possibly help Tesla for depts to erect barriers between themselves or see their success as relative within the company instead of collective? We are all in the same boat. Always view yourself as working for the good of the company and never your dept. 

Thanks, Elon

The knowledge cycle as you have never seen it before

We are used to seeing pictures of knowledge cycles, but there is one cycle you never see, and it's very important.

You can find very many versions of the knowledge cycle, and they all seem to work the same way.

They start with "Create" or "Capture", and progress through "Store", "Share" etc until they get to "Use" or "Apply. Some have as few as 3 steps, some have 8 or more steps, and the 4-step basic has even made it into the Stock Photo collections. However all these cycles work in the same way, as all of them are "Push" cycles.

By "Push Cycle" I mean a cycle that is driven by knowledge supply, and describes how that supply of knowledge works through various stages until the knowledge is used again. It is a supply chain model, and people use the cycle to put in place roles and processes to move knowledge along the steps in the supply chain.

However Supply is only half the story, and you need to look at Demand as well.

The diagram shown here is a cycle driven by knowledge demand - a "Pull cycle" - and it works like this.

• The cycle starts with a problem, and the identification of the need for knowledge to solve the problem (the "need to know")
• The first step is to seek for that knowledge - to search online, and to ask others
• Seeking/asking is followed by finding
• However generally we tend to "over-find". Unless we are lucky, or there is a very good KM system, we fInd more than we need, so the next step is to review the results and select those which seem most relevant in the context of the problem.
• This found knowledge then needs to be integrated into what is already known about the problem, and integrated into solutions, approaches, procedures and plans.
• Finally the integrated knowledge needs to be applied to the problem.

So why do we never see this Pull cycle in diagram form?

• Is it because Pull (Demand) is less important than Push (supply)? Surely not! Most people would see them as equally important, and there is an argument that Pull is in fact a bigger driver of knowledge transfer than Pull. 
• Is it because the Pull cycle is less useful than the Push model?  Surely not! If we can generate knowledge pull, and a demand for knowledge, we can spark knowledge supply. 
• Is it because the Pull cycle is more difficult to work with than the Push cycle? Maybe this is one reason. Asking is less of a natural behaviour and more of a cultural barrier than sharing, so sharing may be the easier option. But ignoring barriers wont help you in the long run.
• Is it because the Pull cycle is less measurable? The Push cycle is often linked with the creation of documents, and this is something that can be measured. Leaving aside the question about whether anyone is looking for these documents, and whether these documents are useful when found, it is easier to measure the first couple of steps in a Push cycle than it is to measure similar steps in a Pull cycle. However you can also measure searches, and measure questions in a community forum.
• Is it because people only want one diagram? Yes, probably, but we know that KM cannot be reduced to a single and simple diagram; it is far too nuanced for that.
• Is it because everyone else draws their cycles this way? Probably yes. But just because everyone else does it, doesn't make it correct or sufficient.

There are many places where this Pull cycle can be applied very well.

• Each individual uses this cycle when searching for knowledge. Most of the steps are done in the individuals head, but it may be useful to talk them through with a manager or colleague,. 
• You can apply the cycle within a Peer Assist meeting, and the format of the meeting can follow the entire cycle from asking the questions, to reviewing the answers, to integrating them into the forward workplan.
• You can apply it within a Community of Practice forum. Someone asking a question on the forum could  be asked to give feedback on the answers they received, the knowledge they selected from these answers, how they integrated this knowledge into their plans and (ideally) how it helped solve the problem. 
• You can apply it as part of KM planning. A project team can identify their knowledge needs, conduct a search/ask activity, then get together to discuss how they will select and integrate the knowledge they have found. 

Being more conscious and explicit about the Pull cycle gives you more ways to create and stimulate knowledge demand in your organisation, and helps drive a Knowledge Seeking culture. 

Please do not focus only on the Push cycle for KM - its only half the story. Make sure your KM Framework incorporates the Pull cycle as well. 

The Knowledge Management Iceberg model

The KM iceberg is a common image, but what does it really mean?

The Iceberg is a very familiar model within Knowledge Management, seen in many slide presentations. I first used it myself in the public domain, in an article in Knowledge management magazine, 2000, entitled "Mining the deep knowledge - tapping into things you don't know you know" (contact me through comments for a reprint) and I have re-used it many times over the last couple of decades.

In the iceberg analogy,the documented knowledge of an organisation is like the visible portion of an iceberg, and the undocumented explicit knowledge (things people know that they know but have not documented) is underwater, but close to the surface, in the daylight zone where it is visible.

The documented knowledge can, in theory, be seen and found easily, as it lies in plain sight.

Similarly the undocumented explicit knowledge can be found and accessed if you can find the right people to direct a query to.

However deeper down, out of sight, lies the vast mass of unconscious tacit knowledge; the bulk of the iceberg. This knowledge is invisible, inaccessible, and easily overlooked. These are the things that people don't necessarily know that they know - the unknown knowns - and this is very often the deep-lying technical knowledge and mastery that is of real value to others.

Before this knowledge can be shared and applied, it first needs to be made conscious. A process of realisation is needed, to move the knowledge into the conscious domain, and to bring it up into the sunlight.

Much as data may need to be mined out of documents to be useful, so the unconscious knowledge needs to be mined out of the human brain before it can be made conscious and explicit, and then (if necessary) documented. This "brain mining" is a skill, which can be learnt and taught, but it is primarily a human activity that cannot be automated. It is however the highest value step in the entire spectrum of knowledge management activity.

The mining tools we use to reach this deep knowledge are Questions, and any knowledge management system that does not somewhere involve some question-based processes will never reach the deep dark unconscious tacit knowledge where the real secrets of success and failure are to be found.

When learners become teachers - how community roles shift over time

Community of practice members may start by being learners and end up being teachers who still learn.

Let's look at patterns of behaviour in a Community of Practice forum, or discussion area.

• When a novice employee is very new to an organisation or to a topic, they are usually very quiet in a community forum. They are still learning the basics, which they get from training and from the community knowledge base, and they spend 100% of their community time watching and reading community discussion. They don't tend to ask questions on the forum - their questions are still fairly basic, and if they do ask, the answer is usually a version of "read the flipping manual".

• After a while, and maybe quite quickly in some cases, the employee starts to face problems and issues that are not in the manual. That's when they start to ask questions of the Community, and begin to use the Community members themselves as a resource. They move from 100% lurking and reading, to (over time) mostly asking.

• After a bit more time, the employees begin to find that they themselves can answer the questions of others. They have become practitioners, they understand the practice, and can share the lessons they have learned. This can happen relatively quickly as well - I remember interviewing one guy who was less than 2 years into the company, and a question came up on the community forum which was related to a special study he had just completed.  He answered this successfully, and reported how pleased he was to be able to "feed something back" to the CoP.

• The more experienced members- now experts in their topic -  may take on a leadership role in the CoP, as core team members, or as subject matter experts, with accountability for teaching and for owning some of the Knowledge Assets of the Community.  However a good expert never stops learning. Only last week I saw, in a busy community forum, an expert asking for feedback, comments and advice on a document she had produced. Even the most advanced expert should spend some time asking, some time answering, and some time teaching.

Now lets map some demographics onto the diagram above. 

Imagine a far-eastern company, with many many young staff, and few experts. Here the bulk of the staff will be in the Red area in the diagram, with a few in the other segments. This CoP will act more like a Teaching CoP, with relatively little discussion and quite a lot of publishing.

Imagine a western engineering company, loaded with baby-boomers. Here a large proportion of the staff are in the blue, yellow and green segments. The bulk of community activity will be about discussion and dialogue, rather than about publishing and reading. 

As always, it's more complicated than any simple model will allow, and there is no "one size fits all" approach, but different communities of practice may operate in different ways in different settings, largely driven by the experience profile of the community members. 

Why Yammer's default question is unhelpful

If you agree with me that the greatest value in organisational online discussion comes through answering questions, then Yammer's default prompt does not help.

"What are you working on?" asks Yammer - as a work-related version of the Facebook question "What's on your mind".

As a way of getting people to share work-related activity, that's a reasonable question, and pretty soon you will find your Yammer stream full of statements like

• "I'm working on a new proposal"
• "I'm getting ready to go on holiday"
• "I'm finishing the assessment report"

For some people, that's interesting connectivity, that helps them feel connected with co-workers. For others, that's unwelcome Noise; stuff they didn't need to know that distracts them from their own work. The risk is that the noise turns people off.

This blog has long championed the use of Knowledge Pull behaviours, and Knowledge seeking.  We know for example that Asking is tougher than sharing, but gives instant results. We know that the more questions that are asked in a Community of Practice, the more successful it is. We know that 75% to 90% of knowledge sharing comes as a response to a request for help. We (or I, at least) believe that an internal knowledge market is best grown through demand rather than through supply. And also  that Facebook is not a good analogue for in-house social media.

If you want to use a product like Yammer for knowledge sharing, then I can't help thinking there's got to be a better default prompt - one that drives Pull and not Push; one that develops the habit of Asking.

Maybe something like

"What knowledge do you need to help deliver your work?"
"What can your social network help you with today?"
"What question do you have for your network?"

The role of Asking in Knowledge Management

Most knowledge sharing in our private lives is driven by Asking. Let's use this in work as well.

Think about the last time you shared knowledge with one of your friends or family. Maybe it was this morning, or yesterday - maybe you shared advice, a tip or hint, or something you had found out that the other person did not know.

I bet you shared this knowledge bacause you were asked.

• "Where are the car keys?"
• "What's the weather going to do today?"
• "Are you doing anything tonight"?

That's the way that private knowledge sharing seems to work; it follows the three rules below.

When do we share?  Most often, when we are asked

Who do we share with? People who ask us

What is preventing us from sharing? Often, nobody is asking (see here to understand how to tell when sharing is broken)

So how do we take these principles into the workplace?

There are several ways in which you can introducing Asking as part of a Knowledge Management framework.

 The first obvious example is in Communities of Practice. The most important and powerful role of CoPs is providing a forum where CoP members can ASK questions of their peers. The forum allows the person who actually needs the knowledge to ask directly, and the answer comes from the members with knowledge to share.  Communities access the long tail of knowledge, and communities work better with a large element of "Knowledge Pull"

The second case is in After Action Reviews. Here someone in the team, such as the team leader, ASKS a series of 5 questions, to elicit the knowledge of the team. This knowledge will be used by the same team to improve their practices, so the knowledge providers and knowledge users are the same team.

The third example is in end-of-project Retrospects. Here the questioning is led by an experienced external facilitator. The process is an asking process - structured, quality assured, and aimed at answering (in advance) the likely questions from future projects.

Asking is the most powerful way to drive knowledge transfer - Pull is more powerful than Push

Don't wait for knowledge to be volunteered - go ask.

One of David Snowden's principles is that "Knowledge can't be conscripted, it can only be volunteered". However waiting passively for voluntary contributions is the wrong way to populate a KM repository.

I Know The Answer!
Originally uploaded by ngader

Knowledge can't be conscripted, it can only be volunteered, and often it won't be volunteered until you ask.

This is an outsome of the problem of the Unknown Knowns. Often people don't don't realise they have learned something, until they are asked about it, or have the chance to discuss it.

Sometimes you find organisations who have set up a system whereby people are required to identify lessons or new knowledge themselves, and then to add them into a knowledge repository. I am not a huge fan of volunteer systems like this; I don't even like them for collecting innovation suggestions. I think you capture only a small proportion of the lessons this way, because people are not aware that they have learned anything, and if they are aware, they often discount the learning as "not important". Also, self-written knowledge are often superficial, because there hasn't been the depth of dialogue and questioning to get to the lesson.

I am not arguing for forcing people to share knowledge, but I am suggesting that you don't wait for the volunteers to come to you. Instead you give people scheduled facilitated conversation-based opportunities where they can become aware of what they know, and which provide a safe and encouraging environment for them to volunteer the knowledge when asked.

There are two main approaches for doing this; reactive, and scheduled.

The reactive approach requires someone to identify particular successes and failures from which to learn. The failures can be obvious, such as HSE incidents or significant project overruns, and many companies have mandatory processes for reviewing these failures. But how do you spot the successes? Maybe you can use your company benchmark metrics, and pick the best performing units for review. Perhaps you could work with the knowledge from the manufacturing plant that never had an accident, as well as from the one with frequent accidents. Maybe you can look for the best sales team, and look to learn the secrets of their success. Or maybe you can do both successes and failures - I did a very interesting study not long ago for an organisation that measures staff engagement using the Gallup survey. We picked the ten top scoring sales teams, the ten bottom scoring teams and the ten teams which had shown the most improvement over the previous year, and interviewed the team leader and a team member of each one, to pick out the secrets of successful staff engagement.

Another organisation we have worked with uses global consultants and Technical Directors to identify opportunities for learning and knowledge transfer. They travel the world, reviewing activity at different centres, and will identify good practice which needs to be repeated, as well as opportunities to learn from mistakes.

An alternative approach, common within project-based organisations, is to schedule learning reviews and knowledge exchange within the activity framework. These could be

• After Action Reviews on a daily basis during high-intensity learning, or after each significant task 
• Peer Assists early in each project stage, or during project set-up
• Retrospects (or some other form of Post Project review) at the end of each project stage, or at each project review gate
• A Knowledge Handover meeting at the end of a project, to discuss new knowledge with other projects
• A Technical Limit meeting during the detailed planning stage, to bring in knowledge from people with detailed experience
• A Retrospect (or some other form of review) at the end of a bid process, when the company knows if the bid has been successful or unsuccessful.

There are many advantages to the scheduled approach. Firstly, success and failure are components of every project, and if every project is reviewed, lessons may be identified which can avoid the big mistakes later on. Secondly, if lessons identification is scheduled, it becomes a clear expectation, and the company can monitor if the expectation is being met. This expectation is common in many organisations, thought the rigour with which the expectation is met seems to vary. Finally, by scheduling and facilitating the learning dialogue, you can uncover the knowledge that nobody knows they know, until they start to discuss it.

Don't rely on people volunteering their knowledge spontaneously - instead set up scheduled processes which provide a request and a context for volunteering. 

Which is the most unnatural behaviour - sharing knowledge, or seeking knowledge?

Any knowledge transaction requires a seeker and a sharer.  But which of these two behavioural stances is more challenging?

I am talking here about public sharing and public seeking, rather than people depositing files in a certain place and others privately searching for them. I am talking here about public behaviour, social behaviour, the sort of behaviour that is culturally influenced, and is a cultural influencer; the sort of behaviour you would like to see demonstrated, and role-modelled, as part of your KM culture change.  

Both seeking and sharing have their barriers. 

The main barriers to seeking are Not Invented Here, and no wanting to look like someone who "doesn't know". Refusal to seek for knowledge is true "Knower" behaviour. The main barriers to sharing are fear of losing power, and fear of treating knowledge insecurely. (Barriers such as lack of time, and lack of tools, are generic to both behaviours).

But which of those barriers are strongest?

Image Wikimedia Commons

Imagine, if you will, a car driving through a strange city, obviously lost (despite the satnav and road atlas). There are people on the sidewalk with local knowledge, who would be able to help the driver. There are therefore the ideal conditions for knowledge transfer - a clear need for knowledge, and a clear supply. Why then does the knowledge not reach the driver? Is it because

a) He doesn't ask (and for the purposes of this blog post, let's assume its a He)
b) The people on the sidewalk won't tell him (and for the purposes of this blog post, let's assume it's a safe part of the city, and they won't mug the driver).

I am sure you will agree with me that it's usually for reason a).

That's true in organisations as well. We did a survey in one organisation, and asked people 

• Would you be willing to share knowledge with someone, if asked? 70% said Yes.
• Would you be willing to ask for knowledge form someone else? 30% said Yes.

As David Snowden said - 

"In the context of real need few people will withhold their knowledge. A genuine request for help is not often refused unless there is literally no time or a previous history of distrust". 

Public and social knowledge seeking is a bigger challenge than public and social knowledge sharing. Seeking stimulates sharing ("few people will withhold their knowledge"); sharing does not stimulate seeking.   As the authors of this Mckinsey article on the "Giver" culture" say,

"Giver cultures depend on employees making requests; otherwise, it’s difficult to figure out who needs help and what to give. In fact, studies reviewed by psychologists Stella Anderson and Larry Williams show that direct requests for help between colleagues drive 75 to 90 percent of all the help exchanged within organizations".

If direct requests for help drive 75% to 90% of exchanged assistance, and asking for help is a far tougher barrier than reponding, then that tells us where to focus our culture change efforts; not on sharing, but on asking.

The McKinsey term "giver culture" is wrong - they are describing an "asker and responder culture". That is why, in our advice to clients, we always always recommend

• deliberately cultivating a culture of asking rather than a culture of sharing, 
• developing habits of Asking out loud rather than Working out loud, and 
• emphasising Push over Pull.

Perversely, non-social seeking and sharing may well work the other way round. If knowledge is codified, people are happy to use a search engine to find it, and the more (and better) the knowledge available, the more people will search.  Our car driver will be happy to use satnav, happy to use a road atlas, and happy to read road signs. These behaviours are all socially acceptable. The knowledge which is codified is the generic knowledge - the main roads, the turns and roundabouts, and (in the case of the road signs) the directions to the major landmarks.

However there always comes a time when close navigation is needed, where local knowledge is important, or where you are "off the map".

It is at times like this that you need to develop the cultural habit of Asking. 

How to make knowledge needs visible

If we could make Knowledge Needs visible, we would have a far greater chance of providing knowledge where it's needed.

Help Wanted by Egan Snow on Flickr

One of the biggest challenges in working with knowledge is that it is invisible. Nobody can tell by looking at you how much knowledge you have, and nobody can tell what knowledge you are in need of. Nobody knows when you need help.

Two people can pass each other in a corridor, one of whom possesses the solution to a problem that is taxing the other out of their mind, and they don't even realise the need to talk, because the knowledge and its need are invisible.

If knowledge were a visible commodity, like cereal or cans of soup, it would be easier to manage. We would open the knowledge grocery cupboard, see the knowledge gaps on the shelf, know that we need knowledge, and then go to the knowledge supermarket and buy the knowledge we lacked.

However there are ways to make the knowledge visible; both the knowledge that people hold, and the gaps in their knowledge they wish to fill. Once you have made knowledge, and knowledge needs, visible you can just watch the interactions start to happen, as suddenly supply and demand are connected.

Making knowledge needs visible in a conference.

At one conference we asked people to write, on their name badge, an issue or problem that was taxing them: Knowledge they needed. Then, as people circulated for coffee, others who had ideas or solutions to the problem could introduce themselves, and knowledge exchange could start.  Mars did a similar exercise, using electronic tags which lit up when someone with similar knowledge or interests came near.

Just the simple act of making knowledge needs visible prompted a huge number of interactions.

Making knowledge needs visible through a knowledge market

A Knowledge Market is a fantastic face-to-face event for a Community of Practice - rather like the UK practice of a "Bring and Buy" sale.  At the Knowledge Market,  people host a poster listing their knowledge issues and their knowledge offers, and others circulate, looking for answers to their problems and problems they can answer.  By making knowledge supply and demand visible, you promote interactions, and people share knowledge with each other and come away richer.

Making knowledge needs visible online

You can do something similar online.

• You can set up a yellow pages system, where people can identify not only what they know, but also what they need to know.
• You can use social media to broadcast your knowledge needs. In Knoco we use Yammer as a way to tap into the knowledge of our world-wide colleagues.  Rather then following the Yammer prompt "What are you working on", we use it to post "what do I need to learn today".

• You can set up a "Knowledge wants and offers" page, just like you see in the newspaper, or in the recycling groups. we have done this ahead of conferences, to set up interactions for knowledge transfer at the conference itself.

The more we can make the knowledge visible, and make the questions, or knowledge needs, visible, the more we can put people together with others to improve knowledge transfer and solve problems.

How to motivate people to share? Don't bother.

Another client has asked us "how do we incentivise  knowledge sharing?" The answer we usually give is "don't bother".

Money on a hook by Tax Credits on Flickr

We give this answer, because knowledge sharing in itself achieves nothing. Knowledge needs to be re-used before any value has been added, and before KM has delivered.

And of the two - sharing and re-use - far bigger barriers are present in re-use. The Not Invented Here syndrome is far more prevalent than Knowledge Hoarding.

As an analogue, think of a driver in a car in a strange city, looking for a building which is not on the satnav.  They need knowledge, people on the sidewalk have the knowledge, but the knowledge doesn't reach the driver; not because people won't share, but because the driver usually doesn't ask.

Without an appetite for knowledge re-use, knowledge sharing can actually be counter-productive, resulting in the feeling of the "knowledge firehose".

Better to incentivise knowledge seeking first then knowledge sharing later, create the appetite for knowledge before you create the access, and create the demand before you create the supply.

There will naturally be SOME supply already, as there are people who naturally like to publish. They like to share, they like to write, they were given two ears, one mouth and ten fingers and use them in that proportion.  However if you create the demand and create the channel, the supply will follow. As David Snowden pointed out,

"In the context of real need few people will withhold their knowledge. A genuine request for help is not often refused unless there is literally no time or a previous history of distrust. On the other hand ask people to codify all that they know in advance of a contextual enquiry and it will be refused (in practice its impossible anyway). Linking and connecting people is more important than storing their artifacts".

Create the need, connect the people, and the sharing will follow.

And how do you create the need for knowledge?  There are a number of ways;

• Managers create a high performance culture, where people are eager to "push the envelope"
• Managers ask the two questions that drive KM behaviour, emphasising the first
• Managers set people challenges that they don't know how to solve using just their own knowledge

So don't incentivise knowledge sharing - incentivise knowledge seeking first. The sharing will follow.

Knowledge for Action, Knowledge for Interest

Knowledge has to lead to action in order to add value. As Bill Wilson says (albeit about learning rather than knowledge per se) "Learning without action is mere mental trickery, while action without learning is simply useless physical exercise".

We have been working with a client recently on developing a lesson learning system from projects. The collection of lessons has been going well, but the client had the firm view that lessons should be collected in a library that future projects could review if they wanted. For them, the knowledge would be "for reference", or "for interest".

Of course, few people have time to read through the lessons, and there are now so many lessons that reading through them is becoming more and more daunting. 

We are now helping the client to move to a different philosophy, where lessons are forwarded to the owners of the organisational processes, so they can continue to update the processes in the light of the new learning. This is "knowledge for action".  

We recommend "knowledge for action" rather than "knowledge for interest" as being a far more effective system.

Communities of practice, as well, should focus on actionable knowledge. Actionable knowledge is

• Advice
• Good practices
• Improved practices
• Solutions to problems
• Answers to questions
• New approaches
• Recommendations
• Guidance
• Tips and Tricks

Non-actionable knowledge is

• Interesting articles
• Links to interesting articles
• Musings
• Quotes and aphorisms
• Descriptions of what you are doing (unless you analyse this to bring out actionable learning)
• Descriptions of what you have done (unless you analyse this to bring out actionable learning)
• Gossip

Communities that circulate non-actionable knowledge, or "knowledge for interest" are classified as Communities of Interest rather than communities of practice, the clue being in the title. 

CoPs deliver more value when they focus on solving the problems of the members than when they circulate "interesting links and ideas". CoPs that operate through a Pull process - where members with problems or issues ask questions and receive recommendations and support from other members - know they are adding value.  Each answered question represents a solved problem; knowledge which the person who asked the question can immediately put into action.

In a question-led CoP, each interaction leads to action.(Tweet this) 

So when you are sharing knowledge in a CoP, ask yourself whether you are sharing "something that others will find interesting" or "something that will help people do their job better" - something actionable. If you have nothing actionable to share, then ask a question instead.

And when you are designing lesson learning systems, make sure each lesson leads to action, rather than being retained "for interest".

Ask the audience, phone a friend

---

When it comes to giving people access to tacit knowledge, there are two popular approaches, which we can call "Phone a Friend" and "Ask the Audience," with reference to the popular TV game, "who wants to be a millionaire". In this game, people are asked increasingly difficult questions, until they reach a question where they do not know the answer. They are allowed a number of lifelines; one of which ("Phone a friend") allows them to call a friend, hopefully with expertise or knowledge in the topic, to see if they can answer the question, and another of which ("Ask the Audience") allows them to poll the studio audience.

Organisations can offer similar lifelines to their staff, as part of their Knowledge Management approaches, to allow staff to find knowledge when they need it.

An organization operating along the "Phone a Friend" route may set up expertise directories, where staff can find designated experts for specific topics. They may set up “Ask the Expert” systems, where you can type in a query which goes to the relevant expert to be answered. They may also set up closed-membership communities of practice, where the experts can get together and discuss “best practices”.

An organization operating along the "Ask the Audience" route set up experience directories, where you can find all the people with experience in specific topics, whether they are experts or practitioners. They may set up open-membership communities of practice, where practitioners from all over the company can contact each other for help and advice. They set up “Q&A” systems, where you can type in a query which goes out to the community membership, and anyone with knowledge to offer can answer, thus tapping into the Long Tail of Knowledge.

In the first model, knowledge is assumed to reside in the heads of the experts. In the second model, knowledge is assumed to be dispersed around the community.

There are three cases where you might want to go down the Phone a Friend route.

• The first case is where the demographics of the company is highly skewed to junior people. We see this, for example, in the national companies of the far east, where there are a few experts who have been in the business for decades, plus thousands of people fresh out of graduate school. Here the bulk of the community is inexperienced, and there would be no point in asking the audience, because the audience would not know.
• The second case is where the knowledge is very mature, and not changing much at all, and where all the answers are known. There would be no point in asking the audience, as anyone with any knowledge at all on the topic would know the answer. Here you are better off asking a single authority (or even better, just reading the manual).
• The final case is where the knowledge is very abstruse, and only one or two people know about it. The company expert on Internet law, for example, or the one person in the company who knows about Environmental Impact Statements in the Gambia. Here there is no community – no audience to ask. You have to find the friend to phone.

Where experience and knowledge are more widely spread, then Asking the Audience (open questions in a community of practice) is a far better approach. Otherwise experts can become bottlenecks, we can’t assume the experts can hold the totality of knowledge in their heads, and we can’t assume that the expert will remain up to speed with all the developments in the field. Very often the REAL expert is the grizzled old foreman in a remote operating unit, who knows more about the way things really operate than the whole of head-office put together.

Of course in many companies you can use both lifelines. You can ask the audience (through community Q&A systems), and you can phone a friend, by using the company Yellow Pages to identify those few people with deep expertise in the area you need to learn about. And the great thing about KM In an organisation, compared to the TV game, is that you can use both lifelines at once, and you can use each of them as many times as you like.

The "Ask and Respond" culture in KM

---

This article was making the rounds yesterday via Twitter. It is a really interesting article from McKinsey, which starts with the observation that, in Intelligence groups in the USA, "the single strongest predictor of group effectiveness was the amount of help that analysts gave to each other".

The article goes on to discuss this culture, and draws on several studies to conclude that "Across these diverse contexts, organizations benefit when employees freely contribute their knowledge and skills to others". The authors go on to talk about a Giver culture, where knowledge is freely shared, and a Taker culture, where it isn't*. Taker cultures often dominate in organisations, through overt or hidden forms of internal competition, even though Giver cultures are significantly more successful in business terms. The article talks about how Giver culture can be introduced, rewarded, and modelled by leadership.

However a little deeper in the article, we find that Giving (exchange of knowledge) is not a cultural norm in itself, it is a response to something else.

"Giver cultures depend on employees making requests; otherwise, it’s difficult to figure out who needs help and what to give. In fact, studies reviewed by psychologists Stella Anderson and Larry Williams show that direct requests for help between colleagues drive 75 to 90 percent of all the help exchanged within organizations".

Giving is a Response to Asking.

What we see in the successful cultures, is a behaviour of Asking, which prompts a Giving/Helping response.

It is possible to develop an Asker culture - the article talks about an exercise called a Reciprocity Ring, which is a face to face version of the Question-driven communities of practice we see operating so successfully as part of mature knowledge management programs. Peer Assist is the archetypal Asker process, which always generates a Giver response. Many of the standard Knowledge Management interventions act as culture change agents in their own right to promote the behaviours of asking and of giving.

So if you are interested in creating a "culture of Knowledge Sharing" - a Giver culture, that "single strongest predictor of group effectiveness" - remember that Giving is (75% to 90% of the time) a response to Asking.
Try creating an Asker culture first (as I suggest in this video).


*I don't really like the terms "Giving" and "Taking" here - all exchange of knowledge requires a giver and a taker. The question is, what prompts and supports the interaction between the two, and who takes the first step.

Analysing searches in a Community of Practice

---

An interesting post from Mary Abraham on what an analysis of searches might tell you about knowledge topics. If you could analyse patterns of searches, it might lead you to identify emergent knowledge topics in your organisation, your community, or in society. It might provide a bottom-up approach to identifying your critical knowledge areas.

We tried just this approach of analysing queries in a big 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. Topics 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.

The importance of an asking culture (video)

---

A recent video, recorded in China, which explores the requirement for an Asking culture and part of Knowledge Management