Why the "Working Teams" dimension is important in KM

We hear a lot about communities of practice and social networks in Knowledge Management, but we should not lose sight of the other dimension of the knowledge equation – the work teams.

Image from wikimedia commons

Work teams are often the way work gets done in organizations, and a team of knowledge workers is effectively a knowledge team. Any complete knowledge management framework needs to cover the team dimension, because teams create knowledge, and teams use knowledge.

Teams create knowledge

Knowledge is related to activity—you learn from experience, from ‘doing things’. In most of the companies to which Knoco consults, ‘things are done’ by teams. In the oil industry, construction industry, engineering, mining, television, etc, most of the big work is done by multidisciplinary teams, and therefore, the organisational unit for reviewing that work is the team.

Please note that although Knowledge  is related to activity, it actually comes from reflection on activity (see posts on the importance of reflection, and 6 benefits of reflective team learning). A team will not collectively create knowledge unless they reflect collectively. This will not happen unless you do it deliberately. Most team communications are action-oriented (What have we done? What needs to be done? What will we do next) rather than reflection-oriented (Why did these things happen? What did we learn? What can we improve?). To introduce reflection, you need to introduce reflection processes and methods; not just assume that will reflection will happen during normal team discourse.

Some of the more familiar methods for reflective Knowledge creation and capture within a team/activity/project environment are the after action review and the retrospect. These are processes for structured discussions between the team members to identify any new lessons and new knowledge which has been created during the activity or the project.

Teams apply knowledge

Teams create knowledge, but they also seek, re-use and apply knowledge. They need to learn from others in order to perform their tasks effectively. Team learning can be organised through the use of a Knowledge Management plan, and will involve processes such as Peer Assist where the team talks with other experienced practitioners to draw on their lessons.

Teams manage their own knowledge

Teams need to manage the knowledge they are creating, where it is specific to the team (knowledge which is generic, and applies to other teams, needs to be managed by the communities of practice). You may need to introduce team knowledge technology to help manage this knowledge.

Much of the Team technology such as Trello, Zoom, MS Teams etc are designed to manage activity, connectivity and work products, not knowledge. You probably need a team lessons log, and potentially a team blog and a team wiki as well, so long as the blog is used to summarise and share reflections and knowledge rather than to share progress and activity reports.

Communities of practice share knowledge

If the work teams create and apply knowledge, then the role of the communities of practice and the social media is to provide a mechanism to transfer this knowledge from one work team to another on a daily basis. 

View Original Source (nickmilton.com) Here.

What can happen if you don’t capture the "know-why"

Know-Why is important in KM, but sometimes neglected. Let’s see what happens if this is not captured.

Image courtesy of keesler.af.mil

Know-how is one of the cornerstones of Knowledge Management.  If we capture how things should be done, we empower people who need to perform a task, but have no experience of their own. Capturing know-how allows you to build a “recipe book” for repeat tasks, which allow them to be replicated in similar circumstances in future.

However unless you also capture know-why, the know-how can trip you up, especially when the know-how is applied in a different context.

Here is an example of when know-how was misapplied, through lack of know-why. 

This story comes from oil-well drilling back in the 90s, where one part of the organisation was learning from another part about a particular technique for drilling in deep water. The details of the technique were transferred, but not the reasoning behind it, and when the team applied the technique in their own part of the world, where the sea-bed was different, it failed, and several days were spent recovering the situation at a cost of over a million dollars.

One of the partners involved with the well, however, picked up the technique and also the rationale behind it(the know-why)  and applied it successfully, at a saving of several million dollars per well.

If we capture the  Know-how of a technique, but not the Know-why, then

  1. others can “follow the recipe” when the context is the same, but
  2. when circumstances change, people do not have the knowledge to adapt the technique, and either proceed to failure, or tinker with the technique, which often leads to failure as well

If we capture the  Know-how of a technique and also capture the Know-why, then

  1. others can know when the recipe is inapplicable, and
  2. know what can be safely changed
How do you capture the Know-Why?

There are a number of ways to capture the Know-why.

In After Action Reviews and Retrospects, the questioning includes a “Root cause analysis” step, that shows why the lessons were derived, and why they are worded the way they are. The observers and participants understand the context, and this is also recorded in the lessons management system. There should always be a paper trail between any changes to procedures made as a result of lessons, and the know-why recorded in the lessons themselves.

The A3 approach used in product design also captures the context and the root cause.

Some equipment designers use a document called Basis of Design. This captures the rationale behind a design of equipment or design of a process. It explains why the design is the way that it is.  The Basis of Design can be updated as design continues, to capture any changes, and the rationale behind these.  As one Alaskan drilling engineer said to me, “With a good Basis of Design, I could come up to this oilfield and put a quality well program together in a week, and there hasn’t been a rig drilling here for two years”.

Toyota capture the Know-why in “checksheets”, attached to each technical drawing, which captures the rational behind the design, its impact on performance, and any known issues. Rolls Royce Aero Engines have an even more sophisticated system called the Design Rationale Editor, which captures the reasons behind design choices, and the reasons why other choices were rejected, as a Functional Analysis diagram.

In each case, the knowledge product contains not just the final design of a product or product, but the rationale behind it. This preserves crucial knowledge for future use.

View Original Source (nickmilton.com) Here.

Why a no-blame culture needs no-blame processes

We hear a lot about the importance of a “no-blame culture” in Lesson-learning, but a no-blame culture won’t work unless you have no-blame processes as well. 

Image from wikimedia commons

Learning lessons in an organisation requires a culture of openness, so that people are willing to explore honestly and openly what happened, and what might be learned.  This is particularly important when learning from projects or incidents where things have gone wrong and where mistakes have been made.  If people feel they are likely to blamed for the mistakes, and that their career or reputation might suffer as a result, they are unlikely to discuss the issue openly.

When we discuss the topic of lesson-learning with clients, we often hear the concern that lesson-learning meetings could be seen as “witch-hunts” – in other words, a search for someone to blame. To reassure them, we talk them through the lesson-learning process we use; the Retrospect.

The Retrospect is an externally-facilitated team meeting, held after the end of a project or project stage, where the team identifies and analyses learning points through discussion and dialogue, in order to derive lessons and actions for the future. The facilitator leads an inclusive discussion to identify

  • What went well and what did not go to plan in the project
  • Why the successful elements succeeded, and why the failures and mistakes happened (looking for root cause)
  • How future projects can repeat the success and avoid the failure. 

The key questions are therefore What, Why and How; very open questions which allow full exploration of the lessons learned.

Note that there is no Who question. 

We do not really care who was the hero or who was the villain. This is a no-blame process, as well as a no-praise process. We are searching neither for Witches or for Knights; only for the truth.

An open, no-blame culture requires open no-blame processes such as the Retrospect.

View Original Source (nickmilton.com) Here.

Do you always need content as part of KM?

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

Image from wikimedia commons

This blog has argued that content is as important as conversation in KM, and that content beats memory for long-term preservation of knowledge, and that creation of knowledge content (which is different from other types of content) helps tackle the illusion of memory.

There are few if any organisations which attempt to manage KM without the use of content, so under-use of content is not a bias to be corrected in the same manner as under-use of conversation (see yesterday’s post). However the automatic use of content in every case may also be inappropriate.

Under what circumstances can you run KM without creating content? Here are 3 examples

 1. Content-free knowledge transfer is perfectly acceptable when the use of the knowledge is very short term and local. 

Take the example of a project team conducting a complex task, identifying their learning through regular After Action reviews. There will be much knowledge than is discussed and exchanged through this mechanism, which can be immediately fed back into the way the team works, without ever having to be written down. Because the knowledge will be used by the same team and nobody else, and in the very short term, it has no need of being recorded.

2. Content-free knowledge transfer is perfectly acceptable when the context of the knowledge is rapidly changing.

 Take the example of a situation which is changing day by day. The people involved, in their teams or communities, should be talking regularly, but any captured knowledge will be out of date as soon as it is written. Here knowledge transfer is best done through communication and conversation. There is no point in documenting best practice where the nature of “best” changes on a daily basis. 

3. Content-free knowledge transfer is perfectly acceptable when the knowledge is impossible to document. 

Here we are talking about “Deep Smarts,” Familiarity Knowledge”, or knowledge of physical activity. This is knowledge that is very hard or impossible to write down. Knowledge of “how to dance” has be be guided and mentored; it cannot be codified. Here knowledge transfer is accomplished by coaching and guiding, or through what Dorothy Leonard calls “guided experience“. Trying to transfer such knowledge through content is a waste of time. 

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

View Original Source (nickmilton.com) Here.

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.

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. 

View Original Source (nickmilton.com) Here.

Dealing with the unknown knowns

Another post from the archives on dealing with the “unknown knowns” in Knowledge Management.

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 in Knowledge Management 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 people – the tacit knowledge (in the original sense of tacit – distinguished from explicit knowledge being the known knows, whether they are documented or not).

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 (45 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.

For me, that manoeuvre was an unknown know. I knew how to do it, but did not know how I did it, if you see what I mean.

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 answer to the question might be a statement; sometimes it is a demonstration (as in my driving example). This depends on the knowledge, and the depth to which it has become unconscious.

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. They don’t pay attention to the step of making knowledge conscious, so all that becomes recorded is the known knowns – the shallow knowledge, which does not contain the necessary depth or detail. And then they wonder why they don’t get the value.

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

After Action review
Peer Assist

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.

View Original Source (nickmilton.com) Here.

The curse of knowledge, and stating the obvious

The curse of knowledge is the cognitive bias that leads to your Lesson Database being full of “statements of the obvious”

Obvious sign is obvious.There is an interesting exercise you can do, to show how difficult it is to transfer knowledge.

 This is the Newton tapper-listener exercise from 1990.

 Form participants into pairs. One member is the tapper; the other is the listener. The tapper picks out a song from a list of well-known songs and taps out the rhythm of that song to the listener. The tapper then predicts how likely it will be that the listener would correctly guess the song based on the tapping. Finally, the listener guesses the song.

Although tappers predicted that listeners would be right 50% of the time, listeners were actually right less than 3% of the time.

The difference between the two figures (50% and 3%) is that to the tapper, the answer is obvious. To the listener, it isn’t.

This is the “curse of knowledge“.

Once we know something—say, the melody of a song—we find it hard to imagine not knowing it. Our knowledge has “cursed” us. We have difficulty sharing it with others, because we can’t readily re-create their state of mind, and we assume that what is clear to us, is clear to them.

Transferring knowledge through the written word (for example in lessons learned, or in online knowledge bases) suffers from the same problem as transferring a song by tapping. People THINK that what they have written conveys knowledge, because they can’t put themselves in the mind of people who don’t already have that knowledge.

Just because they understand their own explanations, that does not mean those explanations are clear to he reader.

This effect can be seen in written knowledge bases and lessons databases, and often appears as Statements of the Blindingly Obvious (SOTBOs).

These are statements that nobody will disagree with, but which carry obviously carry some more subtle import to the writer which the reader cannot discern. These include statements like

  • “It takes time to build a relationship with the client” (Really? I thought it was instantaneous). 
  • “A task like this will require careful planning”. (Really? I thought careless planning would suffice)
  • “Make sure you have the right people on the team.” (Really? I thought we could get away with having the wrong people)
  • Ensure that communication and distribution of information is conducted effectively. (Really? I thought we would do it ineffectively instead)
The writer meant to convey something important through these messages, but failed completely. Why is this? Often because the writer had no help, no facilitation, and was not challenged on the emptiness of their statements.

In each case, any facilitator which had been involved in the capture of the knowledge, or any validator of the knowledge base, would ask supplementary questions:

  • How much time does it take? 
  • What would you need to do to make the planning careful enough? 
  • What are the right people for a job like this? 
  • What would ensure effective communication?
This further questioning is all part of the issue of knowledge quality assurance, to filter unhelpful material out of the knowledge base, or lessons management system, and to turn an unintelligible set of taps into a full tune.

Without this, people rapidly give up on the knowledge base as being “unhelpful”, and full of SOTBOs.

View Original Source (nickmilton.com) Here.

How to find the "unknown knowns"

The Unknown Knowns are a major component of experts’ tacit knowledge, and to uncover these, we need Knowledge Pull

Unknown PeopleThere is a lot of knowledge out there in the organisation that we Don’t Know That We Know, and one of the truths of Knowledge Management is that we don’t know what we know until we need it, or until someone asks us really deep and probing questions.

That’s why an effective Knowledge Management program cannot be based on individual volunteering or publishing of knowledge, aka Knowledge Push, as this only find the Known Knowns.

Sometimes you find organisations who have set up a system whereby people are required to identify lessons themselves and to add them into a lessons management system, or to identify “knowledge objects” and add them to a database, or to identify new ideas and improvement suggestions and add them to a Suggestions Scheme.

I am not as huge fan of Push systems like this.

I think you capture only a small proportion of the knowledge or ideas this way, because you miss the Unknown Knowns.  People are not aware that they have knowledge and ideas, and if they are aware, they often discount the knowledge as “not important”.

Instead, don’t wait for knowledge, ideas or lessons to be volunteered – go seek them out. Go and do some proactive knowledge identification.

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

The reactive approach requires someone to identify particular successes and failures from which to learn. The failures can be obvious, such as safety incidents or significant project overruns, and many companies have mandatory processes for reviewing these failures. But how do you spot the successes? Maybe you can use your company benchmark metrics, and seek to learn from those departments with the best results that year. Perhaps you could work with the knowledge from the manufacturing plant that never had an accident, as well as from the one with frequent accidents. Maybe you can look for the best sales team, and look to learn the secrets of their success.

Or maybe you can do both successes and failures – I did a very interesting study not long ago for an organisation that measures staff engagement using the Gallup survey. We picked the ten top scoring sales teams, the ten bottom scoring teams and the ten teams which had shown the most improvement over the previous year, and interviewed the team leader and a team member of each one, to pick out the secrets of successful staff engagement.

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

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

There are many advantages to the scheduled approach. Firstly, success and failure are components of every project, and if every project is reviewed, lessons may be identified which can avoid the big mistakes later on.

Secondly, if lessons identification is scheduled, it becomes a clear expectation, and the company can monitor if the expectation is being met. This expectation is common in many organisations, thought the rigour with which the expectation is met seems to vary.

Finally, by scheduling and facilitating the learning dialogue, you can uncover the knowledge that nobody knows they know, until they start to discuss it.

That’s how you find the Unknown Knowns.

View Original Source (nickmilton.com) Here.

Socrates on Explicit Knowledge

Here’s a reprise from the archives – Socrates on the limitations of the written word.

SocratesSocrates, as reported by Plato in The Phaedrus, was not a fan of explicit knowledge.

Explicit knowledge, in those days, meant Writing, and Socrates never wrote anything down – he had a scribe (Plato) to do that for him. He mistrusted writing – he felt it made people stupid and lazy by giving them the impression that they were recording (and reading) real knowledge.

Here’s Socrates

“He would be a very simple person…who should leave in writing or receive in writing any art under the idea that the written word would be intelligible or certain; or who deemed that writing was at all better than knowledge and recollection of the same matters….. Writing is unfortunately like painting; for the creations of the painter have the attitude of life, and yet if you ask them a question they preserve a solemn silence….

You would imagine that they had intelligence, but if you want to know anything and put a question to one of them, the speaker always gives one unvarying answer…..Is there not another kind of word or speech far better than this? … I mean an intelligent word graven in the soul of the learner, which can defend itself, and knows when to speak and when to be silent”.

In the form of a fable, he says this about writing as a means of transmitting knowledge

“The specific which you have discovered (writing) is an aid not to memory, but to reminiscence, and you give your disciples not truth, but only the semblance of truth; they will be hearers of many things and will have learned nothing; they will appear to be omniscient and will generally know nothing”

In Summary, Explicit Knowledge, for Socrates, is poor because it cannot be questioned, gives always the same answer, and is the “semblance of truth”. Far preferable is Tacit knowledge (“an intelligent word graven in the soul of the learner”) which can be questioned.

Socrates (as befits one of the world’s leading philosophers) had a good point.

How then can we reduce these real risks when it comes to transferring knowledge? We have four options.

  1. For the most important knowledge, aim to Connect people rather than relying on Collecting the written word. Use Peer Assist and Communities of Practice, rather than relying solely on knowledge bases.
  2. When you do record explicit knowledge, ensure that the details of the author are attached to the knowledge, so that the reader can find the writer and question them directly. In this way the explicit record becomes a pointer to tacit knowledge, and a reminder (Socrates’ “reminiscence”) to the author. 
  3. Use explicit knowledge for those topics which require “one unvarying answer”, such as best practice, “rules of the road”, instructions, manuals and policies, bearing in mind that the answer may evolve over time, and that the written word must evolve similarly.
  4. When you record explicit knowledge (as text or video), bear in mind all the questions the reader/viewer is likely to have, and answer them. The FAQ format is a better format than dry prose or instruction, as it is reader-focused and question-focused.
I think Socrates would endorse 1, 2 and 3, and perhaps be less happy with 4.

View Original Source (nickmilton.com) Here.

How to learn from critical decisions (video)

This video from the University of Bath, UK, shows Joseph Borders describing a varation of the Critical Decision Method.

This is a method used to elicit knowledge from an expert, in the context of an unusual even they were involved in, through an analysis of their decision making process.

You might use this technique as part of a Knowledge retention strategy for example, or as a form of Retention Interview.

The Critical Decision Audit: Blending the Critical Decision Method & the Knowledge Audit from University of Bath on Vimeo.

View Original Source (nickmilton.com) Here.