“The thread through the labyrinth” is a metaphor for allowing others to follow our steps safely. This is what Knowledge can do. 

German cave diver holding line, by Hossam El-Hamalawi on Flickr

When Theseus negotiated Daedelus’ labyrinth in order to kill the Minotaur, he left a thread behind him (provided by Ariadne, daughter of Minos) so that the way through the Labyrinth would be clearly marked.

Cave divers do something similar, unreeling a line behind them as they explore the labyrinth of flooded passageways; both so they can find their own way out, and also so that others can follow the path without getting lost, or without having to explore the same dead ends and blind alleys that the first divers did. 

Sometimes, negotiating our projects feels like making our way through a labyrinth, especially when the project has to negotiate complex regulatory or bureaucratic hurdles, or technical difficulties.

When we successfully negotiate these hurdles, which sometimes can be long and taxing, we need to leave a thread behind us for the sake of the next project.

Imagine the first project of its type in a country – the first factory, or the first branch office. Imagine you have eventually worked your way through the maze of rules, regulations and red tape, contracts and logistics. The thread you leave behind is not string, but the collected knowledge (the “knowledge asset“) that enables the second factory, or the second branch office, to successfully follow the path of the first.

That knowledge might include;

• The list of activities you need to undertake
• The order in which to undertake them
• The people you must contact, and how to contact them
• The letters you must send, and how to write them
• The evidence you must collect, and how to best present it

We often get hung up on treating knowledge as if it were impersonal pieces of content; instead let’s look at it as an interaction between supplier and user.

Image from wikimedia commons

All knowledge, if we think in terms of “Know-how” originates from people, and is re-used by people.  Sometimes it passes from person to person through conversation, and sometimes the interaction is more remote – through written or recorded words and diagrams.

Knowledge Management, therefore, is a systematic and structured approach to transferring strategic and operational knowledge from suppliers to users through whatever interactions are most effective and efficient. And in many cases co-developing the knowledge as well as transferring it.

In a recent blog post, I explained about Collect and Connect as being two routes for knowledge transfer between the supplier and user, but now let’s look at the supplier and user themselves.

Knowledge is created through experience, and through the reflection on experience in order to derive guidelines, rules, theories, heuristics and doctrines. Knowledge may be created by individuals, through reflecting on their own experience, or it may be created by teams reflecting on team experience, or communities of practice engaged in collective sense-making. These are knowledge suppliers.

Knowledge is applied by individuals and teams, who can apply their own personal knowledge and experience, or they can look elsewhere for knowledge – to learn before they start, and benefit from shared experience. These are knowledge users. One of the challenges for knowledge transfer, is that often the user is unknown and the supplier has limited ways to interact with this user.

Sharing is no guarantee of uptake. Sometimes better practices and innovations take a long time, and require a lot of support, to take hold.

Here is a very interesting article from the New Yorker, by Atul Gwande, about why some ideas or best practices catch on and spread, while others don’t. In today’s connected world we expect good ideas to diffuse virally, but the fact is that many great ideas never spread.

For example, Gwande contrasts the histories of anaesthesia and asepsis in medicine – both important life-saving ideas, but the practice of anaesthesia spread like wildfire, while asepsis is still not properly adopted world wide. What was the difference between the two?

The difference was the immediacy and visibility of the problem to the practitioner.

Anaesthesia solved an immediate and visible problem for the surgeon. Under ether, the patient was no longer screaming and thrashing about, and the operation could take place in peace and quiet. Asepsis, on the other hand, did not solve an immediate problem. The operation took place as normal, and nothing apparently changed. As far as the surgeon could see, there was no immediate improvement. OK, the long term patient survival rate improved with asepsis, but that was a longer term issue and more remote for the surgeon. Asepsis solved a big problem, but a problem that was largely invisible to the practitioner, at least in the short term.

Gawande concludes that with the big invisible problems, you cannot expect improved practices to spread virally. You need to work on them. You need to sell the solutions, and like sales reps, that requires frequent interactions (the “seven touches”) between the trainer or knowledge holder and the user – person to person, door to door, talking.

He gives an example of an interaction with a nurse who learned, from a visiting trainer, a new practice that improved the survival rate of newborn infants. This was a practice that addressed one of these “invisible problems”, but had proved very difficult to spread. Gwande wanted to know why the nurse had adopted the practice in this case.

“She showed me how to get things done practically,” the nurse said. 

“Why did you listen to her?” I asked. “She had only a fraction of your experience.” 

In the beginning, she didn’t, the nurse admitted. “The first day she came, I felt the workload on my head was increasing.” From the second time, however, the nurse began feeling better about the visits. She even began looking forward to them. 

“Why?” I asked. All the nurse could think to say was “She was nice.” 

“She was nice?” “She smiled a lot.” “That was it?” 

“It wasn’t like talking to someone who was trying to find mistakes,” she said. “It was like talking to a friend.”

This was one of those big ideas that spread through repeated personal contact and influence, rather than virally, and the repeat contact and trust that developed between the trainer and the nurse was vital for adoption and re-use of the knowledge.

So what is the implication for Knowledge Management?

The implication comes through the strategies you need to employ for knowledge re-use. Where knowledge solves an immediate problem for the user, then you can rely on a viral approach. Where it solves a longer term problem for the organisation, but may be invisible to the user, then knowledge re-use needs to be promoted through training, coaching and frequent interaction with a friendly person. 

How far does your knowledge spread in your organisation?

Image from wikimedia commons

We are used to the idea of the Carbon Footprint – the amount of carbon dioxide released into the atmosphere as a result of your activities – but what about your Knowledge Footprint? This is the amount of knowledge released into the organisation (or the world, if you prefer) as a result of your activities?

What is the size of your knowledge footprint?

We could measure that by seeing how far your knowledge spreads; whether you contribute in Community of Practice discussions, for example; whether you contribute to lessons learned, or whether you add your contribution to Wikis and knowledge assets. All of these are examples of broadening your knowledge footprint, and contributing your knowledge to the wider organisation.

In contrast, a small knowledge footprint would be if you shared your knowledge only with the team you work with, or only in individual reports in a library which nobody might read. As an example, a study of “Which World Bank Reports Are Widely Read” found that over 31% of the reports they publish are never downloaded. The knowledge in these reports effectively has a zero footprint.  Just publishing knowledge does not mean a large footprint, the knowledge has to be read and reused.

Some companies incentivise having a large knowledge footprint.

• In Deloitte, the performance appraisals will address what employee has done to contribute value to the firm beyond standard billable hours, including the creation of knowledge  
• A similar approach is applied in McKinsey where one of the ways in which an employee can advance is by gaining recognition outside their own office through knowledge sharing. The knowledge behaviours people exhibit directly affects their promotion. 
• The Fluor KM “Pacesetter” Program uses peer recognition to reward employees who are actively engaged in knowledge sharing behaviours. 
• Boeing offer “Knowledge sharing awards” for people whose knowledge has been reused elsewhere for business advantage.

How big is your knowledge footprint?

The Umbrella week (aka Knowledge Handover) is a face-to-face process for sharing lessons with the rest of the organisation. 

Umbrella week image from army.mil

You can read about a recent Umbrella week here, where Captain Scott Kuhn of the 3rd Armoured Brigade described an event last week. According to Scott, 

Can we use the term “knowledge sharing” as better replacement for the term “Knowledge Management? There are two good reasons not to do so.

image from Wikimedia Commons

The terminology debate continues to rumble on in the KM world, with many people preferring the term “knowledge sharing” over the term “knowledge management”. This is partly due to a distrust of the concept of management, or use of the “management” term especially when used in conjunction with the word Knowledge.

As Tom Davenport wrote in his article “Does Management mean Command and Control?”

One powerful enabler for Knowledge Management is a clear statement from senior management. Here is an example.

Not every meeting or every conversation involves sharing knowledge!

Image from Wikimedia commons

Sharing knowledge is a two-sided process. There is a sharer and a receiver. Be careful that making knowledge easier to share does not make knowledge harder to re-use.

Image from wikimedia commons

Sharing knowledge is like passing a ball in a game of rugby, American Football or basketball. If you don’t place some demands on the thrower to throw well, it won’t work for the catcher. If you make it too undemanding to throw the ball, it can be too hard to catch the ball.  Passing the ball is a skill, and needs to be practised.

The same is true for knowledge. If you make it too simple to share knowledge, you can make it too difficult to find it and re-use it.  In knowledge transfer, the sharing part is the easier part of the transfer process. There are more barriers to understanding and re-use than there are to sharing, so if you make the burden too light on the knowledge supplier, then the burden on the knowledge user can become overwhelming.

Imagine a company that wants to make it easy for projects to share knowledge with other projects. They set up an online structure for doing this, with a simple form and a simple procedure. “We don’t want people to have to write too much” they say “because we want to make it as easy as possible for people to share knowledge”.

So what happens? People fill in the form, they put in the bare minimum, they don’t give any context, they don’t tell the story, they don’t explain the lesson. And as a result, almost none of these lessons are re-used. The feedback that they get is “these lessons are too generic and too brief to be any use”.  we have seen this happen many many times.

By making the knowledge too easy to share – by demanding too little from the knowledge supplier – you can make the whole process ineffective. 

There can be other unintended consequences as well. Another company had a situation as described above, where a new project enthusiastically filled in the knowledge transfer form with 50 lessons. However this company had put in a quality assurance system for lessons, and found that 47 of the 50 lessons were too simple, too brief and too generic to add value. So they rejected them.

The project team in question felt, quite rightly, that there was no point in spending time capturing lessons if 94% of them are going to be rejected, so they stopped sharing. They became totally demotivated when it came to any further KM activity.

 Here you can see some unintended consequences of making things simple. Simple does not equate to effective.

Our advice to this company was to introduce a facilitation role in the local Project Office, who could work with the project teams to ensure that lessons are captured with enough detail and context to be of real value. By using this approach, each lesson will be quality-controlled at source, and there should be no need to reject any lessons.

Don’t make it so simple to share knowledge, that people don’t give enough thought to what they write.

The sharer of knowledge, like the thrower of the ball, needs to ensure that the messages can be effectively passed to the receiver, and this requires a degree of attention and skill.