SOTBOs (statements of the blindingly obvious) in KM

---

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. Then, the tapper predicts how likely it will be that the listener would correctly guess the song. 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 what Chip and Heath, in HBR, called 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. 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 eh reader.

This effect can be seen in written knowledge bases, 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. 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!)

In each case, any facilitator involved in the capture of the knowledge, or any validator of the knowledge base, needs to ask supplementary questions. 

• How much time? How should this time be spent?
• What does "careful planning" look like?
• Who are the "right people"?
• What should be put in place to ensure effective communication?

This further questioning is all part of the issue of knowledge quality control, to filter unhelpful material out of the knowledge base, or lessons management system.

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