What I found out about “Tacit and Explicit Knowledge” so far

First I want to mention. I can’t wait to finally read Harry Collins’ book, “Explicit and tacit knowledge” to get more know-how about this topic.

I first was made aware of this topic by some mentions from Mike Larsen, James Bach and Michael Bolton. That was together with the mention of the book, that I still was not able to read yet.

That topic made me a bit more aware of how thinking, knowledge, sharing knowledge, coaching, etc. works. But why? After I was aware of that difference in types of knowledge I began observing that in my daily work and life.

One work example situation is writing a test case. By exploring you found out, how a certain feature works and what scenarios you have to test. You learnt first-hand about the feature, by trying out, by clicking around. You gained a lot of information. Now it’s time to write some test cases or charters for the next time, sometimes called as regression testing. What information do you put in the test steps? How detailed do you have to write it down? What information to skip? In the first place, after learning about the feature, most of your information is tacit. Only you know it, because you did it, you tried it out. You gained lots of information. But what part of those information do have to make explicit, also known as write them down? What information can be put as implicit knowledge, because as a user of a PC or that application, you should have that kind of basic knowledge. But do you really?
I began watching myself from the outside, when writing a test case. What am I writing down? What information is important enough to be noted? Every now and then I get a question or statement from a colleague about some feature, and I say, yes, I know, and do you know about this and that? So I can also make knowledge explicit by talking about it. Shouldn’t I have written about this earlier, is usually my first thought now. Back to the test case. So what do you write down? Everything should not be possible. So you focus on the what you think important information and take a lot of information for granted. But how about the person who has to perform the test the next time? Do you write a test case for trained monkeys or for thinking testers who know the product?
When you write a test case the next time, take a test step and look at the application. What information do you know about this test step? What have you written for that step? Why have you written this information and what other information might be interesting to know besides that?

Another example from work is the so called test automation, or as I like to call it check automation. You take a test case and tell some computer code to perform those actions and what to look for, if the step is passed or failed. The number of questions you ask is usually not very high. That’s the difference between human and machine performance. The human being, hopefully rather intelligent and not bored to death, is looking at the screen and notices most things on the screen and combines the information. The computer is only looking at those places of the screen, that you tell him to look at and what to look for. The information the automation checks for is explicit. You wrote it down as code with exact instructions. The “checks” you perform while executing the same test case are mostly tacit. You are doing them, because you know, what to look at and what to look for.

A visual test map (mind map) is a big collection of explicit information and stands for an even bigger amount of tacit or implicit information. In the map you want to focus on the important stuff, so you skip the less important information. When reading the mind map you know how to fill the gaps, but can all other readers do so as well?

The best example outside of testing I know is cooking. Cooking uses a lot of tacit or implicit knowledge. The recipe mostly states what ingredients to use, how long to cook and wait, and so on. You need a lot of knowledge to understand those instructions. You also need a lot of experience in different cooking techniques to “perform” a recipe. And in every recipe there is the famous “dash of salt”. Now how much is that?

Think more about how you think. Be aware of tacit knowledge, when can it be made explicit and when not. In cases where you are not able to express those information, try to find out why and find a way. Train to write down tacit as explicit knowledge. Use different ways of writing down information, plain text, sketch notes, diagrams, mind maps, or whatever fits best.

Those were a lot of questions, and I am looking forward to reading Collins to understand the differences better and hopefully get some techniques how to transfer tacit to explicit knowledge.