2 questions that show KM is broken

The two questions in this little conversation are evidence of a broken KM culture or system.

It's the sort of conversation most of us have had at some time on our lives. In this conversation we can see evidence of a missed opportunity to share knowledge ("I could have told you...") which had negative consequences ("... it wouldn't work").  

This is what we call the "Cost of Lost Knowledge", and the elimination of such consequences is the primary value that Knowledge Management will deliver.

Why was this opportunity to share missed?

Firstly there was no supply of knowledge ("Why didn't you tell me?"), and the knowledge manager exploring such a Lost Knowledge Incident would want to explore this lack of supply. Did the knowledge supplier not want to share? Did they not know how to share? Or did they not even know they were supposed to share? Either they were unwilling to share, unable to share, or unaware of the need to share (these are the three main barriers - lack of willingness, ability or awareness).

Secondly, and perhaps more fundamentally, there was a lack of demand for knowledge ("Why didn't you ask me?"). Again, this needs to be explored - was the knowledge seeker unwilling to ask (they didnt want to appear stupid), unable to ask (there was no system in place for asking for knowledge) or unaware that asking for knowledge was a sensible and expected behaviour.

If you know why the transfer did not happen, then you can address the awareness, the willingness, and the mechanism, and ensure that the sort of conversation shown here never happens again.

If this conversation reminds you of your organisation, and you would like help sorting it out, give us a call.  We can help.

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.

Don't lead the witness (the objectivity of the km professional)

Very often the Knowledge Management professional (especially the Knowledge Engineer) will get involved in the mechanics of Knowledge Capture. This is where they need to be fully objective, and avoid "leading the witness". 

Image from Wikimedia

If you, as Knowledge Manager, are involved in a Knowledge Capture service, the purpose of the exercise is to work with an individual or group so that they can become aware of, and express in some way (verbal or non-verbal), the knowledge they hold in their head.

The key point is that it is the knowledge they hold in THEIR head, and it is not to be confused with the knowledge you hold in YOUR head. Therefore your questioning style, in interviews, after action reviews and retrospects, needs to be objective, and based on Open questions.

Open questions are those where no answer or type of answer is presupposed, and which cannot be answered with a single word or short phrase. The following question is an open question -

"What were the reasons behind your choice of action?"

The following question is not an open question - it is a classic closed question -

"Did you choose that action because you thought it was the best thing to do?

You get a lot more response and detail from the interviewee through an open question. In the example above they might give you three or four reasons why they took that course of action. In the closed question example they might just reply "Yes", or they might amplify on the Yes answer, but you have already closed down several of their potential lines of response.

Even worse than the closed question is the leading question.

A leading question is one where you, as the facilitator, suggest the answer or provide an answer that you want the interviewee or group to confirm.  For example;

"I would have thought that the correct course of action would have been X, don't you?"

"You must have known at the time that this was wrong?"

"Were you as appalled as I was at that decision? 

"What you are telling me is that this was all Y's fault, isn't that right?" 

 Leading questions are tempting, because they not only allow the interviewer some status in the process (Interviewers have opinions too!) but also promote social bonding through expressing shared or similar opinion. However they have two main problems in Knowledge Management;

Firstly they begin to confuse the opinion of the interviewer with the opinion of the interviewee, so the knowledge which is captured then becomes mixed or diluted. There is a place in KM for validating captured knowledge, but that place comes after the knowledge is captured and not as part of the capturing process.

Secondly leading questions or suggestive questions have been shown to have the potential to implant false memories.  Asking questions like "how fast was the car going when it passed the stop sign?" have led people to recall there being a stop sign in a video, when in reality there was no such sign.

Next time you conduct an interview, check through the interview transcript to see how many of your questions were open, how many were closed, and how many were leading questions.

Asking leading questions is outlawed in many legal systems, and is often referred to as "leading the witness". I think we should also try to avoid it within Knowledge Management processes.

Analysing questions in a community of practice

An analysis of searches and queries can tell you a lot about the knowledge topics which are of the greatest value in your organisation.

Analysing patterns of searches helps you to identify the emergent knowledge topics, the knowledge gaps, and the "hot potatoes" in your organisation, your community, or in society.

We tried this approach by analysing questions within a big community of practice . The queries to the community forum were already characterised into topics, because when you ask a question using the forum software, 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, knowledge assets 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 such as Knowledge Exchanges so that we could start to exchange and document best practice.

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.

What makes a good learner?

If you want a learning organisation, you need an organisation of learners. But what makes a good learner?

Learner, by sangeight on Flickr

Here's an article called "Seven Characteristics of Good Learners" by Maryellen Weimer, which addresses just that question.

According to Maryellen:

• Good learners are curious – They wonder about all sorts of things, often about things way beyond their areas of expertise. They love the discovery part of learning. 
• Good learners pursue understanding diligently – A few things may come easily to learners but most knowledge arrives after effort, and good learners are willing to put in the time to seek and to find. Good learners are persistent. They don’t give up easily. 
• Good learners recognise that a lot of learning isn’t fun – That doesn’t change how much they love learning. Learning is hard work sometimes, but when understanding finally comes, when they get it, when all the pieces fit together, that is one special thrill. 
• Failure frightens good learners, but they know it’s beneficial – It’s a part of learning that offers special opportunities that aren’t there when success comes quickly and without failure. In the presence of repeated failure and seeming futility, good learners carry on, confident that they’ll figure it out. 
• Good learners make knowledge their own – This is about making the new knowledge fit with what the learner already knows, not making it mean whatever the learner wants. Good learners change their knowledge structures in order to accommodate what they are learning. 
• Good learners never run out of questions – There’s always more to know. Good learners are never satisfied with how much they know about anything. They are pulled around by questions—the ones they still can’t answer, or can only answer part way, or the ones without very good answers. 
• Good learners share what they’ve learned – Good learners are teachers committed to sharing with others what they’ve learned. They write about it, and talk about it. Good learners can explain what they know in ways that make sense to others. They aren’t trapped by specialised language. They can translate, paraphrase, and find examples that make what they know meaningful to other learners. They are connected to the knowledge passed on to them and committed to leaving what they’ve learned with others.

An organisation of such people would be a powerful learning organisation indeed.

"What would you do differently next time"? The crucial question.

To learn from the past, we need to reflect on the past, and questions are crucial for prompting reflection.

When you observe the conversations and presentations at conferences and in organisations, they are very often stories about the past.

"We did this, we did that, this happened, we met these obstacles and through perseverance we achieved success"

It is possible to learn from these stories in a general sense, but often these stories are narrative and not reflective, and it is from the reflection that knowledge arises.

The question "If you were to do this again, what would you do differently next time" is an excellent question to provoke reflection. It is a question that we use all the time in After Action Review and Retrospect, but it is one that you otherwise rarely hear at work, and almost never hear raised at conferences.

Many times people at work, or people at a conference, would ask each other “what did you do, how did you do X, how did you respond to Y”, and what they would get in reply would be, effectively, history. The replies would help you understand what the team did, but not understand whether this is a good thing to do, and bad thing to do or a random thing to do.

But if someone is asked “what would you do differently”, you can't answer with history; you have to answer with analysis and with insights.

The progression from Observations ("What we did and what happened") to Insights ("This is why things happened he way they did") to Lessons ("This is what I would do next time") is a process of analysis, and needs t be driven by questions - either questions from a facilitator or a third party, or by self-questioning.

History is not knowledge. It is analysis of history - reflection on history – that creates knowledge. We need to ask, not just “what did you do”, but also “with reflection, what would you do differently” if we are to get a true knowledge.

Is questioning the most important skill for the KM professional?

Perhaps the most important skill for the KM professional is the skill of Questioning.

Questions are the hook from which most of your knowledge hangs. Anyone with small children knows that itireless questioning underpins their early learning. The same principle applies in organisations.  Making knowledge conscious, making it explicit, and capturing or transferring that knowledge is triggered through the use of questions.

Poor questions result in poor knowledge, or result in knowledge never been identified in the first place. We recognised this recently when working with a company who had been trying to identify knowledge through Retrospects, without giving any training in questioning skills to the Retrospect facilitators. As a result, the knowledge gathered was superficial and of very low value.

Questioning is important in knowledge interviews, when you are trying to help the interviewee to reflect on their experience. Group questioning works the same way in the after action review and retrospect processes. In communities of practice, the facilitator often needs to "question the question", and find out what a community member is really asking about and looking for, before they a question can be answered.

Questioning techniques include the use of open questions, the use of probing questions to get down to the next level of detail, the use of closed questions to home in on a learning point, and the use of summarising and feeding back to ensure you have fully understood the answers. We terach the skills of open questioning, and the use of question trees, in our core Knowledge Management traning courses.

Listening skills are also very important, and are part of good questioning technique.  Listening carefully to the answer, assessing how much knowledge has been provided, and asking additional questions to fill the gaps - this is also part of the Knowledge Manager's skillset.

Ensure your KM staff are skilled in questuioning and listening.

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.

Reaching the deep knowledge

Reaching the Deep Knowledge often requires the help of a facilitator or interviewer, and there is a tell-tale sign that shows when you get there.

"woman, thinking" by Robert Couse-Baker, on Flickr

Superficial knowledge transfer happens all the time.

A foreman leaves his job. The company arranges a hand-over meeting, and the foreman talks through the processes and procedures with his successor, but the real knowledge - the tips of the trade, the workarounds, the instinctive feel for the tasks - leaves with the man.

 An engineer opens his email, and reads a request for advice from a colleague on another continent. The engineer drafts a quick reply, describing a solution he has applied in the past. However he fails to think through the reasoning and insights underlying the solution, and his reply is superficial and of little value to his colleague. The colleague gets no help from the suggestions, and next time she won’t even bother to ask.

 A project manager finishes her project. She sits down for a couple of days and writes a close-out report, where she details the history of the project, and the successes this project has achieved. But she never gets to the secrets behind the success; these are hidden in the undocumented interactions in her team. As a result, the successes are unrepeated.

 In each of these examples, an opportunity to exchange valuable knowledge has been lost - in some cases forever. The crucial knowledge stays in the head of the foreman, the project manager, the engineer, because none of them are conscious of what they know. Without being conscious of what they know, they have no way to pass that knowledge on. Any knowledge management system that fails to find the things that people don’t know they know (the unknown knowns), that fails to mine the deep knowledge, will fail to deliver it’s full potential.

One of the key tenets of Knowledge Management is that we know more than we realise, and more than we can record. The individual, working alone and with a blank sheet of paper, seldom accesses the deep knowledge, and you end up recording the superficial. The only way to dig a bit deeper (while still realising we won't get everything) is to start probing with questions.

Questioning processes

A good questioner, or a good questioning process, can help the individual dig deeper than they can manage unaided. That's why so many Knowledge Management processes are based on questioning and dialogue.

On a short-term small scale, the After Action Review is a questioning process; getting at the ground truth behind the results of an exercise or activity. The team’s expectation of an event is compared with the actuality, and the facilitator goes through a questioning process to find the reasons for the difference between the two. Where there is a difference, there is learning, but it may take some probing questioning to get to the knowledge. Oil companies use After Action Reviews in situations where a small team conducts a brief action, such as a maintenance team working a shift at a refinery, or a negotiation team conducting a difficult meeting with a host government. In every case we found that the quality of the questioning determined the value of the knowledge. Superficial questioning gives shallow knowledge of limited use. Harder questioning, maybe using the technique of ‘the five whys’, gets at the deep knowledge, where the real value lies.

On a larger scale, the Learning History uses the same sort of questioning techniques. A skilled facilitator, informed but detached, not a member of the team, will take a project team through a structured questioning and discussion process, where the history of the project is reviewed and the knowledge brought out and captured. For example, I was once part of a joint interview team, charged with capturing and packaging the knowledge from a major industrial merger. We targeted 40 of the top decision-makers, and sent them an interview guide with some high-level questions. We then followed this up with hour-long interviews, where we applied some of these questioning techniques. It was pretty obvious when we started to tap into the unconscious knowledge - the pace of the interview slowed as the interviewees started to really think deeply about what had happened, and started to ask themselves ‘what really happened there, and what did we really learn?’.

You know, as an interviewer, when you are tapping into the deep knowledge. The interviewee stops, thinks, leans back in their chair, and their gaze rises as they look upwards and inwards.

That's the sign that you are digging deep - the sign that you are hitting Knowledge Paydirt!

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

Ask an expert, or ask a community?

There are two common approaches to answering requests for knowledge - asking an expert, or asking a community of practice. I prefer the latter, and here's why.

Image from an excellent blog by John Hand,
also discussing expertise location vs
knowledge networking

There are two major components to any Knowledge Management Framework, which we call Connect and Collect, and which deal with Conversation and Content. Connect involves connecting people who have a need for knowledge with others who have that knowledge, so they can discuss and converse, and so exchange knowledge which may not yet have been documented as content.

But which people do you connect?  Again there are two approaches - connecting people with experts, and connecting people with communities of practice.

The former is the focus of a growing discipline of expertise finding, with software that trawls social media (for example) to find the people who seem to say the smartest things, and so to divert questions to these assumed experts. The latter is the focus of traditional communities of practice, where questions are asked in open forum, to be answered by anyone with knowledge to offer.

Each of these systems has advantages and disadvantages.

Advantages and disadvantages of expert finder systems

In a situation where there is a small number of experts servicing a body of people with very limited knowledge (for example in a Customer Support system) it makes sense to connect the questioner with a single expert. They can give a quick and reliable answer, and there is no need to involve others in the conversation.

However this assumes that the knowledge can be answered reliably by a single person, that the system reliably identifies the experts from their published material, that the question can be accurately analysed, tagged and linked to a single expert, and that the expert does not become overloaded by questions.

There are some big issues in that last sentence. Identifying expertise from publications tends to recognise the prolific publishers and overlooks the more introverted experts. Also questions are rarely easily tagged, and often you need to "question the question" to find out what the real problem is.

Advantages and disadvantages of communities of practice

Communities of practice seem less efficient, in that a single question may go to many people, some of whom do not have the expertise to answer. Also the question may receive incorrect answers from people with limited knowledge.

In practice these disadvantages are also advantages. In a situation where knowledge is in fact scattered and diffuse, then only the network can provide the answer, as components of the answer may need to be supplied by different people. This will be the case where communities contain many experienced practitioners rather than a few,as in a technical area within a large multinational, or a sector network in a consulting firm.

In contexts like this, communities of practice may access "the long tail of knowledge" and pick up crucial piece of knowledge from unexpected places. See for example the story of the Polymath project, where crucial steps in knowledge were provided by non-experts.

Any non-experts who offer incorrect knowledge are usually rapidly corrected, which provides the spin-off benefit of removing wrong knowledge from the community.  The fact that others in the community can see the discussion taking place in open forum allows them either to contribute their knowledge, or (if they are a novice) to lurk, listen and learn. This apparent wastefulness - involving people who take no part in the conversation - in fact raises the knowledge of the whole organisation.

For these reasons, in settings other than Customer Support, I much prefer communities of practice to expert finder systems. The apparent messiness and inefficiencies of communities of practice are in fact their strength.

A great story of tacit knowledge, and how to make it explicit

I came across this story twice recently, and it is a graphic example of the tacit nature of knowledge, with some pointers about how this may be made explicit. 

Image from wikimedia commons

One instance of the story was in Nancy Dixon's blog, and the other was a blog post by the psychologist Gary Klein. The story is of a firefighter who made a "gut judgement" based on unconscious (tacit) knowledge. As Gary explains:

"One of my first interviews with firefighters, described in my book Sources of Power, covered an incident in which a young lieutenant was called out on a simple house fire. At least it seemed simple. The flames were coming from the rear of the single family, one-story home. Almost certainly the kitchen. 

Kitchen fires are pretty common, and there is a straightforward script for handling them: send the hose crew into the house and attack the fire from the inside. That’s what the lieutenant did. Then he ordered the water to be turned off, to see the effect. But there was no effect — the fire came roaring back with as much intensity as before. They tried again, with the same result. When they stopped spraying water on what they thought was the seat of the fire, the fire showed no reduction. 

"This was bizarre. The lieutenant gathered his crew back into the living room to plan his next move. And then he became tremendously uneasy — so uneasy that he ordered his entire crew to vacate the building. Just as they were leaving, the living room floor collapsed. If they had stood there another minute, they would have dropped into the fire below. Unbeknownst to the firefighters, the house had a basement and that’s where the fire was burning, right under the living room. 

"I had a chance to interview the lieutenant about this incident, and asked him why he gave the order to evacuate. The only reason he could think of was that he had extrasensory perception. He firmly believed he had ESP".

This is an example of knowledge so deep, the person holding the knowledge doesn't realise what he knows.  He does not know the grounds on which he made the decision to evacuate the building, and so can only explain it as Extra Sensory Perception.

Can such knowledge ever be made conscious (explicit) in such a way that it can be shared with others?  Well, yes, it can, because Gary Klein helped the firefighter become aware of what he knew, and so made the knowledge explicit. Here is how he did it.

• Gary interviewed the firefighter
• He got him to recall the events of the fire - what he saw, what he heard, what he felt
• He got him to reflect on those impressions, and analyse what was unusual; what was different. Indeed the firefighter had noticed two anomalies - the fire was much hotter than expected for a kitchen fire, and also much quieter than expected. These anomalies had alerted him that something was different - something was wrong.
• By the end of the interview he understood why it was so quiet: because the fire was in the basement, and the floor was muffling the sounds.

As Gary says in the blog post - 

A critical cue was what wasn’t happening: The noise he expected was absent. And that, as much as anything else, made him nervous and led him to order the evacuation. As a result of the interview, he could see that it wasn’t ESP that saved him, it was his experience. His experience enabled him to notice a cue — noisiness — that was missing.

Before the interview, this knowledge was so tacit the firefighter thought it was ESP. After the interview, he not only realised what he knew, he would be in a position to teach others and to pass that knowledge on.

It is through knowledge harvesting interviews such as this, and other question-based processes such as Peer Assist, After Action Review and Retrospect, that tacit knowledge becomes explicit. Nancy Dixon calls these processes "collective sense making", and often these processes require skilled facilitation. The task of making unconscious (tacit) knowledge conscious (explicit) is not an easy one, as shown above.

Without such questioning, the firefighter's knowledge would have remained tacit and, if he had been asked to advise others, he could have said little more than "try to develop ESP". After the interview, his advice would have been far more helpful.

Making tacit knowledge explicit can be done, it takes time and effort, but it can add huge value. In cases such as the one in this story it can save lives.

3 questions that drive innovation

Three simple and open questions are at the heart of an innovation process.

Berger's book

At Knoco, we believe innovation and creative problem solving is a process - a process that we call "Deep Dive."  Now via the Farnham Street blog we have some insight to the key questions that drive the process.

This Farnham street blog post references the book by Warren Berger called "A more beautiful question" where Berger describes three key questions as being vital to creative thinking and innovation.

The first question is Why. Why are things the way they are? Why can't they be different? (Why is closely allied to Why Not). This is a challenging question, that challenges the status quo and accepted wisdom, and opens the possibility of out-of-the-box thinking. It also ensures we fully understand the problem and the issues that create it. As Berger says:

Although we may think we have a brilliant idea in our heads for a new product, or a new answer to an old question, or a new way of doing an old thing, unless we understand why things are the way they are, we’re not yet on solid ground.

 Once we understand why things are the way they are, the next question is What If?  This is the question that opens new possibilities, not by concentrating on solutions, bit on vision. What If is a visionary leap. Berger tells us:

The What If stage is the blue-sky moment of questioning, when anything is possible. Those possibilities may not survive the more practical How stage; but it’s critical to innovation that there be time for wild, improbable ideas to surface and to inspire. If the word Why has penetrative power, enabling the questioner to get past assumptions and dig deep into problems, the words What if have a more expansive effect–allowing us to think without limits or constraints, firing the imagination.

The final question is the one that fills the gap between the understood current state and the blue sky future; it is the How question. How is the reality test, which Berger suggests we can best explore through trial and error, as we work our way towards the What If vision.

These simple questions, within a framework like Deep Dive, and accompanied by suspension of judgement, can form the basis of a solid innovation process. 

A great video metaphor for social knowledge "sharing"

The video below is a great metaphor for knowledge sharing. Or is it???

I use this video a lot in our Knoco Knowledge Management training courses. I have yet to find a better metaphor for connectivity within communities of practice and social networks.

BT used the video (about 5 years ago) to sell the concept of connectivity, and to show the possible power when large communities of people are connected and can interact.

However as you watch the video, make a note of the sort of interactions that take place, and then scroll down to my analysis below, to see if you noticed the same thing that I did.

Now scroll









Scroll a little more








Here you are

Analysis

Did you notice that almost every interaction, other than the last one, was driven by a Question?

• What's this groove called under my nose?
• Who wants to buy my fish?
• What do you think of our prototype?
• I love being a mum, but does anyone else sometimes feel overwhelmed?
• Did anyone here go to St Margarets school, Tobago, in 1952?
• I am looking to meet someone .....

Even that last one is a quesiton in disguise - "does anyone want to go out with me?"

Questions lead to rich interaction. Announcements don't.  

We can see this in LinkedIn, where the announcements-heavy groups have mostly become ghost towns, other than the few question-led examples. Announcement threads received on average 0.1 follow-up responses and comments. Threads that started with a real question received on average 13.5 comments.

Imagine the BT video, but where the interactions were all led by anouncements, and imagine how different the scenario would have felt. Imagine in each case it was the supplier of knowledge stood in the centre of the stadium, starting with the guy in the white coat announcing that "The groove under your nose is called a filtrum", and hoping that someone, somewhere might be interested. That would have been a far less compelling video.

The video is a great metaphor for knowledge seeking, rather than knowledge sharing. This is important - direct requests for help drive 75% to 90% of exchanged knowledge, and asking for help is a far tougher barrier than reponding and should therefore become the focus for our communication and culture change efforts. 

If you are taking the trouble to connect up the individuals in your organisation, by social media or in communities of practice, make sure that the interactions are question-driven wherever possible. 

How to stop your communities becoming LinkedIn-style ghost towns.

The LinkedIn groups are failing as a medium for community discussion. How do we stop communities of practice in our own organisation going the same way?

Discussion, by Alan Levine, on Flickr

I blogged a couple of weeks ago about how so many Linked-in threads start with a statement - and so receive few if any replies.  Now this same idea has appeared in the Huffington Post. 

The Huffington post article by JD Gershbein, entitled "The LinkedIn groups have become ghost towns", describes what he terms the demise of the groups. Seen initially as a technology to support discussion and knowledge sharing in global communities of practice, the groups have "devolved into a bottomless pit of shameless self-promotion".

Certainly the groups are becoming less about dialogue and more about monologue. When I analysed LinkedIn group discussions in 2011 I found that about 60% of the thread-starters were questions while 40% were statements, and that the threads started with statements received few if any answers, and sparked no discussion.  I repeated this analysis this year and found that only 10% of threads were started with a true question, while  90% started with a "notification"; someone sharing something, usually presented as a statement, but sometimes as a pseudo-question like"What's the best way to introduce social media? Read my website and find out".

The notification threads received on average 0.1 follow-up responses and comments. The 10% of the threads that started with a real question received on average 13.5 comments.  Questions promote discussion, but the percentage of questions is low, and falling.

So JD's view matches my observation - that the LinkedIn groups have not fulfilled their promise of being a discussion mechanism, but have become another avenue for people to promote themselves. Where people have questions, these are generally answered and may create some rich dialogue. However the questions are becoming fewer and fewer, and self-promoting notification more and more common.

Why has this happened?

JD suggests that an increased complexity and activity level in LinkedIn has turned people from contributors into browsers, compounded by the new LinkedIn moderation policies. However I think there may be something more fundamental. LinkedIn is, by its very nature, a forum for self promotion. You promote yourself through your profile and through your activity, and so find jobs and contracts.

This individualistic drive competes against the more social drive you would hope to see in the groups. People on LinkedIn like to be seen to have answers; they don't like to be seen to have questions. Over time the individualism has become the default culture, and the more the groups are filled with notifications, the less people feel like posting questions.

What can we do about it?

Obviously you don't want this to happen in your in-house communities of practice. We know from the Knoco 2014 KM survey that successful CoPs have a high ratio of Pull (questions) to Push (notifications), as the chart here shows. 

By these figures, the satisfaction rate with the LinkedIn groups should be very low. 

How do you avoid this problem?  Here are some clues. 

In 2011 I noted that one thread showed a really rich pattern of interaction  and discussion due to

"the involvement of the person who originated the thread and his activities in responding and reframing the discussion, and the social interactions he generated. He has taken the role of discussion facilitator, and as a result has a far longer and richer result".

Similarly  JD Gershbein picks an exemplar LinkedIn group where a moderator, Tsufit, provides active facilitation.

"She offers thought-provoking questions and comments that are designed to help members artfully and appropriately promote themselves. Tsufit actually serves in the role of a recruiter for her group, identifying good candidates through LinkedIn Pulse and other online media. “I seek out influencers, thought leaders, heads of organizations, speakers, and authors who are community-focused. Once in, they are not to do the old teach-and-preach. Instead, I encourage them to pose questions that will evoke a response.”

Similarly Clay Shirkey, in his blog post "a group is its own worst enemy" offers three conclusions to help the purpose of the group succeed over the purpose of the individuals;

1. As you can't 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.

You can do the same in your groups. 

• Set up a core group, a moderator and a charter
• Ensure the charter promotes questions and discussions over notifications and self-promotion
• Ensure the moderator plays an active role in weaving discussion
• Ensure the core group are active in monitoring behaviour, and driving questioning. 

In this way you can engage the community in discussion, and avoid the community forums becoming ghost-towns of self promotion. 

How to deal with "Blank Box fear" in enterprise KM technology

The best thing to do with a "Blank box" on social media, is to ask a question. 

I was reading a blog post recently on writers block on social media - the sort of mental block that hits you when faced with a blank box on Yammer, or a blank page on a blog.

• Should you post a status?
• Should you let people know what you are doing?
• Should you share something you have seen?

I think, if your aim is to promote conversation and knowledge sharing in your organisation, then you should do none of these things. Instead of notifications such as the examples above, you should ask a question. 

Questions generate far more conversation and engagement than notifications, as the following experiment shows.  I took a random sample of 77 LinkedIn discussions posted over the last few weeks in some of the Knowledge Management forums.  The statistics are interesting.

• 70 of those discussions started with a notification; someone "sharing something"
• only 7 of those discussions started with a question
• The average length of the discussion threads started with a notification was 1.1 posts; ie each notification received on average 0.1 comments. 65 of the 70 posts provoked no response. 
• The average length of the discussion threads started with a question was 14.5 posts; ie each notification received on average 13.5 comments.  No question was unanswered in the sample I looked at.

In fact there was more discussion in the question-led threads than in all the notification-led threads put together, despite there being ten times fewer questions. 

You can try this for yourselves, counting threads and posts on your own linkedin groups, or on your own enterprise social media platforms.  Notifications do not create conversation - questions do.

Just imagine if we started our real live interactions with notifications. Instead of "Hi, how are you? How are your kids? Did you see the match last night? What did you think?" it would be "Hi, I am well today.  I watched Aston Villa last night. I was disappointed by the match. My daughter has a sore throat".  Some conversation, eh?

So if you really want to get a buzz of conversation going on your enterprise social media, don't notify, don't "work out loud" just for the sake of saying something, don't be pulled in by the (wrongheaded) Yammer question "what are you working on".

Ask a question instead.  You may be amazed at the engagement it produces.

Pull or Push in CoPs, which works better?

Which works better in driving Community of Practice interaction - Pull or Push?

Community of practice interaction can be driven by pull or push - pull meaning interactions driven by knowledge seeking and by questions, push meaning interactions driven by publishing knowledge and posting articles and notifications.

Data from our 2014 global survey of knowledge management allows us to compare these two drivers, and to see which works better.

Those respondents who answered the section on communities of practice gave us two figures - a subjective assessment of community effectiveness (marked from 1 to 5), and an estimate of the percentage of community interactions driven by pull.

These two numbers are compared in the figure here.

The blue line shows the average community effectiveness for various ratios of pull to push. Effectiveness is lowest when pull is lowest (0% to 10%) and highest when pull represents between 51% and 70% of the interactions.

This effect is even more marked in larger CoPs of 1000 or more members (orange line), where satisfaction is highest when the pull ratio is greatest. In fact, only the large pull-driven communities of practice received an average "5 out of 5" effectiveness rating in the survey.

The conclusion is that your communities of practice should be driven more by pull than by push if they are to maximise effectiveness, especially the larger ones.

The challenge of Unknown Knowns

---

The unknown knowns are, in many ways, as tricky to deal with in Knowledge Management than the Unknown Unknowns. 

05.24.08 by Daniella on Flickr

We hear a lot (famously from Donald Rumsfeld) about the unknown unknowns, and how difficult they are to deal with, and in knowledge management terms, they can be a real challenge. However an equally challenging issue is the unknown knowns. These are the things that people know without realising – the unconscious competencies. These are very often the deep-lying technical knowledge that is of real value to other.

But how can someone share knowledge if they don’t know that they know it?

An example comes from when I was teaching my daughter to drive. To start with, she did not know what she did not know. The whole topic of driving was a closed book to her. However, once she was behind the wheel, she began to be aware of the things she needed to learn. Now I have been driving so long (36 years), that I drive automatically, without thinking. I know how to do it, but I am not conscious of what I am doing much of the time. I don't know what I know any more. So when she asked me complex questions such as “when changing gear going down a steep hill, do I put my foot on the clutch before I put it on the brake, or do I brake first?” I had to think for some time, and often I had to get into the driving seat, go through the manoeuvre, and analyse what I was doing in order to become conscious of it, before I could explain it to her.

The people who have the knowledge, are often unaware that they have it, like me and driving. The people who need the knowledge may often be unaware that they need it. Without an effective process to address the unknown knowns, the crucial knowledge may never get transferred. We need a process of helping people know what they know.

Questions are the route to the unknown knowns.

We have already seen the process from my driving example – the process is questioning.

There is a saying in the Middle East – “Knowledge is a treasure chest, and questions are the key”.  The person who needs the knowledge asks the difficult question, and starts the process of discovering the unknown knowledge.

The most effective means of knowledge transfer is through dialogue – via questions and answers. Through a question and answer process, the knowledge supplier becomes conscious of what he or she knows, and once they are conscious, they can explain or demonstrate to the learner. The explanation or demonstration can be recorded and codified and made explicit.

This works for teams as well. Teams have an unconscious competence in the way they work effectively together. Not only do the individual team members not know what they know as individuals, they doubly don’t know what the other team members know. So before you can start to capture or harvest any knowledge from a team, you need a team Q&A dialogue, carefully facilitated, such as After Action review or retrospect. Once you start the dialogue, and start discussing the reasons behind why things happened, the team will often piece together the learning as a group activity.

The "self-submission" trap.

Now imagine that you did not use dialogue or questions, and instead that you asked the team members to write down what they know. You would never get the unknown knowns, and you would never get at the double unknown secrets of team delivery.

And yet many organizations expect just that – individual submissions – as a feed into their knowledge base. And then they wonder why they don’t get the value.

Instead, you should aim to make use of the dialogue-based processes,

Interview
After Action review
Peer Assist
Retrospect

Use these as your primary means to help competence to become conscious, to help the knowns to become known, and to start to generate some content of real value.

---

Care needed when "working out loud"

---

LOUD speaker by woodleywonderworks on Flickr

There is a lot of interest in "Working out loud" and "narrating your work" at the moment. Here are 4 things you need to watch out for, to ensure this approach adds value to the organisation.

"Working out loud" (WOL) is, at first sight, a simple and attractive idea. Social Media and group-ware enable us to narrate what we are doing so that others can be aware (and so avoid duplication and offer insights), and to put our work products in common areas so that others can re-use them and build on them.

Indeed, tools such as Yammer encourage WOL, by prompting you with the question "What are you doing today?"

However there are a number of ways in which WOL, taken superficially, can go badly wrong, as shown by a case study at the end of this post.

Here are 4 pitfalls you need to address.

1. WOL must address demand as well as supply - Pull as well as Push.

Although WOL greatly increases knowledge sharing, the goal of Knowledge Management is not Knowledge Sharing but Knowledge Use. KM is ultimately about giving people access to better knowledge that will solve their problems, and setting a culture whereby they want to find and use that knowledge.

Knowledge re-use requires knowledge demand, and not just supply.  People need to be actively seeking and asking, as well as actively telling and sharing. Any unbalanced market, where supply exceeds demand, leads to a crash in the value of the commodity (in this case, knowledge). Conversely where demand exceeds supply, the value of the commodity rises. Demand stimulates supply; supply does not always stimulate demand.

WOL can fail when it becomes only a mechanism for Telling - telling people what you are doing, telling people what you have done - a supply mechanism only.

If WOL is going to work, it needs to refocused as Asking Out Loud, or Questioning Out Loud. A sharing culture needs to be replaced by (or augmented by) an Asking Culture.  In-house Yammer should be asking "What do you need help with today?". This way WOL becomes a demand-side mechanism.

Remember Shell's maxim of "Ask, Learn, Share" and remember that they prioritise them in that order.

Don't replace "Ask, Learn, Share" with "Tell, Tell, Tell"

There is often an assumption that telling what you are doing, and sharing work in progress, tacitly invites commentary, and is a proxy for seeking and asking. If you are doing something wrong, the assumption is that someone will correct you without you having to ask. The reality is determined by culture, and in many cultures around the world people hesitate to correct someone unasked, or to offer unsought feedback.  If you want commentary then Ask, don't just Tell.

2. WOL creates "just-in-case" knowledge, not "just in time".

WOL, applied incorrectly, becomes a set of answers looking for a question. You narrate your work "Just In Case" someone is interested. You store your work products "Just In Case" they are of use to someone.

However we know that KM is most effective when it operates through "Just In Time" rather than "Just In Case". People don't know what they need to know, until they need to know it (this is one of the demand-side principles of Knowledge Management), and when they need it, they need it NOW.

There are cases where Just In Case knowledge is valuable, namely when you are sure that such a case will recur, and that people will come looking for the knowledge. In situations like this, knowledge is "because we will" knowledge. Such knowledge should be synthesised into knowledge assets tailored to the needs of the user. Just creating compilations of work produces will not be as useful.

3. Noise drowns out signal.

Imagine you are one of 100 people working out loud. Your piece of knowledge might be useful to one of those people. For the remaining 99%, it is noise.  You are putting the onus onto the user to filter out the signal, rather than removing the load from the user. Given that re-use is the biggest challenge in KM then anything that adds barriers to re-use is counter productive, and that includes the noise to signal ratio.

Unwanted knowledge is of no value - it is just noise (until the time when it IS wanted, of course). Wanted knowledge - sought knowledge - is of immediate value.

You can reduce noise by working out loud within communities of practice.  This is a way to focus your sharing - narrating only within a community of people doing the same sort of work as you, who therefore are more likely.  Even better, reduce noise by sharing what is essential and useful.

4. What you are doing, and what you have produced, is not the same as what others should do or produce.

Until you have finished a piece of work and tried the result in practice, you don't know whether what you did was the right thing to do. Any piece of work - a bid, an intervention, a project, a product, a business plan - can only be judged by whether it achieved its results. Therefore narration of work on its own is of little value to others, just as sharing work products is of little value to others. What you should be sharing is the results of reflection on your work; the things you should have done, the things you would do if you were to do it over, and the things you recommend others do.  This is more like coaching out load than working out loud.

And beyond this - if knowledge is, as described above "because we will" knowledge, then such knowledge should be synthesised into knowledge assets tailored to the needs of the user. Just creating compilations of work products will not be as useful; you end up with a mass of material to wade through, some of it out of date, some of in contradictory, some of it wrong.. If knowledge is important, then it requires some investment in synthesising results, insights, and the current best work products, in order to create the best resource base possible for the knowledge user.

When WOL goes horribly wrong.

Here is a story about a company that takes the ideas of "Public sharing" to excess. They were not strictly Working Out Loud, as much of what they shared was finished product rather than work in progress, but their Knowledge Management approach was very much "Tell, Tell, Tell" with little evidence of Learning and no evidence of Asking. They were "Telling out loud" what they had done.

This company had introduced

• A blogging platform for all staff
• Incentives for blogging and publishing. Directors and other senior staff were taking the lead, people ranked each other's blogs, and star bloggers were given prominence and recognition. Blogging was therefore pursued enthusiastically
• A platform for publishing work product articles, again linked to recognition. 
• Many blog posts were repeats of these articles 
• A wiki platform. Much wiki content was repeated on blogs, or duplicated the contents of articles. There was no synthesis of knowledge on the wiki; no creation of Knowledge Assets.
• A discussion forum, used for announcements. Many of the posts were notifications of new articles.
• A microblogging platform, mostly used for narration, and for notification of new blogs, articles and wiki pages 

Activity levels were enormous, driven by powerful incentives. The re-use rate for this mass of material was miniscule -  less than 0.7%.

The net cost to this large organisation was about 42 mandays per day in publishing, checking, reading and maintaining material that will never be re-used, and will seldom be read. There would be big savings in abandoning the system entirely.

This company was fantastic at knowledge sharing and lousy at knowledge re-use. They "Told out loud" to deafening levels, and lost value as a result.

What to do instead

• Ask out loud and Question out loud, so others can Answer out loud. Aim for a culture of asking. Ask before doing. Fill in the knowledge gaps that you are aware of before you start your work, then ask others whether there is anything else you are missing.  
• Share your knowledge and insights, not your actions and products. Reflect in your teams about how effective your work was, and share the results of the reflections. Share what you think others should know, not what you yourself did.  Coach out loud.
• Aim for "Just in Time" knowledge and "Because We Will" knowledge, rather than "Just In Case" knowledge.
• Narrowcast your questions and your knowledge to those most likely to need to know, within the relevant communities of practice.

Above all, avoid the pitfall of "Tell, Tell, Tell"

What would you do differently? The Killer Question.

---

It’s been an interesting few weeks, with client work in China, Belgium and Frankfurt followed by two great days at the excellent KMUK conference.

The great thing about a conference is it always gives you time to reflect, things to reflect on, and different viewpoints from which to look at the world of Knowledge Management. At one point in the conference yesterday, after a first class presentation by Stuart Jackson of Actis, somebody from the audience asked the question “If you were starting your knowledge management work all over again, what would you do differently?”

This is a question that we use all the time in After Action Review and Retrospect, but it suddenly struck me that this was the first time I had heard this question asked at that particular conference. Then it also struck me that, in many of the client interactions I had been watching this week, this question had been asked only rarely (and mostly by me).

Many times people in the client teams, or people at the conference, would ask each other “what did you do, how did you do X, how did you respond to Y”, and what they would get in reply would be, effectively, history. The replies would help you understand what the team did, but not understand whether this is a good thing to do, and bad thing to do or a random thing to do. However when Stuart was asked “what would you do differently”, he couldn't answer with history; he had to answer with analysis.

History is not knowledge. It is analysis of history - it is reflection on history – that creates knowledge. We need to ask, not just “what did you do”, but also “with reflection, what would you do differently” if we are to get a true knowledge.

By the way, at the conference, Stewart’s answer was (and I paraphrase) “I would spend less time building content databases, and more time helping to generate value, and create new deals, for the business”.