Why "Know-why" is as important as "Know-how" - the monastery cat story

Recording the Know-how is key to Knowledge management, but Know-Why is also important.

Do you know the story of the monastery cat? It goes like this -

Cat at Sovloki Monastery
picture from wikimedia commons

Once upon a time, there was a monastery where the monks meditated from dawn to dusk. One day a cat trespassed into the monastery and disturbed the monks. The head monk instructed that the cat be caught and tied to a tree until dusk. He also advised that every day, to avoid hindrance during meditation, the cat be tied to the tree. So it became a standard operational procedure "To catch the Cat & Tie it to the Tree" before the monks started meditating. 

One day the Head Monk died, the second most senior most monk was chosen as Head monk and all other traditions including tying the cat to the tree were continued. One day the cat died. The whole monastery plunged into chaos. A committee was formed to find a solution and it was unanimously decided that a cat be bought from the nearby market and tied to the tree before starting the meditation each day.  This tradition is still followed in the monastery even today.

A simple story, but carries a clear message - if you don't know why you are doing something, then you don't know when you can stop, or what you can change.

We are working with a client at the moment, who has a good system for documenting Standard Operating Procedures, and updating them with new Lessons Learned as appropriate. This is their way of continually improving their processes, and of institutionalising a form of corporate memory. However there is a risk here. The risk is that they are recording "how to do it" and not "why to do it this way" - the "Know-How" and not the "Know-Why". And if the context changes, and the procedures need to be adapted, then without an understanding of the "why", people won't know how to change. The SoPs could become "Tying cat to the tree".

This is an operational version of "thinking fast and slow". The Fast thinking is to follow the SoP, when all you need to know is "what to do" or "how to react". The Slow thinking is to go back to the principles, go back to the Why, and derive the new operating procedure. Or you could look at is as double-loop thinking - the first loop focused on "what to do", and the second loop on "why do we do it that way".

So how do you record the Know-Why?

You have a couple of options.

• Record enough commentary in the SoP so that you can see what it is based on. For example, one legal company we worked with used to keep standard contracts, but each contract clause had extensive commentary describing why the clause was there, and why it was written the way it was. The contract could then be amended if needed (together with amended commentary) and the commentary stripped out when the contract was printed. That way they preserved the Know-Why.

• Create a secondary document, such as a Basis of Design document. This document takes each element of a project design, a product design or a software design, and described the basis and the assumption son which it was designed. You can create a BoD before the project, and revise it during and after the project to capture changes to the design, and the rationale behind those changes. The BoD then helps future teams working on the same product to make intelligent changes, rather than blind changes. It also helps transfer knowledge to subcontractors working on the project, and protects against loss of knowledge. I recall someone saying to me, about Basis of Design, "I could look at the BoD and put out a quality project design in 2 weeks, and there hasn't been any work done in this area for 2 years".

Recording the Know-why keeps the context, and avoids the risk of repeating the Monastery Cat story.