Due to COVID 19, all workshops and courses are remotely given for the foreseeable future.

Janet Gregory: Agile Consultant, Trainer, Advisor, Writer, Speaker

A couple of things happened last week which made me look at how we share knowledge.

The first incident was when I was showing my granddaughter how to make lefsa, a traditional Norwegian potato flatbread/pancake that we make. I opened my recipe book and had her follow the recipe. It became obvious very quickly, that the recipe wouldn’t work. It wasn’t that it was incomplete – it had all the ingredients, measurements, and even a ‘how’ part. It was missing pieces of information that I “just” knew from years of experience.

For example, the mashed potatoes that I cooled yesterday, had to be taken out early to be at room temperature (not necessary, but makes it so much easier). The recipe says four cups of mashed potatoes, but what do you do if you have five cups? It also didn’t say to “pack” the mashed potatoes when measuring.

The ingredients were all there, but not in any particular order, and the mixing instructions didn’t specify the order. It also didn’t say that when stirring starts to get difficult, you should use your hands to knead, and look for the right consistency adding more flour if needed. It didn’t tell you how much dough to use to form into a ball for rolling it out, or how to use the lefsa stick to turn the lefsa on the griddle.

For a new cook, there were so many missing pieces that are part of the tacit knowledge we learn from experience. I learned from my mother and use the recipe only for the list of ingredients.

So much of creating excellent lefsa is from look and feel, and the only way to get that, is by apprenticeship, or mentoring … or a lot of trial and error.

How much of that do we do in our own jobs? How often do we assume that because we wrote it down, that others can follow the ‘recipe’?


Figure from: https://www.researchgate.net/figure/Explicit-vs-Tacit-Knowledge_fig2_264799777

Recently, I was interviewing a release manager and asked him if the implementation steps were tested before releasing (manually) to production.  His reply was, “Of course. The developers write what needs to be done, and I follow the steps.” He is a very experienced release manager and has done this many times and I suspect that he uses the steps as guidelines like I do with my lefsa recipe. I asked him if he were away, could someone else could follow the steps? He seemed upset that I would even think that may be an issue. In my experience, instructions should be tested by someone who is not the expert.

I believe in simplicity – for example, if I can’t automate a test, how can I keep it as simple as possible? Perhaps writing an exploratory test charter so people can use their own experience and critical thinking skills. Maybe we could use a mind map to show what we need to test for. However, for these to work, people need to have more than a passing knowledge of the application(s). This is where good mentoring and pairing practices has real value.

When teaching someone else or when pairing with others, teach them to ask questions like “Why are you doing that?” or to recognize that you use a specific technique and ask, “Can you share it with me?” For example, my granddaughter was trying to get the sticky dough off her fingers, so I sprinkled a little flour on her hands to rub together, and she thought that was magic.

Like some of the best handed down recipes, it is the tacit knowledge that is important. Some of the important knowledge of applications and testing techniques, are passed to others by sharing, and not by writing it down. Consider how to share your mental model of how to do … most anything. It is often difficult to articulate what you do, but I encourage you to try.

One last point to make – some of the implicit knowledge that is passed down through the ages can become obsolete. Things change, and sometimes we need to challenge the status quo. I have experimented and sometimes found out the reason it was done that way in the first place, and have added that to the recipe for the next person. We can do the same thing in our work – we get jaded, and often overlook things that are ‘just’ accepted as fact. This is where having fresh eyes to challenge can be important; however, we must be open to those ideas to use them effectively.


One comment on “Implicit/Tacit vs Explicit Knowledge

Leave a Reply

Your email address will not be published. Required fields are marked *