Is the Coca Cola recipe knowledge, or information?

This is a reprise and update of an old post, which visits an even older KM argument. 

CocaColaLabel, a photo by purpleslog on Flickr.

There was a heated discussion a while ago on one of the LinkedIn forums, entitled "Is the Coca Cola recipe knowledge, or information?"

There were, as you might expect, two fairly strongly polarised views on the topic, as this is a variation on the age-old debate "does knowledge become information when you write it down", one of those KM arguments than never get settled..

One camp believes that if it's written, it is Information, as Knowledge resides in People, not in Documents.

Another camp believes it is Knowledge, because it is Actionable, and allows someone to know how do something.

My current view is that the recipe is both Knowledge AND Information - Knowledge codified in Informational form. The recipe is amenable to management through IM - it needs to be filed, tagged, archived, whatever - and is also amenable to management through KM - it needs to be understood, learned, transferred, and continually improved.

However I have a deeper view than this, which is as follows;

This is an academic argument and not really something to worry about in a practical sense.

In practical terms, any attempt to transfer the knowledge of "how to make coca cola" would require transfer of the recipe,  plus of course a whole lot more knowledge, some of which could probably never be documented.  The recipe is a case of being either information that helps transfer knowledge, or explicit knowledge, or knowledge codified in the form of information, depending on how you want to argue it, but , whatever you call it, you need to include it in your "knowledge transfer" approach, or as part of your "knowledge asset".

A personal story follows.

When I was 18, I worked in a cake factory as a Mixer, Grade 1.  My task was to mix the pasty for the jam tarts - one hundredweight of flour from the four vats, 56 lb of fat from the fat nozzle, half a hundredweight of sugar and so on.  

The key knowledge was the written recipe, and without that I would not have known what to do. The recipe worked well for routine operations. However there was a lot of other undocumented knowledge, such as the following;

• Don't leave the flour scoop in the flour bin; it builds up a charge of static. If you see the flour scoop in the bin, someone else has put it there and is watching round the corner to see you get a shock.

• At the start of the early shift on a really cold winter morning, don't press the button for the fat, as it will have solidified in the nozzle overnight and nothing will happen, or at least not for a while. The 56 lb of fat will be delivered only later when the nozzle thaws, and will go all over the floor. Instead, go down to the store with a very big bucket.

• You can always get something to eat at the fruit cake off-cuts bin.

The combination of the recipe and this additional experiential knowledge allowed me eventually to operate pretty well in the undemanding world of a Grade 1 Mixer.

My suggestion is not to start with definitions of knowledge, but to start with what a person needs to know, where that knowledge comes from, and how it can be transferred.

The knowledge can be transferred from person to person in many forms, and documents and recipes are one form; vital for routine operational knowledge. It could be argued that the documents themselves are information and that internalisation is required to turn the information in those documents back into knowledge, or it could be argued that the documents contain explicit knowledge per se, but the end result is the same.

However, just because knowledge CAN be transferred using information, this does not mean that ALL information transfers knowledge, nor does it mean that ALL knowledge transfer involves documented information.

Some knowledge comes from experience, and when it's an unpleasant experience like a static shock from a flour scoop, or 56 lb of fat all over the floor, you would rather this knowledge was transferred to you, than to have to learn it the hard way.  So don't worry too much about definitions; thank "what knowledge is needed to do this job, and what is the best solution to give access to this knowledge to the people who need it".

Sometimes the solution is training, sometimes coaching, and sometimes its a recipe.

Every lesson is a story

Capture your lessons as stories, that way they will be remembered more easily.

Native American Storytelling. Photo By: Johnny Saldivar

One of the way humans learn is through stories. Stories can Inform, Educate, and/or Entertain (transmit information, knowledge, and entertainment) and some of the best stories do all three.

A post from the Farnham Street blog entitled "The structure of a Story" tells us that a great story has structure, and includes Context, Action and Result; where Context includes Where, Who, What do they Want, and What's getting in the way. As the blog says

"It all hangs on the central Context, Action, Result (CAR) structure. It starts with the Subject, Treasure, and Obstacle, and concludes with the Right lesson and link back to why it’s being told".

When we transfer Knowledge, story is one of the best formats. That is equally true of lesson-learning as it is of the other elements of KM. Yet all too often, lessons fail to meet the test of a good story.

As the Farnham Street blog says, aspirant storytellers usually start with the Action, because that is the exciting part, and omit the context, and as a result the reader of the story or lesson cannot easily identify with nor internalise the learnings.

When we teach lesson-learning to organisations, we say that Every Lesson is a Story, and we recommend that the lesson has at least 6 components

1) Context. Here we explain what was expected to happen, but didn't. This is the "What did we want" step of the story. It is amazing how many project teams or facilitators skip this step. Because "what was expected to happen" is so obvious to them, they expect it to be obvious to the reader, but of course it seldom is. 

2) Outcome. Here we explain what actually happened - the Action step of the story. What went wrong? What actually happened? 

3) Root cause. Here we explain WHY it happened - what the Obstacles were, what was missing that should have been there, or (in a success story) what was done to achieve the result. 

4) Impact. Here we explain or try to quantify the result, either negative or positive. 

5) Lesson. Based on the root cause, what is the learning for future projects? This is the "Right Lesson" part of the story.

6) Action to Embed.What action do we take to embed that lesson into business process, so mistakes are never repeated, and successes always copied.

A lesson with a story-based structure such as this takes about a page to write down or a couple of minutes to tell, compared to typical bullet-point one-liner lessons - told in seconds, forgotten almost as quickly.

However if we treat every lesson as a story, then we realise that it must be presented as a Narrative, with Context, Action and Result, concluding with the Right Lesson.

This is the simple structure that conveys the message.

The human bias behind group-think

There is a real human bias that drives us to agree with each other, which can drive group think and false consensus 

The power of social proof climbs rapidly
with the number of people involved.
From the Solomon Asch study

Why are "canned laughter" tracks so common on TV comedies?  We all hate them, we know they are false, and yet they keep putting them on the soundtrack.  The reason is that canned laughter is a form of Social Proof, and social proof is a massive factor in the way we think and behave.

Social Proof is the name for the assumption that "if everyone else thinks so, it must be correct". Canned Laughter is a subtle form of social proof; and it works - people judge comedy shows as funnier if there is canned laughter. Even though we know its false, we instinctively think "they are all laughing, so it's funny". The TV executives know we think this way, which is why canned laughter is so endemic.

The Solomon Asch study shows an even more radical form of social proof - how up to 74% of people (as part of a secret experiment) would say something they know is wrong, just to agree with everyone else. Asch concluded that it is difficult to maintain that you know something when everyone else knows the opposite. The group pressure ("Social Proof") implied by the expressed opinion of other people can lead to modification and distortion, effectively making you agree with almost anything.

The risk in Knowledge Management is very clear.

Consensus in a group may mean that everyone agrees because they all independently think the answer is correct, or it may mean that they all agree because everyone else agrees. This is particularly the case when the first person to speak is very confident; everyone else is likely to follow, and so social proof builds up (I talk about this in my blog post on the illusion of confidence, and point out that confidence is often an function of ignorance, especially ignorance in small groups. Real experts are rarely dogmatic).

I saw this for myself in a meeting in Sweden (a country where consensus is particularly valued). I asked everyone to judge the success of a project from their own perspective, to mark the level of success out of 10, and to write that number down in front of them. I was looking for outliers, and I could see that the person next to me had written a 6. We went round the table, the first person said "8 out of 10", and the marks followed - 8,8,8,8. We got to the person who had written down 6, and she said "8" as well.

Social proof is such a well known phenomenon now that it is widely used by marketers to convince us to buy things, and it can be a powerful took when marketing KM in an organisation. However when we are identifying knowledge, discussing knowledge, or trying to determine from a group what actually happened and why, then social proof can drive group-think and distort the truth.

In knowledge management we are not interested in consensus, we are not interested in knowledge as something to sell to others, and we are interested in truth, or as close to the truth as we can get. Social proof is not real proof, and just because everyone agrees with a statement, does not mean they all believe it to be correct.

So how do we avoid conformance and groupthink driven by social proof in KM?

1) When looking for individual objective input, we must avoid "speaking out around the table." In Sweden I could have collected votes on post-it notes, or I could have said clearly "read out what you have written, even if its not what everyone else said".

2) As facilitators of KM processes, we must always ask for the dissenting voice. "Does anyone disagree with this interpretation? Might there be other views here? What are the alternatives? Susan, you are looking concerned, do you have another view?"

3) As online facilitators, we must make dissent safe. I recall one community of practice where, in the first year, social proof was very strong. If anyone disagreed with the first post on a conversation they would not disagree online, but would reply privately. It took a lot of work from the facilitator to reverse this trend, and to develop a community where dissent was welcomed as being part of the search for the truth.

4) We must be careful to avoid using social responses as a form of crowdsourcing. Crowdsourcing works either with an expert crowd willing to share dissenting voices, or with a knowledgeable crowd able to contribute independently. It doesn't work with a small uncertain crowd building on each other's opinions, as that way you can end up with false agreement through social proof.

Social proof is real, groupthink is powerful, and it is one of the many human biases we need to beware of in KM. 

Why definitions of knowledge and Km should avoid using the word "information"

This blog post is a reprise and a rewrite of one I have posted before, and which always drives comment and discussion, but is worth revisiting for a newer audience. 

It covers the difference between Knowledge and Information - that perennial topic of debate - and therefore the difference between KM and IM.  This debate is often driven by assumptions, those assumptions can influence definitions if you are not careful, and definitions can set the scope of your KM work.

It is an open debate how closely knowledge is linked to information, and therefore how valid constructs such as the DIK pyramid are.

 If you define Knowledge as something based on Information ("knowledge is information plus context", "Knowledge is information that allows us to take action", "knowledge is information plus processing") then you are already making an assumption about the link between the two.  This assumption of a link leads to a second assumption that you manage knowledge in the same way as information - through libraries, databases, information bases, knowledge bases, or repositories.

Personally I think there is an equally valid set of assumptions;

1. that knowledge is something you APPLY to information in order to be able to interpret information (see also Drucker's point that information only becomes knowledge in the heads of knowledgeable people, and Ackoff's original explanation that Knowledge is what makes possible the transformation of information into instructions); 
2. that knowledge is more closely related to understanding and to insight than to information. 
3. that knowledge is a function of experience more than it is a function of information, and it is that experience that allows you to handle and interpret information, and to make information actionable (see picture below); 

The three assumptions above lead you to a view that the majority of knowledge is carried by people, and lives in heads and in networks, rather than in libraries, databases, information bases, knowledge bases, or repositories.

The fact that the relationship between information and knowledge is fuzzy and open to alternative views and assumptions suggests that definitions of knowledge should not be based on information, but should stand alone. That is why (or partly why) the ISO 30401:2018 definition of knowledge is "a human or organizational asset enabling effective decisions and action in context". No use of the term Information here. 

If we separate out knowledge from information, then we can also separate Knowledge Management from Information Management. 

Management of knowledge therefore becomes as much or more about the management of people and their interaction, than it becomes about the management of files and documents.  People can interact through documents, and (arguably) documents can carry knowledge, but (as suggested here) Knowledge Management is about the content of the documents - the knowledge held within the documents - and Information Management is about management of the documents themselves (the containers of the knowledge).

Unless you assume that knowledge and information are synonymous, then definitions of KM that refer primarily to information are not definitions of knowledge management.

As an example, the current default definition that pops up on my Google results for knowledge management is "efficient handling of information and resources within a commercial organization". This to me is a definition of commercial information (and resource) management, not KM. Similarly the Wikpedia definition "the process of creating, sharing, using and managing the knowledge and information of an organisation" is a definition of "Knowledge and Information Management" (a hybrid discipline some organisations apply).

ISO 30401:2018 takes a different approach, defining KM as "Management with regard to knowledge" (where knowledge is defined as above). This neatly focuses the topic, and reminds us that KM is not "the management of knowledge" but "knowledge-focused management" - a crucial difference.

In all of this we must remember that the English Language is deficient in this regard, and uses one word for Knowledge while other languages have two.  This lack of nuance is at the root of much of the confusion.

So if you want to avoid putting assumptions into your definition (always a good thing to avoid!), then my suggestion is to avoid any definitions of Knowledge which include the word Information.  To mix the two is to blur the boundaries between KM and IM, to ignore the 5 main differences between the two, and to risk ending up looking only at the management of documents and online content.

Be clear, in order to avoid confusing the disciplines. 

10 tasks for the KM team when KM implementation is complete

When KM implementation is over, the KM team still has a job of work to do

Implementing Knowledge Management is a long project of culture change, and the introduction of a new management framework (roles, processes, technologies, governance).  The Knowledge Management team's initial role is to design and introduce the framework, delivering the required changes in behaviour and culture.

Once that job is done, what role does the KM team have?

Some people say that once this job is done and Knowledge Management is fully embedded into the business, you can disband the team, but that isn't the case.

Once Safety Management is embedded do you disband the Safety team? Once Quality Management is embedded, do you disband the Quality team? No; you retain them, because they still have a key role to play and without them playing that role, Quality performance or Safety performance would revert to pre-change levels. The same would happen to KM.

Here are 10 key elements of that continuing role for the KM team.

1. They need to support usage of the framework. This includes training people in its use, coaching the KM professionals, running the KM CoP, launching other CoPs, building the knowledge asset about Knowledge Management.
2. They need to monitor and report on the application of the framework. This includes checking compliance with the KM policy and expectations, measuring the application of lesson learning, tracking value added through communities , auditing the management level of key knowledge assets, measuring the maturity of key CoPs, collecting results of any KM Dashboards or scorecards. Then reporting a summary of these metrics to senior management.
3. They need to coordinate any KM recognition activity. This includes running annual awards schemes, for example, or finding other ways to recognise the star performers, as well as finding ways to deal with the people who refuse to engage with KM.
4. They need to continue to keep the profile of Km high, through communications campaigns or KM focus weeks.
5. They need to continuously improve the KM framework. This may include improving the company KM policy, bringing in or improving the existing, technology, or adapting the processes and roles;
6. They will be in charge of testing the KM Framework against international standards such as ISO 30401:2018;
7. If new KM technology is needed, the KM team will manage the process of technology requirements definition, and managing a vendor tendering process
8. They may take on specialist roles themselves, such as lessons management, or major lessons capture, development of KM plans for major projects, and big Retention exercises.
9. Indeed, if your Knowledge Management strategy is a Retention strategy, the KM team may run the Retention process (planning, prioritising, interviewing etc)
10. The KM team will act as client for any outsourced KM services.

The KM team has a job of work still to do - to manage, maintain and continuously improve the KM Framework - and these 10 tasks form the core of their work.

If you outsource knowledge work to contractors, make sure they have KM in place

If you outsource knowledge work, make sure the contract requires the contractor to have KM in place. 

Contractors review plans,
by US Army Corps of Engineers, on Flickr

A few years ago I was running a multi-day lessons capture event with a company that had recently commissioned construction of a large production plant.

 Here's a story that the client project manager told at the event.

"This plant was based on a similar plant built by the same contractor, and on that previous plant they had made a big construction error - in one of the emergency release lines, they had put a non-return valve in backwards. Had there been an emergency, this could have been a disaster. We spotted the error, fixed the valve, and we discussed it, together with other lessons, with the contractor at the end-of-project lessons capture session.  

So this time, when I was walking the lines, I thought 'shall I bother to check that valve? Surely they would not have put it in the wrong way round again? But I thought - better safe than sorry - and blow me down, it was the wrong way round again!"

Disaster averted for a second time, but what's the moral of the story?

The moral is that when we outsource work (to a contractor, or to an outsource provider) we are also outsourcing the knowledge of how to do the work. We  expect the contractor or the provider to bring the knowledge needed to deliver the work properly.

And when we outsource the knowledge, we outsource the management of the knowledge as well. We expect the contractor or provider to learn - to constantly improve their knowledge - to never repeat mistakes.

So what went wrong on this case? Who was to fault?

Obviously the contractor was at fault; they should have had a proper KM system in place, with closed-loop lesson-learning, which eliminated repeat mistakes. And there is nothing worse for a contractor than having a client with a better KM system than you - who knows your repeat mistakes before you do!

However the client was equally at fault. They assumed that "Surely they would not have put it in the wrong way round again? Surely they would have learned?".

But this was an assumption. There was nothing in the contract that stipulated a KM system, and no audit of the contractors learning ability. The client just assumed, and we all know what Assume makes!

The moral of this tale is that if you outsource major work, you also outsource the knowledge needed to do the work, and you need to outsource the management of that knowledge as well. Therefore make sure that your contractor has a top-notch, independently audited and verified, KM and learning system, with the sort of closed-loop learning that eliminates repeat mistakes.

Make sure this "effective KM" is stipulated in the contract.  require your contractor to demonstrate an effective KM approach, compliant with ISO 30401:2018.

And its still worth walking the lines and checking as well - just in case!

The "Designing Buildings" wiki

The "Designing Buildings" wiki is a nice example of managed industry knowledge

The Designing Buildings Wiki, pictured below and explained above, is a wiki for the construction industry.

It is active - with 5 million users, 14 million page views per year, and plenty of new edits and content added in the last few days. It's 7500 articles cover topics such as project planning, project activities, legislation and standards and industry context, It also contains overviews of iconic buildings such as Number 10 Downing Street, the White House, the Palm Atlantis and the Bank of China Tower.

It looks like it uses MediaWiki technology, and is edited by Designing Buildings limited.  It has useful features such as a "related articles" box, and a "featured articles" section. It even contains a section on Knowledge Management in construction.

This is a really good showcase for the power of wikis