Why conversations are so important in KM.

All forms of Management involve conversation, and Knowledge Management is no different.

The management of intangibles is driven by conversations. Those conversations are focused on the particular intangible in question, and serve to set direction, raise awareness, and lead to action.

• Risk management is driven by conversations about risk; conversations to identify risks, conversations to map and characterise risk, and then actions to ensure the risks are well managed;
• Safety management is driven by conversations about safety; Hazops to identify safety issues, conversations about safety mitigation, and then actions to ensure personal and process safety;
• Talent management is driven by conversations; from conversations to identify talent requirements and strategy, through conversations to identify job requirements, to conversations with talented individuals.

Knowledge management is also driven by conversations, or by dialogue, about knowledge.   Steve Denning said at the Ottowa KM summit in 2006 that the learning capacity of an organisation is directly related to it's ability to hold conversations, but we need to go beyond this, and say that these conversations need to be conversations about knowledge. Not normal conversations such as project meetings or status updates, but deliberate conversations with knowledge as the focus.

Conversations about knowledge. 

We can probably divide these into two types of conversations;

1. strategic conversations about knowledge strategies, knowledge needs, knowledge frameworks and knowledge flow, and 
2. conversations designed to identify, build, synthesise and transfer knowledge. As I said on this blog, KM is as much about conversation management as it is about content management.

Actually, when it comes to the second type of conversation, the operative word is probably not "conversations" but "Dialogue". Dialogue is probably the single most important component of effective knowledge management.

All my favourite, most powerful knowledge management processes are dialogue-driven. It's the dialogue that allows people to reach a shared understanding of "what have we learned".

• Peer Assist is a dialogue to exchange and acquire knowledge at the start of a project. 
• After Action Review is a ongoing, regular learning-based dialogue within a working team. 
• Retrospect is a detailed dialogue at the end of the project to identity and clarify the team learnings. 
• Knowledge exchange is a multi-person dialogue within a community or between two teams.

Make sure that your KM program involves all the right conversations about knowledge, as this is the way that intangibles get managed.

The importance of Conversation Management in KM

Why do we hear so much about Content Management in Knowledge Management, and so little about Conversation Management?

Image from wikimedia commons
CC licence
Attribution Dean Calma, IAEA

Happy New Year to all readers of this blog.

I have been blogging about Knowledge Management topics on an almost daily basis since early 2009 (weekdays that is, excluding holidays, and times when I was in China with no access to Blogger). As a result this blog has nearly 3000 posts, and it's beginning to be really difficult to find something new to say.

So from this point on, I will blog on a weekly basis, and many of the posts will be a reworking of older themes.

Today I want to talk about the Content/Conversation dimensions of KM, or  Collect/Connect as it is often known, or Codification/Personalisation as the old HBR article described.

I want to ask the following question:

If the subject material of KM is both Content and Conversation, why do we hear so much about Enterprise Content Management, and so little about Enterprise Conversation Management? 

We know that knowledge is either tacit or explicit - either in the heads, or codified. We know also that there are two parallel approaches to KM - the connect and collect approaches (connecting the people, collecting the knowledge). We know the means of knowledge transfer through connect and collect are conversation and content.

Yet increasingly the content gets the lions share of the attention. 

• KM World describes Content Management as the Third Age of KM, with the Fourth Age being the even more content-focused Knowledge Graphs
• Our KM surveys show "Better Access to documents" overtaking "Connecting people in communities and networks" as the primary approach to KM
• The term Enterprise Content Management gets nearly 4 million hits on Google. There is almost nothing on Enterprise Conversation Management (just over 1000 hits).
• OK, that last one is a bit ingenuous, as ECM is a recognised term. However a search of "knowledge management" plus "content" gets 27 million hits, compared to 2.5 million for "knowledge management" plus "conversation".

Why does the content get so much more attention than the conversations?

I think its possibly because content is far less messy to manage than conversation, and so much easier to automate. Also there are far more vendors working in the content space than in the conversation space, and you can do fancy things with content analysis. Conversation on the other hand is difficult to automate, and there are fewer vendors in this area. It often needs human facilitation or moderation to work well, or even to set up the conversations in the first place. Conversation management is harder and needs more human resource.

However conversation is as vital as content in KM, and in some cases, more so. 

• It is generally accepted that the amount of tacit knowledge within an organisation outweighs the amount of explicit knowledge (figures of 80% tacit, 20% explicit are often quoted), and conversations are one of the most reliable ways of accessing tacit knowledge. If you manage content only, you only manage 20% of the knowledge. 
• The classic study of  Haas and Hansen showed that for a bid team to reuse content from other teams was helpful in one one out of the 4 scenarios they described and actually harmful in the other three, while a conversation with experienced colleagues was helpful in 3, and harmful in only 1 of the 4 scenarios. 
• If you use a few common dictums or principles, you can conclude that transferring knowledge through conversation is 14 times more effective that transferring it in written form. (Having said that, conversation is probably at least 14 times less efficient than use of content, but KM is not all about efficiency).
• The remote working forced on us by COVID 19 has already shown that the impossibility of informal unplanned workplace conversations is most likely taking its toll on knowledge, with an impact on innovation capacity.

So focusing on content because it is easier to handle is rather missing the point. You ignore 80% of the knowledge, add value only in 25% of the cases, and are 14% as effective. It's the "Streetlight effect"; doing something because its easier rather than better, named after the old story of the person seeking for their lost car keys under the streetlight, not because they lost them there, but because its easier to look.

Conversation should therefore as much at the heart of our KM frameworks as content.  For example:

• Conversations within communities of practice, through which practices are discussed and shared, and problems solved - either online or face to face conversations such as Knowledge Exchange
• Conversations between experienced and less-experienced staff, as part of coaching, mentoring, and job handover
• Conversations within project teams to identify shared lessons, such as Retrospects and After Action Reviews
• Conversations between one project team and other teams, such as Peer Assist, Knowledge Handover and informal one-on-one conversations based on knowledge needs and knowledge gaps, to ensure Projects operate from a state of "full available knowledge". 

These are knowledge-specific conversations, all of them dialogue-based, and therefore different from action-specific conversations such as briefing and reporting, and different from the typical broadcast notification traffic seen on some examples of social media.   It is through these dialogue conversations that tacit knowledge is brought to light, shared, and co-developed. Managing, structuring and facilitating these conversations - making them routine, efficient, powerful and deep -  is a crucial element of knowledge management.

Content and Conversation are the King and Queen of Knowledge Management - they rule together. Content is something to talk about, Conversation is where Content is born and where it is tested. As Knowledge Managers, we should focus equally on both.

Please don't neglect Enterprise Conversation Management - pay it as much attention as Enterprise Content Management as part of a balanced KM approach, especially now COVID requires us to plan our conversation far more than we used to.

Do you always need conversation as part of KM?

There are 3 unusual cases where conversation is not important to KM, but they are rare!

Conversation, by Valery Kenski, on Flickr

This blog has often argued that conversation is as important as content in KM, that conversation is at the heart of effective knowledge transfer, and that without conversation it is difficult both to access the deep unconscious learning, and also to check whether the knowledge customer properly understands the knowledge that has been offered. 

However many companies operate knowledge transfer systems, such as lessons databases or knowledge bases, which involve no conversation at all.

Do these work? Under what circumstances can they work? Here are 3 cases

 1. Conversation-free knowledge transfer is perfectly acceptable when the context of the knowledge is very clear.

Take the example of cookery books; these are a very effective means of transferring the knowledge of how to cook certain dishes. The context of cooking a meal is a clear context, shared between the author and the reader. However if you move outside that context, for example moving to another country where the ingredients and measures are different, or opening your house as a pop-up restaurant, the results may be disappointing. If you want to move to a more creative context, you will probably take cooking classes and discuss what you are learning with a professional chef. 

2. Conversation-free knowledge transfer is perfectly acceptable when the nature of the knowledge is very limited. 

 Take the example of road maps; these are a very effective way of transferring the knowledge of how to navigate from one place to another. Most motorists have a road map in their car, or a sat-nav on their phone. But for more complex knowledge, like the details of finding a specific house down country roads, you need the advice of people with local knowledge (see my blog post on Charts and Pilots; charts are fine on the open sea, but every large vessel entering port uses a pilot to travel the last mile or so).

2. Dialogue-free knowledge transfer is perfectly acceptable when the knowledge is very mature at user-level. 

When a topic is mature, everything is known. We know all the questions that can be asked about the topic, and all the answers.  All of this can be fully documented, for example in an online FAQ or knowledge asset.  Even then, there will be advanced-level nuances which experts may still need to discuss, but for the average user, this knowledge can safely be codified.  However if a topic is not fully mature and is still evolving, then the answers in the FAQ may change, and new questions may arise. There will be knowledge that is needed that is not yet "in the manual" and will need to be exchanged through dialogue.

However in every other case, other than the three exceptions above, your Knowledge Management framework needs to focus on Conversation as well as on Content.

Content and Conversation - equal and complementary focus areas for KM

I  blogged recently about Connect and Collect - the two parallel approaches to transfer of knowledge. Now let's look in more depth about the two modes by which knowledge is carried - Content and Conversation. 

Kids of conversation by Kris Hoet on Flickr

During the Connect approach we facilitate the transfer of knowledge through Conversations, whether these are online conversations or face to face meetings.

During the Collect approach we facilitate the transfer of knowledge through captured and codified Content in the form of documents, files, text, pictures and video.

We also know that Conversations are a far richer medium than Content, potentially 14 times richer, though Content can reach far more people, and has a longer life-span than a conversation.

Any comprehensive Knowledge Management framework needs to enable, promote, facilitate and otherwise support both Conversation and Content.

Focusing on conversation and focusing on content are not alternative strategies, they are complementary and interlinked. Neither approach is sufficient on its own (although the content-only focus seems very common), and each relies on the other.

Managing conversation without content leaves no trace, other than in the minds of the people involved. That in itself is useful, and we know that most of the processes of Knowledge Management, such as Retrospect, After Action Review, Peer Assist and so on are valuable individual learning experiences. But managing conversation without content is not a valuable organisational learning experience. Unless new knowledge becomes embedded in process, or guidance, or recommendations, it is never truly "learned", and without this we find knowledge becomes relearned many times, with errors being repeated, wheels reinvented and so on.

Managing content without conversation leads KM towards the already established fields of Content Management and Information Management, and you could (as the author of the famous "Nonsense of Knowledge Management" did) challenge what KM adds over and above these other disciplines. A focus on content without conversation results in a focus on publishing; on creation of reports and files, blogs, wikis, as a proxy for the transfer of knowledge; on Push rather than Pull. But unless people can question and interrogate knowledge in order to internalise it, learning can be very ineffective, and this approach always seems to deteriorate into technology, search, and the perennially soon-to-be-delivered benefits of AI.

There is a saying in social media circles that "Conversation is King, Content is just something to talk about". Like any other dualism-based statement, this is wrong. Knowledge Management, as a field, is far more "both/and" than it is "either/or".

Content and Conversation are the King and Queen of Knowledge Management - they rule together.

• Content is something to talk about
• Conversation is where Content is born and where it is Tested.

As a Knowledge Manager, please focus equally on both, and please do not assume that all Conversation needs to be by written means. Face to Face is still the preferred transfer mechanism for high-context knowledge, and "getting people together to talk about what they know" is an amazingly effective tool within your Knowledge Management Framework.

Make sure you promote and support Conversation and Content as equal partners in your KM Framework. 

Why a conversation with experienced colleagues is better than re-using captured knowledge

There are some circumstances where re-using captured knowledge is helpful, but many more where a conversation with an experienced person is a better option.

I have referred a few times in this blog to a very interesting paper by Martine Haas and Morten Hansen, who look at success data from bid teams in an international service organisation to find out when collaboration actually helps performance.

They looked at the context of the teams and the types of bids they were addressing, and at two types of collaboration; how much they accessed and re-used documents from previous bids (which they called "codified knowledge"), and how much they sought advice from experienced colleagues outside the team ("personal knowledge"). They then looked at bid success rates, to give an objective measure of the VALUE of the knowledge to the team.

The results are shown in the graphs here, and summarised in the table below. The terms Haas and Hansen use as "high/low need to learn" refers to whether the bid teams were experienced (low need to learn) or inexperienced (high need to learn). Also "high/low need to differentiate" refers to whether the bid they are working on is standard (low need to differentiate) or non-standard (high need to differentiate).

They found that the value of reusing knowledge or of a conversation with experienced colleagues varied with the circumstances of the team and the bid.

Context	Re-use of codified knowledge	Conversation with experienced staff (personal knowledge)
Experienced team, standard context	Harmful	Harmful
Experienced team, non-standard context	Harmful	Helpful
Inexperienced team, standard context	Helpful	Helpful
Inexperienced team, non-standard context	Harmful	Helpful

What we can see from these results is that re-using codified knowledge is actually harmful to success in 3 out of 4 cases, while a conversation with an expert is helpful in 3 out of 4 cases. 

This is a message to all of us working in KM - that codified knowledge alone will not deliver the full value from KM, and that conversations are also needed if we are to make the most of corporate knowledge.

Conversation and content are the two sides of KM, and Haas and Hansen's results show that conversation is the more useful of the two in many contexts. 

Management by Talking About

Part of the way you manage issues such as risk, safety and knowledge, is by creating times and processes for talking about them.

Steven Denning, at the Ottowa Knowledge Management summit a few years ago, said that the learning capacity of an organisation is directly related to it's ability to hold conversations, and I truly believe he was right.

When dealing with the management of intangibles such as knowledge, much of the process of management will be through conversation (conversation leading to action).

For example, Safety Management is driven by conversations about safety, in order to drive awareness of safety issues and identify mitigating actions. Similarly Risk Management is driven by conversations about risk, in order to drive awareness of risks to projects and to identify mitigating actions.

Similarly knowledge management is driven by conversations about knowledge.

All of the most powerful knowledge management processes are driven by conversation - especially dialogue.

• Knowledge management planning is a dialogue about "what knowledge do we need", in order to identify learning actions. 
• Peer Assist is a dialogue to exchange and acquire knowledge at the start of a project, in order to identify improvement actions for the project. 
• After Action Review is a ongoing, regular learning-based dialogue within a working team, to identify improvement actions for the team. 
• Retrospect is a detailed dialogue at the end of the project to identify and clarify the team learnings, and the improvement actions for the organisation. 
• Knowledge exchange is a multi-person dialogue within a community or between two teams, in order to collectively make sense of experience, identify the learnings, and determine the process improvement actions.
• Communities of practice are systems for dialogue amongst practitioners of a topic or domain.

As Steve Denning might have said, the learning capacity of an organisation is directly related to it's ability to hold conversations about learning.

Why Dialogue is at the heart of Knowledge Management

Dialogue is the engine behind Knowledge Management - it is the primary means by which Knowledge is shared and absorbed.

We often assume that connecting people together will lead to better knowledge exchange, but connecting wires doesn't necessarily make a circuit. You need a way of ensuring conductivity as well as connectivity, and dialogue provides that conductivity for knowledge.

Dialogue is different from other forms of conversation. In a Dialogue, the participants are trying to reach mutual understanding. It is a process of exchange of views and of knowledge, of both sides asking questions and of listening to the answers. It is a combination of listening, advocacy, reasoning and consensus-seeking. It is hard to imagine effective knowledge exchange without some form of dialogue.

• Dialogue differs from argument, which is all about presentation and advocacy of views. There are no winners or losers in dialogue; you can't say "I lost the dialogue with Peter”.
• Dialogue differs from debate, which is all about testing the validity of a proposition rather than testing whether it is understood.
• Dialogue differs from interrogation, where all the questions are one-way, and only one person stands to profit from the exchange.
• Dialogue differs from discussion, which is often about analysis of detail rather than searching for common understanding.
• Dialogue differs from reporting, which is the presentation of facts rather than the search for common understanding.

We need dialogue because of the  unknown knowns, the deep knowledge of which people are unaware.  The person who has the knowledge (the "knowledge supplier") may only be partially conscious of how much they do know. The person who needs the knowledge (the "knowledge customer") may only be partially conscious of what they need to learn. The unknown knows and unknown unknowns are only uncovered only through two-way questioning; in other words through dialogue.

Dialogue is needed, in order to

• Help the knowledge supplier understand and express what they know (moving from superficial knowledge to deep knowledge)
• Help the knowledge customer understand what they need to learn
• Transfer the knowledge from supplier to customer
• Check for understanding, and
• Collectively make sense of the knowledge

The knowledge customer can ask the knowledge supplier for details, and this questioning will often lead them to analyse what they know and make it conscious. The knowledge supplier can tell the customer all the things they need to know, so helping them to become conscious of their lack of knowledge. As pieces of knowledge are identified, the customer and supplier question each other until they are sure that transfer has taken place.

Almost all of the effective Knowledge Management processes are based on dialogue. 

AARs, Peer Assists, Knowledge Handovers, retrospects, Harvesting interviews, Learning Histories, Knowledge exchange - all are dialogue based. All of these processes are facilitated, and part of the role of the facilitator is to ensure dialogue rather than argument or monologue.

Some of the elements of dialogue can be done remotely through Web 2.0 tools, though this needs to be done deliberately. We can't assume that dialogue "just happens" over social media, any more than we can assume that a conversation will be a dialogue.

• Blogs are 95% monologue, and although some dialogue can be sparked through blog comments, it's more often debate than dialogue. However examples such as the Polymath project suggest that a structured approach of Blogs and Wikis can lead to problem-solving through dialogue
• Community discussion forums can occasionally engender dialogue, but again, debate and argument are often found in there as well. 
• Social media promote conversation, but not necessarily dialogue. The conversations in LinkedIn, for example, are mostly serial monologues, where people post their own views while seldom seeing to understand the views of others
• Wikis allow co-creation, but not through a dialogue format, which makes them difficult for really contentious or emergent topics. 

So how do we promote dialogue as part of our knowledge management programs?

1. We deliberately promote, even to the extent of educating people in, the behaviours of listening and questioning, as part of a Knowledge Management and Organisational Learning Culture.
2. We introduce the facilitated processes mentioned above
3. We ensure our Online communities of practice are also guided and facilitated, to promote dialogue instead of argument
4. We train the facilitators well.

We move beyond just "connecting people", and look at the nature of that connection, and the nature of the conversations that result. Good facilitation is key to helping this happen.

Should you allow people to be anonymous in company online forms?

Is anonymity a good thing in online organisational (in-company) knowledge sharing forums? I suggest it is not, and my reasoning is below.

Public domain image from SVG

When you first set up knowledge sharing forums, it can be tempting to allow people to contribute anonymously, to reduce their fear of exposure. But is this a good idea?

Please note I am not talking about public forums, where people may want to talk about personal problems - relationships problems, abuse, addiction - which they do not necessarily want their family and neighbours to know about. Nor am I talking about anonymous activism, or Wikileaks. I am talking about knowledge-sharing communities of practice as part of an organizational Knowledge Management framework.

There are arguments for and against anonymity, and lets look at those first.

Arguments for anonymity

• In a toxic culture, where knowledge is power, it can be a risky act to challenge the status quo. To ban anonymous comments, is to remove the possibility of honesty. An anonymous forum creates a safe space for knowledge sharing.
• In a non-Western culture, where admitting mistakes is not acceptable, it can be very difficult for people to admit they don;t know, and to ask for help. Anonymity again gives a safe space for asking.

Arguments against anonymity

• People are more likely to share positive knowledge if they get credit for it (see my blog post on keeping the name with the knowledge).
• People are more likely to use the knowledge if they trust it, and if they trust the source. I remember, when testing an anonymous knowledge asset in an organisation, how people responded "Why should we trust this, if we don't know where it comes from".
• It is very difficult to learn from the written word. Most effective knowledge systems allow you to find the contributor of a lesson, a good practice or a document, and to speak with them to learn more. With anonymity, this is not possible.
• If the culture is difficult, toxic, or intolerant of mistakes, then an anonymous forum  acknowledges publicly that you have to be anonymous to share knowledge, and so to an extent perpetuates the culture. Conversely, if people can see knowledge being shared openly by brave souls, and those brave souls being praised and rewarded for it, then you have the potential to change the culture.

That last one is the clincher for me.

If you need to be anonymous to share knowledge in your organisation, something is badly wrong. Work with the culture, sure, for example providing named individuals who can share your knowledge for you if you are not brave enough, or provide alternative safe spaces where knowledge can be discussed and shared without anonymity, but don't reinforce a bad culture.

Instead, seek to influence it; seek to change it.

5 types of conversation - only one works for KM

Knowledge Management is a combination of content management and conversation management, but which sort of conversations do we need?

Let's talk, by Ron mader, on Flickr

Conversation is widely recognised as the best Knowledge Management tool there is. Tacit knowledge and true understanding can be shared through conversation, but not through every type of conversation.

The problem is that conversations do many things, and knowledge sharing is only one of them. Understanding how conversations work, and being able to influence conversations styles through facilitation, are vital tools for the knowledge manager.

Here 5 common types of conversation. This is not an exhaustive list!

• Small talk. Small talk is the social communication where the fact of communicating is more important than the words. "Hi, how are you? What a nice day!" all really mean "I see you, I recognise you, I have, or want to create, a social bond with you".  Banter is one type of small talk. Gossip is another (though gossip is also a form of reporting and debriefing). Much of the interaction we see on Facebook, for example, is small talk (lol). Small talk has a vital social role, but does not share knowledge.

• Social cohesion. Social cohesion conversation is like small talk, but the purpose is to gain social cohesion through agreement. Reminiscence is a social cohesion tool - "Hey, do you remember when .... Did you see that moment in the second half of the game where he ....". The "Like" button is a social cohesion tool - "I am on your side". The problem with social cohesion conversation is that it can completely mask the truth. The Solomon Asch experiment showed how social pressure means that individuals will often agree to something they know to be incorrect, in order not to disagree with the rest of the group - not to be "off-side". Facilitators in knowledge management sessions such as Knowledge Exchange and Peer Assist need to be very much aware of the social cohesion aspect, and actively search for the dissenting voices. The only "side" to be on, in knowledge sharing, is the side of the truth.

• Reporting and debriefing. These are conversations (or more often, serial monologues) where people state facts and occasional opinions. Most project meetings are like this. These meetings are vital to have, but are only very superficially "knowledge sharing" meetings. Facts are shared, deep understanding generally is not shared. People go away "better informed, but none the wiser". If reporting and debriefing is the only type of conversation which happens in your projects, you need to introduce some  different processes, such as After Action Review, and Retrospect.

• Argument and debate. These are the "win/lose" conversations. Someone has an opinion, and defends it against alternative opinions. Very often this is tied into the issue of status - "I am the expert - my opinion must be defended as it gives me my status; if I lose the argument my status will be weakened". Debate is a milder form of argument, but both debate and argument carry the concept of winning. In debate and argument, people listen to and question their opponents statements in order to find weaknesses and loopholes. Many of the discussions on Linked-In are arguments, debates, or serial monologues. Argument and debate are hopeless for knowledge-sharing. As Thomas Jefferson said - ""I never saw an instance of one of two disputants convincing the other by argument." The body language in the picture above suggests that this is a debate or argument.

• Dialogue. As described in this HBR article, dialogue is the primary tool for knowledge sharing in organisations. The goal of dialogue is not winning, nor convincing, nor agreeing, but reaching a deeper level of collective understanding. In dialogue, people listen to and question the statements of others in order to understand why they hold these views. Dialogue requires listening skills as well as debating skills. In dialogue, people allow their opinions to be challenged (and indeed, welcome that challenge). In dialogue, everyone leans in to the conversation. Dialogue requires trust and openness. Dialogue is a very difficult conversational style to achieve, and until it becomes second nature in an organisation, the role of the facilitator may be vital. The facilitator watches the conversation, defuses argument, challenges group-think, ensures assumptions are questioned, seeks out the dissenting voices and the unshared opinions, and keeps the process of the conversation on track to it's stated goal - that of building shared understanding. 

Without good facilitation, dialogue can easily degenerate into debate and argument, or even further into opinion-stating, social cohesion and small-talk, and the opportunity for effective knowledge sharing is lost.

Ensure you focus on Dialogue as part of your Conversation Management

Contact us for KM process facilitation, or for facilitator training.

Extending SECI - 9 transitions of knowledge transfer

The SECI model is a common model in KM. This blog post from the archives suggests a way to expand this model.

One of the basic models of Knowledge Management - often discussed, frequently challenged - is Nonaka and Takeuchi's SECI model. This is a 2x2 matrix, looking at the transitions between tacit and explicit knowledge (and the challenges to the model is often whether tactic knowledge can ever be made explicit, or whether it needs to be, or whether explicit knowledge is the same as documented knowledge).

I would like to extend this model, because when we start to work with Knowledge Management in organisations, we find that knowledge actually lies in three natural states rather than two, and that we therefore need a 3x3 matrix rather than a 2x2.

The three states are as follows;

1. Unconscious "Knowledge in the head" - the things you don't know you know.
2. Conscious "Knowledge in the head" - the things you know you know (of course the boundary between states 1 and 2 is gradual, and more of a transition than a boundary).
3. Recorded Knowledge (captured in documents, audio, video etc).

The most powerful knowledge - the deep knowledge  that experts possess - is in state 1. However if knowledge is to be transferred easily between people, it may need to change it's state in order to allow transfer. The 3x3 matrix above represents the 9 possible transitions.

The dark blue squares are where Knowledge Management traditionally focuses (you can see that traditionally we only cover about half of the diagram).

It should be stressed that  every one of these transitions involves loss of value and loss of knowledge. We know (unconscious) more than we can say (conscious), and we often say (conscious) more than gets captured.

Here are the 9 transitions or transfers.

1. The transition from one person's unconscious knowledge to another's can be called "Emulation". This is how a baby learns, or how a craftsman can pass deep knowledge to their apprentice - by working together over years, often wordlessly. This is effective but very slow.
2. To make unconscious knowledge conscious requires some form of analysis - usually self-analysis, as the knower has to be deeply involved in the process. Group self-analysis, or sense-making, is a powerful technique, and a good interviewer, facilitator, coach or psychotherapist can also help make knowledge conscious. Coaching and mentoring is a useful tool in this box, as are team reflection exercises such as After Action review or Action Learning.
3. To record unconscious knowledge is difficult. About all you can do is record what the knower does - through videoing them at work for example - for later analysis. But to be honest, it's not yet knowledge, as all these recorded work products have to pass back through an analysis step in order to draw out the conscious knowledge. Maybe you can call the things in this box "latent knowledge".
4. The transition from conscious to unconscious knowledge is habituation. At one time you were conscious of your golf swing, your fishing cast or your ability to drive a manual car, but over time it becomes unconscious.
5. The transition between one person's conscious knowledge to another's often comes through conversation and discussion (particularly dialogue), and through techniques such as demonstration and teaching. Here is where discussion processes and structures such as Communities of Practice and Peer Assist become useful.
6. The transition from conscious knowledge to recorded knowledge comes through interviewing, writing, documenting, capturing lessons - all the standard tools of knowledge capture.
7. The transition from written knowledge to unconscious knowledge is a tricky one, but we know it happens. If you are brought up on a diet of Fox News, you end up "knowing things" that are different from those you would "know" if you were brought up on a diet of the Washington Post. I don't have the correct term for this box, but "Indoctrination" may be a good term.
8. The transition from written knowledge to conscious knowledge is also difficult - here we can use the term "Internalisation" for that whole chain of "Read, Mark, Learn and Inwardly Digest"
9. The transition between various forms of recorded knowledge we can refer to as Synthesis - the bringing together, combination and "making sense" of disparate recorded sources into Knowledge Assets.

Depending on the sort of knowledge you are dealing with - the deep unconscious knowledge of the experts, or the shallow knowledge of company procedures - you may need to deal with more or fewer of these 9 transitions.

Connect and Collect - the two parallel pathways in KM

I mentioned Connect and Collect in yesterday's blog as being two routes for knowledge flow, so I thought I would expand on these two in today's post.

One of the earliest models in the history of Knowledge Management, and one that sometimes seems to get forgotten, is that there are two key dimensions in Knowledge Management, representing two routes between the knowledge suppler, and the knowledge user.

These are the Connect route, and the Collect route.

The Connect route supports knowledge transfer through connecting people.

• In the Connect route, Knowledge is transferred through conversation - either face to face or electronically mediated. 
• It can be supported by processes such as Peer Assist, Knowledge handover, knowledge exchange, knowledge markets, knowledge cafes, action learning, after action review, mentoring, coaching, and communities of practice.  
• It can be supported by technologies such as collaboration tools, people-finders, community forums, webex, telephone and skype. 
• The knowledge never needs to be written down; it can be - but it does not need to be, and knowledge can be transferred in tacit form.
• The Connect route is necessary for complex knowledge, advanced knowledge, deep skills, and highly contextual knowledge. 
• The Connect route is a highly effective way to transfer knowledge, but very inefficient, as the conversation must be repeated for each knowledge user.

The Collect route supports knowledge transfer through collecting knowledge into documents.

• In the Collect route, Knowledge is transferred through documentation ("Knowledge capture"), through organisation and synthesis of that documentation, and through connecting the user with the documents, through search or through push.
• It can be supported by processes such as Retrospect, Lesson Learning, Interview, creation of Knowledge Assets, and Knowledge Synthesis. 
• It can be supported by technologies such as portals, lessons management systems, search, semantic search, blogs and wikis. 
• The knowledge is written down or recorded, and transferred in explicit form.
• The Collect route is ideal for relatively simple non-contextual knowledge which needs to reach a large audience, for knowledge that needs shelf life, for knowledge where no immediate user is available, and for knowledge which needs compiling and processing (such as lessons). 
• The Connect route is an ineffective way to transfer knowledge, as we can only write a fraction of what we know, but very efficient, as once that fraction is captured it can be reused a thousand times.

Connect and Collect are not alternative strategies. They are two components of a single framework and a single strategy, which work in parallel. 

Your organisation will contain critical knowledge of very many kinds; some of which will need to be transferred through collection and some through connection. So make sure you address both dimensions

.

Connect and Collect - the left leg and right leg of KM

The Connect and Collect approaches in KM are like the left leg and the right leg- you need to use both. 

image from PublicDomain Pictures

I was working with a client last week who is very interested and enthused about the use of Knowledge Management Processes to drive conversations between staff, as an antidote to previous attempts to collect knowledge. These previous attempts had resulted in a huge lessons database which people viewed as a chore, and a waste of time. 

Much as I applauded their new focus on conversation and Connection, I urged them not to neglect the Collect part of the knowledge cycle, as these two aspects of KM go and in hand.

In fact, they are like the left leg and the right leg. A focus on Connecting can help you make a great stride forward, but you need the other leg to catch up if you want to make real progress. 

I told them this story

We were working with a KM team, who had asked us to come into their organisation and run some Retrospects from major successful bids. They wanted to develop and deploy knowledge of how to bid successfully. 

We held a series of Retrospects, and they worked very well. We had some fantastic dialogue within the bid team, and with the internal client, and identified a series of learning points. We found some really good success factors whch should be repeated in future, and whole set of opportunities for improving the bid process, including some things that were really frustrating the bid teams (mostly related to inappropriate company policies) and we communicated these to other projects. Everyone was very enthused by the process.  

A few months later the client called, and said "That Retrospect process is rubbish". That took me aback, as I know from experience that it is a very powerful and robust process, so I asked him why he said this. He replied - "those issues that were frustrating the team when we started, are still there. They have come up again in the latest Retrospects. Nothing has been changed". 

 Well - nothing would be changed, if all they did was hold Retrospects. Retrospects are great for identifying team learning, but there needs to be a follow on process to take action on the issue, and for this particular company, those actions needed to be taken at a high level in the organisation. They had not implemented a process or workflow for documenting the lessons addressing the actions, and had no engagement from senior managers in the learning process. Retrospects, like so many KM tools, need to be part of a system, and no tool in isolation will stand in for the system as a whole.

Connect and Collect  - Conversation and Content - need to work together. Conversation is where content is born, and content is something to talk about together. Retrospects need to work together with the lesson management system, not in isolation.

Connect and Collect are like the left leg and right leg of KM - there is only so far you can travel using one and not the other.

An unmoderated community is its own worst enemy

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

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

He mentions three behaviours;

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

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

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

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

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

He concludes three things

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

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

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

KM and conversations about knowledge

All forms of Management involve conversation, and Knowledge Management is no different.

"Side conversation" by Loren Kerns on Flickr

The management of intangibles is driven by conversations. Those conversations are focused on the particular intangible in question, and serve to set direction, raise awareness, and lead to action.

• Risk management is driven by conversations about risk; conversations to identify risks, conversations to map and characterise risk, and then actions to ensure the risks are well managed;
• Safety management is driven by conversations about safety; Hazops to identify safety issues, conversations about safety mitigation, and then actions to ensure personal and process safety;
• Talent management is driven by conversations; from conversations to identify talent requirements and strategy, through conversations to identify job requirements, to conversations with talented individuals.

Knowledge management is also driven by conversations, or by dialogue, about knowledge.   Steve Denning said at the Ottowa KM summit in 2006 that the learning capacity of an organisation is directly related to it's ability to hold conversations, but we need to go beyond this, and say that these conversations need to be conversations about knowledge. Not normal conversations such as project meetings or status updates, but deliberate conversations with knowledge as the focus.

Conversations about knowledge. 

We can probably divide these into two types of conversations;

• strategic conversations about knowledge strategies, knowledge needs, knowledge frameworks and knowledge flow, and 
• conversations designed to identify, build, synthesise and transfer knowledge. As I said on this blog, KM is as much about conversation management as it is about content management.

Actually, when it comes to the second type of conversation, the operative word is probably not "conversations" but "Dialogue". Dialogue is probably the single most important component of effective knowledge management.

All my favourite, most powerful knowledge management processes are dialogue-driven. It's the dialogue that allows people to reach a shared understanding of "what have we learned".

• Peer Assist is a dialogue to exchange and acquire knowledge at the start of a project. 
• After Action Review is a ongoing, regular learning-based dialogue within a working team. 
• Retrospect is a detailed dialogue at the end of the project to identity and clarify the team learnings. 
• Knowledge exchange is a multi-person dialogue within a community or between two teams.

Make sure that your KM program involves all the right conversations about knowledge, as this is the way that intangibles get managed.

What's the best thing to do with uncodfied knowledge?

Knowledge Managers sometimes assume that the best thing to do with uncodified knowledge - that undocumented knowledge that people still hold in their heads - is to capture it. Often however the best thing is to leave it where it is. 

Image from wikimedia commons

There are very many examples of cyclic Knowledge Management models where the cycle begins with "Capture", or at the very least, contains "Capture" somewhere within it.  This is a result of a default assumption that to manage knowledge, it must be codified. "We must make our tacit knowledge explicit" Knowledge Managers say, confusing tacit with uncodified, and explicit with codified.

However very often, the best thing to do with uncodified knowledge, whether it is tacit or explicit, is to leave it in the heads of the people until it is needed by others.  Capturing and codifying knowledge is labour-intensive, difficult to do, and even more difficult to do well. You can only capture a small fraction of the knowledge someone has in their heads - the rest is either too difficult to explain in words, and the knowledge-holder may be unaware of much of their knowledge (we refer to this deep knowledge of which the holder is unaware as the Unknown Knowns, or the unconscious competence).

Similarly there may not be a need for all of that knowledge to be captured. There is no point in capturing knowledge if it is not needed by someone else. If we documented all the uncodified knowledge in an organisation - downloaded the contents of every head onto paper or into files - we would have a fantastically comprehensive library of which only a tiny shelf in one corner is likely to be read.

Better then, in many cases, to leave the knowledge where it is, until it is needed. Provided that the person who needs the knowledge can,  at their time of need, find the relevant expert and have a conversation with them, then that knowledge is safe and secure.

Safe and Secure, that is, so long as you you follow the advice below.

1. Only leave the knowledge uncodified if there is limited demand for it.

The primary problem comes when you leave uncodified those areas of knowledge which are in high demand. In such cases, having to ask the expert for advice all the time just adds load to the expert. Such high-usage knowledge is worth codifying; the effort spent in codification and capture far outweighs the otherwise overwhelming demand on the expert's time. It becomes easier to refer the enquirer to a Frequently Asked Question site or other knowledge asset, rather than have to answer the same questions and hold the same conversations over and over again

2. Only leave the knowledge uncodified if the expert is guaranteed not to forget

This means that the knowledge must cover topics which are in constant use. If an expert is not constantly using their knowledge, then they need to store it away in their long-term memory, which is a poor knowledge store. Even the best experts forget over time, if the knowledge is not regularly used.

3. Only leave the knowledge uncodified if the expert is guaranteed to stick around

If there is any chance at all that the expert will retire, or quit, then codify and transfer that knowledge as soon as you can as part of your Knowledge Retention and transfer program.

4. Only leave the knowledge uncodified if the practitioners - expert and novice - are connected. 

There is no point in leaving the knowledge in people's heads, if those people cannot be found. Tacit knowledge remains an asset to the organisation if the people are connected; connected in communities of practice, indexed in a know-how directory, and connected through collaboration and discussion software.

If these four caveats are in place, then often the best thing to do with the knowledge is leave it in the heads until you need it. 

Enterprise Conversation Management

If the subject material of KM is both Content and Conversation, why do we hear so much about Enterprise Content Management, and so little about Enterprise Conversation Management?

Image from wikimedia commons

We know that knowledge is either tacit or explicit - either in the heads, or codified. We know also that there are two parallel approaches to KM - the connect and collect approaches (connecting the people, collecting the knowledge). We know the means of knowledge transfer through connect and collect are conversation and content.

Yet the content gets all the attention. There is a huge discipline of Enterprise Content Management, and the term gets 2.3 million hits on Google. There is almost nothing on Enterprise Conversation Management (247 hits).

Why does the content get 10,000 times more attention?

I think its probably because content is far less messy to manage than conversation. However, messy or not, conversation is as much at the heart of our KM frameworks as content.  For example:

• Conversations within communities of practice, through which practices are discussed and shared, and problems solved - either online or face to face conversations such as Knowledge Exchange
• Conversations between experienced and less-experienced staff, as part of coaching, mentoring, and job handover
• Conversations within project teams to identify shared lessons, such as Retrospects and After Action Reviews
• Conversations between one project team and other teams, such as Peer Assist, Knowledge Handover etc.

These are knowledge-specific conversations, all of them dialogue-based, and therefore different from action-specific conversations such as briefing and reporting, and different from the typical broadcast notification traffic seen on some examples of social media.   It is through these dialogue conversations that tacit knowledge is brought to light, shared, and co-developed. Managing, structuring and facilitating these conversations - making them routine, efficient, powerful and deep, is a crucial element of knowledge management.

Don't neglect Enterprise Conversation Management - pay it as much attention as Enterprise Content Management as part of a balanced KM approach.

Content and Conversation are the King and Queen of Knowledge Management - they rule together. Content is something to talk about, Conversation is where Content is born and where it is tested. As Knowledge Managers, we should focus equally on both.

3 cases where KM doesn't need dialogue

This blog has often argued that dialogue is at the heart of effective knowledge transfer, and that without dialogue it is difficult both to access the deep unconscious learning, and also to check whether the knowledge customer properly understands the knowledge that has been offered. 

Conversation with a wise man by Celestine Chua on Flickr

However many companies operate knowledge transfer systems, such as lessons databases or knowledge bases, which involve no dialogue at all.

Do these work? Under what circumstances can they work? Here are 3 cases

 1. Dialogue-free knowledge transfer is perfectly acceptable when the context of the knowledge is very clear.

Take the example of cookery books; these are a very effective means of transferring the knowledge of how to cook certain dishes. The context of cooking a meal is a clear context, shared between the author and the reader. However if you move outside that context, for example moving to another country where the ingredients and measures are different, or opening your house as a pop-up restaurant, the results may be disappointing. If you want to move to a more creative context, you will probably take cooking classes and discuss what you are learning with a professional chef. 

2. Dialogue-free knowledge transfer is perfectly acceptable when the nature of the knowledge is limited. 

 Take the example of road maps; these are a very effective way of transferring the knowledge of how to navigate from one place to another. Most motorists have a road map in their car, or a sat-nav. But for more complex knowledge, like the details of finding a specific house down country roads, you need the advice of people with local knowledge (see my blog post on Charts and Pilots; charts are fine on the open sea, but every large vessel entering port uses a pilot to travel the last mile or so).

2. Dialogue-free knowledge transfer is perfectly acceptable when the knowledge is very mature at user-level. 

When a topic is mature, everything is known. We know all the questions that can be asked about the topic, and all the answers.  All of this can be fully documented, for example in an online FAQ or knowledge asset.  Even then, there will be advanced-level nuances which experts may still need to discuss, but for the average user, this knowledge can safely be codified.  However if a topic is not fully mature and is still evolving, then the answers in the FAQ may change, and new questions may arise. There will be knowledge that is needed that is not yet "in the manual" and will need to be exchanged through dialogue.

As I pointed out here, any Knowledge Management framework needs to focus on Conversation (through dialogue-based processes) as well as on Content, other than in the three cases described above.

Content and Conversation - the two subjects of KM

---

I have blogged a few times about Connect and Collect - the two parallel approaches to transfer of knowledge. Now lets look in more depth about the subject of that transfer - the material or the stuff that is enabled by the transfer. 

Kids of conversation by Kris Hoet on Flickr

• During the Connect approach we facilitate the transfer of knowledge through Conversations, whether these are electronically moderated or face to face.
• During the Collect approach we facilitate the transfer of knowledge through captured and codified Content in the form of documents, files, text, pictures and video.

We also know that Conversations are a far richer medium than Content (see here - thanks Valdis) - potentially 14 times richer, though Content can reach far more people, and has a longer life-span than a conversation.

Any comprehensive Knowledge Management framework needs to enable, promote, facilitate and otherwise support both conversation and content.

Managing conversation without content leaves no trace, other than in the minds of the people involved. That is itself is useful, and we know that most of the processes of Knowledge Management, such as Retrospect, After Action Review, Peer Assist and so on are valuable individual learning experiences. But managing conversation without content is not a valuable organisational learning experience. Unless new knowledge becomes embedded in process, or guidance, or recommendations, it is never truly "learned", and without this we find knowledge becomes relearned many times, with errors being repeated, wheels reinvented and so on.

Managing content without conversation leads KM towards the already established fields of Content Management and Information Management, and you could (as the author of the famous "Nonsense of Knowledge Management" did) challenge what KM adds over and above these other disciplines. A focus on content without conversation results in a focus on publishing; on creation of knowledge bases, blogs, wikis, as a proxy for the transfer of knowledge; on Push rather than Pull. But unless people can question and interrogate knowledge in order to internalise it, learning can be very ineffective.

There is a saying in social media circles that "Conversation is King, Content is just something to talk about".

Like any other attempt to avoid duality, this is wrong. Knowledge Management, as a field, is far more "both/and" than it is "either/or".

Content and Conversation are the King and Queen of Knowledge Management - they rule together.

Content is something to talk about, Conversation is where Content is born and where it is Tested.

As a Knowledge Manager, please focus equally on both, and please do not assume that all Conversation needs to be written either. Face to Face is still the preferred transfer mechanism for high-context knowledge, and "getting people together to talk about what they know" is an amazingly effective tool within your Knowledge Management Framework.

Why knowledge transfer through discussion is 14 times more effective than writing

---

Knowledge can be transferred in two ways - by Connecting people so that they can discuss, and Collecting knowledge in written (explicit) form so others can find and read it (see blog posts on Connect and Collect). 

Connecting people is far less efficient than Collecting while being far more effective - but how much more effective?

We can never be sure about the effectiveness of knowledge transfer without some good empirical studies, but there are 2 pointers towards the relative effectiveness of these two methods. These pointers are as follows;

The often repeated (and sometimes challenged) quote that “We Learn . .

• 10% of what we read 
• 20% of what we hear 
• 30% of what we see 
• 50% of what we see and hear 
• 70% of what we discuss 
• 80% of what we experience 
• 95% of what we teach others.”

David Snowden's principle that

• We always know more than we can say, and 
• We will always say more than we can write down

Let's make two assumptions here, firstly that the percentages in the first list are correct, and secondly that we equate the "more than" in Snowden's principle to "twice as much as" (OK, this is entirely arbitrary, but I want to see what the consequences are).

With these assumptions, the effectiveness of the Connect route is as follows

• I know (100%)
• I say (50%) 
• You learn through discussion (50% x 70% = 35%)

The effectiveness of transmission of knowledge through Connecting is therefore 35%.

The effectiveness of the Collect route is as follows

• I know (100%)
• I write (50% x 50% = 25%)
• You learn through reading (25% x 10% = 2.5%)

The effectiveness of transmission of knowledge through Connecting is therefore 2.5%.

Therefore transferring knowledge through Collecting is 14 times less effective than transferring knowledge through Connecting people.

If we change the proportions in Snowden's principle then we change this conclusion. If for example 

we always know 3 times more than we can say, and we will always say 3 times more than we can write down, Collecting becomes 21 times less effective, and so on.

I know all these figures are arbitrary and inexact, but what we are looking at here is some sort of estimate of relative efficiencies.

Note that this does not mean that Collecting knowledge has no place in Knowledge Management - quite the opposite. Despite being very ineffective, it is very efficient. Knowledge has only to be documented once, to be re-used one thousand times. Efficiency can trump effectiveness. However we can conclude the following

• Because of these relative efficiencies, Knowledge should shared in explicit form (the Collect route) only when it is relatively simple and when it can be codified with minimum loss of context. 
• Where knowledge is more complex or more contextual, it should be shared through discussion (the Connect route) - for example through conversational processes such as Peer Assist
• Where efficiency is more important than effectiveness (i.e. broadcasting relatively straightforward knowledge to a large number of users), the Collect route is ideal.
• The Collect route is also necessary when a Learner (a recipient for the knowledge) cannot be immediately identified, so no Connection is possible (see "speaking to the unknown user").
• Even then, it is worth "keeping the names with the knowledge" so that readers who need to know more detail can call the originator of the knowledge and have a discussion. 

Why dialogue is so important for Knowledge Management

---

Conversation, by Valerie Kensi, on Flickr

Why do children go to school to learn, rather than staying home and reading books?

Why, if you have access to the best cookery books in the world, do you still need to take personal tuition if you want to be a cordon blue chef?

If you have a street map in the car, why would you ever need to stop and ask for directions?

The answer, in every case, is that knowledge transfer is a social process, and if you want to transfer detailed knowledge you have to engage in conversation (specifically, in dialogue) with other human beings.

Dialogue allows you to ask questions, seek clarification, test understanding, and look for that "aha" moment when the knowledge is really transferred. Dialogue allows access to the deep tacit knowledge - the knowledge that people don't even know that they know - and it allows you to check whether you are really understood the knowledge.

Any good teacher knows that discussion and dialogue in the class is far better at developing understanding than teaching by rote. Any cook knows there are tricks you can’t pick up from any book. Any driver knows that there comes a time when the map is not enough, and they need to wind down the window and ask a real human being with local knowledge.

Why is dialogue so important in Knowledge Management? 

The majority of knowledge within any organization is held in people’s heads. Indeed some would claim that ALL the knowledge is in people’s heads, and that anything which is written down becomes information, rather than knowledge. However for the purposes of this article we will call written knowledge “explicit” and “head knowledge” will be referred to as “tacit” (although this is not the strict definition of the term).

 There are two sorts of tacit knowledge in anyone’s head – the knowledge which they are conscious of, and the unconscious knowledge, the deep knowledge of which they are unaware. The matrix below identifies four states of knowledge, depending on whether the person has the knowledge or not, and whether they are conscious of it or not.

The bulk of the useful knowledge is likely to lie in the box of unconscious competence, where people who have gained the knowledge have not yet taken the time to analyse what they have learned, and make it conscious so it can be transferred to others.

Under these circumstances, the transfer of knowledge from one person to another is not an easy thing to achieve! The person who has the knowledge (the "knowledge supplier") may only be partially conscious of how much they do know. The person who needs the knowledge (the "knowledge customer") may only be partially conscious of what they need to learn.

If we look at the matrix below, the knowledge supplier has both conscious and unconscious competence, and the knowledge customer has both conscious and unconscious incompetence. Also the knowledge supplier doesn't know what the customer needs, and the knowledge customer doesn't know what the supplier has.

Without dialogue we cannot overcome the boundaries of not knowing. (Tweet this)

Dialogue is needed, in order to

• Help the knowledge supplier understand and express what they know (moving from superficial knowledge to deep knowledge)
• Help the knowledge customer understand what they need to learn
• Transfer the knowledge from supplier to customer, and
• Check for understanding

The knowledge customer can ask the knowledge supplier for details, and this questioning will often lead them to analyse what they know and make it conscious.  The knowledge supplier can tell the customer all the things they need to know, so helping them to become conscious of their lack of knowledge.  As pieces of knowledge are identified, the customer and supplier question each other until they are sure that transfer has taken place.

What types of dialogue are there?

Although we have been talking here about knowledge transfer from one supplier to one customer, this will not always be the case. Usually the knowledge is held by more than one person – often by a team. (the team also has another specific role here, it helps define the contextual domain of why the knowledge may be valid to another team. One person has the personal context of “why this works for me”, the team can provide the more smoothed data that would appeal to a larger audience through the process of consensus) There may be many customers for the knowledge, and many different teams may need access to the knowledge at various times in future. Dialogue can take place within teams and between teams, as well as between individuals. However the processes and formats for the dialogue vary, depending on the number of customers, the number of suppliers, and whether the knowledge is being pushed or pulled.

The matrix below shows some of the forms that the dialogue may take, depending on whether the supplier and customer are one individual or team, or many individuals or teams.

	To one customer	To many customers
From one supplier	After Action review Mentoring Coaching Handover interview	Knowledge Handover Training Teaching Knowledge visit
From many suppliers	Peer Assist	Knowledge Exchange Knowledge Cafe

Contact Knoco for guidance on how Dialogue can be part of your Knowledge Management Framework.