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”
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)
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?
Without this, people rapidly give up on the knowledge base as being “unhelpful”, and full of SOTBOs.
Tags: knowledge capture, lessons learned