How knowledge is born - Observations, Insights, Lessons

Knowledge is born in a three-stage process of reflection on experience; from observations, through insights, to lessons.

Experiencing, Learning, Reflecting, by Denise Krebs on Flickr

I think most people accept that knowledge is born through reflection on experience. The three-stage process in which this happens is the core of how the military approach learning from experience, for example as documented in  this presentation from the Australian Army (slide 12).

The three stages are the identification of  Observations, Insights and Lessons, collectively referred to as OILs. Here are the stages, using some of the Australian Army explanation, and some of my own.

• Observations. Observations are what we capture from sources, whether they be people or things or data or information or events. Observations are "What actually happened" and are often compared to "What was supposed to happen" (the gap between "Supposed" and "Actual" is a gap of Surprise, which is the first sign that there is new knowledge to be found).  Observations are the basic building blocks for knowledge but they often offer very limited or biased perspective on their own. However storing observations is at least one step better that storing what was planned to happen (see here). For observations to be a valid first step they need to be the truth, the whole truth (which usually comes from multiple perspectives) and nothing but the truth (which usually requires some degree of validation against other observations and against hard data).

• Insights. Insights are conclusions drawn from patterns we find looking at groups of observations, or from analysis of a single observation.  They identify WHY things happened the way they did, and insights come from identifying root causes. You may need to ask the 5 whys in order to get to the root cause.  Insights are a really good step towards knowledge due to their objectivity.  The Australian Army suggests that for the standard soldier, insights may be as good as lessons. 

• Lessons.  These are the inferences from insights, and the recommendations for the future. Lessons are actionable knowledge which has been formulated as advice for others, and the creation of lessons from insights requires analysis and generalisation to make the insights specific and actionable . The Australian army defines lessons as "insights that have specific authorised actions attached.... directed to Army authorities to implement the stated action", and there is a close link between defining an actionable lesson, and assigning an action to that lesson. Note however that the lesson is not "Learned" until the action is taken, and sustainable change has been made. 

This progression, from Observation to Insight to Lesson represents the methodology of learning by reflection. The Retrospect meeting and the (smaller scale) After Action Review both provide a structured discussion format which moves increments of knowledge through the three stages..

In other organisations these three stages are separated. Perhaps observations are collected by (for example) users, a separate team of analysts use these observations to derive insights, and then an authoritative body adds the action and turns the insights into lessons. 

My personal preference is to address all three steps as close as possible to the activity which is being reviewed, using the same team who conducted the action to take Observations through to Lessons.

But however you divide the process, and whoever conducts the steps, these three stages of Observation, Insight and Lesson are fundamental to the process of learning from experience. 

The three levels of lesson-learning - don't get stuck at level 1!

Here is a reprised blog post presenting 3 potential levels of maturity for a lesson-learning system. Many or most organisations are stuck at level 1.

Lesson-learning is a common component of KM management systems, and there are three levels of rigour, or levels of maturity, regarding how Lesson-learning can be applied.

• The first is to reactively capture and document lessons for others to search for, find and read ("Lessons for Information");
• The second is to reactively capture lessons at the end of projects and after events, document them, and as a result make changes to company procedures, practices and training ("Lessons to Make Change");
• The third is to proactively hunt lessons from wherever they can be found, and make changes to company procedures and practices so that the lessons are embedded into practice. 

Lesson-learning can be a very powerful way for an organisation to learn, change and adapt, but only if it is approached in a mature way. Level 1, to be honest, will not add much value, and its only when you get to level 2 that Lesson learning really starts to make a difference.

Let's look at those levels in more detail.

Level 1

Level 1  is to reactively capture lessons at the end of projects, and document them so that others can learn. Lessons are stored somewhere, and people need to find and read the lesson in order to access the knowledge. There are sub-levels of maturity in level 1, which include

1a) Ad-hoc documentation of lessons by the project leader, documenting them and storing them in project files with no quality control or validation step. Lessons must therefore be sought by reading project reports, or browsing project file structures

1b)Structured capture of lessons, through scheduled lessons identification meetings such as retrospects, documenting and storing the lessons in project files with no quality control or validation step.

1c) Structured capture of lessons, through sheduled lessons identification meetings such as retrospects, documenting and storing the lessons in a company-wide system such as a lessons database or a wiki. This often includes a validation step.

1d) Structured capture of lessons, through lessons identification meetings such as retrospects, documenting and storing the lessons in a company-wide system with auto-notification, so that people can self-nominate to receive specific lessons.

Level 2

Level 2 is to reactively capture lessons at the end of projects, document them, and as a result make changes to company procedures and practices so that the lessons are embedded into practice, procedure, guidance, design and/or training. Here people do not need to read the lesson to access the knowledge, they just need to follow the updated and improved practice etc. Lesson learning has become integrated into, and drives, continuous improvement. Again, there are sub-levels of maturity in level 2, which include:

2a) Lessons are forwarded (ideally automatically, by a lesson management system) to the relevant expert for information, with the expectation that they will review them and incorporate them into practice, procedure guidance or training;

2b) Lessons include assigned actions for the relevant expert, and are auto-forwarded to the expert for action;

2c) As 2b, with the addition that the actions are tracked and reported.

Level 3  is to proactively hunt lessons from wherever they can be found, and make changes to company procedures and practices so that the lessons are embedded into practice.  There are not enough organisations at level 3 to recognise sub-levels, but there are some ways in which Level 3 can operate

3a) Senior managers can identify priority learning areas for the organisation. Some projects are given learning objectives; objectives for gathering knowledge and lessons on behalf of the organisation. These may be written into project knowledge management plans. 

3b) Learning teams may analyse lessons over a period of months or years to look for the common themes and the underlying trends - the weak signals that operational lessons may mask.

3c) Organisations may deploy specific learning resources (Learning Engineers, Project Historians, etc) into projects or activity, in order to pick up specific learning for the organisation. See this example from the Australian emergency services. 

I have only really come across level 3 in the military and the emergency services.  For example, see this quote from Lieutenant-General Paul Newton

"The key is to ‘hunt’ not ‘gather’ lessons, apply them rigorously—and only when you have made a change have you really learned a lesson. And it applies to everyone … It is Whole Army business". 

However even level 2 is quite rare. Many organisations have not gone beyond the "document and store" stages of Level 1, and often have been disappointed by the outcomes, and by the tendency to re-"learn" lessons over and over again. After all, in Level 1, nothing changes, and if nothing changes, nothing has been learned. 

If you aspire to be a learning organisation, set your sights at levels 2 or 3.

Your business plan is wrong. That doesn't matter if you can learn fast enough.

The world is too complex for us to get things right first time. So what matters is the speed at which we adapt and learn.

Image from wikimedia commons

The British historian Michael Howard wrote, on the subject of military doctrine,

"I am tempted to say that whatever doctrine the armed forces are working on now, they have got it wrong. I am also tempted to declare that it does not matter. What does matter is their ability to get it right quickly, when the moment arrives......When everybody starts wrong, the advantage goes to the side which can most quickly adjust itself to the new and unfamiliar environment and learn from its mistakes."

In a complex and changing environment, it is the agile and the adaptive who survive. Everyone starts wrong, but the adaptive get righter quicker.

This is as true in the marketplace as it is on the battlefield. Planning is essential, but plans are not enough. No plan of battle ever survives contact with the enemy, and no commercial strategy or marketing plan survives contact with the market, the customer and the competition.

If Howard is right for business as well as for the Military, and that the advantage goes to the organisation that most quickly learns from its mistakes, then Knowledge Management and Organisational learning is a survival strategy.

An organisation must be confident enough to embark into the unknown, prepared to modify or even abandon processes, practices and plans, based on focused and high-quality learning. Knowledge Managers must attend to

• Increasing the clock speed" of organisational learning to increase your adaptation rate
• Removing the waste from the knowledge supply chain to make KM more lean and efficient
• Maximising signal to noise in knowledge transfer to make the learning signal clearer, and
• Bursting the knowledge bubbles to make sure the decision makers are open to new knowledge. 

An organisation can then learn its way forward in an agile way, learning from mistakes and successes, "sounding the way forward" to find the safe passage. This is as true in the post-Covid recovery world as it ever has been. 

Knowledge has a shrinking half-life, and where knowledge has a short half-life, Knowledge Management is not about documenting and protecting "what you know", it is about how fast you can know something new, and how easily you can let go of the old. That's what will win you the battle with the competition.

 Colonel Ed Guthrie of the US Army used to liken it to the aerial dogfights in world war 1.

"In those days" he used to say, "It was about getting inside the other guy's turning circle. That's what would win you the engagement. Now it's about getting inside the other guy's learning circle."

So whatever your business plan is, it's wrong, and it does not matter. What does matter is your organisations ability (enabled by Knowledge Management) to quickly adjust itself to the new and unfamiliar environment and learn from its mistakes and successes.

How escalating lessons can help burst knowledge bubbles

Any lesson learning system requires a method for escalating lessons. However escalated lessons may need to break through "knowledge bubbles". How do we reconcile these two issues?

Rainbow bubble by Lena on Flickr

As we have often argued on this blog, the purpose of lesson learning is to drive change and continuous improvement. If nothing changes, nothing has been learned. Each lesson therefore must lead to an action or a request for action, and the action must lead to change. Once the change is made, the lesson has done its job. 

But change can be hard when people do not want to change, and where they protect themselves by knowledge bubbles; hearing only what they want to hear. How can we address this issue?

The issue arises when the team that identifies the lesson does not have the authority to make the change, and has to escalate it to a higher level. Maybe the team has identified a company process that needs to be updated or written. Maybe an equipment redesign is needed. 

These are actions for either the company process owner or the person who holds the contract with the equipment supplier. Neither of these people is in the team, and the team leader doesn’t have authority to tell them what to do. The action has to be escalated to a level where the required authority lies - perhaps with the head of projects, the leader of a particular functional discipline, or a member of the senior level steering group.

Here we run into the issue of the Knowledge Bubble. 

The knowledge bubble is the unwillingness of people to believe new knowledge that contradicts their world-view, for example Stalin's refusal to believe that Hitler was about to invade Russia despite the huge amount of intelligence which proved otherwise. It's not just dictators that face this issue - all of us cherish our own established knowledge and views, and are reluctant to change them.

How then can we ensure that the head of projects, the functional leader and the senior level steering group are not protected by knowledge bubbles, and that they are open to new knowledge supplied through the lessons system? The political version of this is "speaking truth to power", and is not an easy thing. Likewise telling management that change is needed, based on lessons from the troops, can also be difficult at times. 

There are 8 ways in which we can help escalated lessons break through any knowledge bubbles./ 

1. The senior people need to be involved in, and have ownership of, the lesson learning system. Their roles need to be well defined, and they should have been consulted during the design of the system.

2. The lesson learning system needs to be applied rigorously, so that the senior people can expect to see a flow of escalated lessons as part of normal business.

3.   The lesson learning system needs to be quality-controlled and validated, perhaps by the technical experts, so that the senior people know that lessons represent real knowledge rather than opinion. This implies that the documented lessons should show the evidence and the root cause analysis behind the request for change.

4. The lessons must have some measure or description of impact, so the senior people can realise the importance of making the change

5. The lessons must be associated with an author, so the senior people know who to contact for more details

6. The senior people must not be able to reject a lesson without both registering that they are rejecting it, and giving a reason for rejection. 

7. The lesson learning system must be monitored and reported to a senior level, so that the organisation knows whether lessons are being consistently ignored or rejected by certain individuals or groups. 

8. Through their involvement, management must collectively accept accountability for the operation of the lesson learned system. 

The last component is key. It is this accountability, linked with monitoring and reporting, that identifies and maps out the knowledge bubbles, which the most senior management of the organisation (provided they buy into the concept of organisational learning) must then use their influence to dismantle. 

In a comment to an earlier version of this post. Lisandro Gaertner said that in his organisation:

"We work with a two step implementation process. First the technical experts assure the quality of the knowledge and, when it needs further actions to implement, it is passed on to the senior leaders who should tell how, when and by who it will be implemented or why it is not going to create changes on the company. The senior leaders are then accountable for the knowledge they didn't implement. It empowers the employees and create a system to fight the knowledge bubble".

This is a combination of many of the approaches above, with emphasis on the assurance role of the experts, and the accountability of management. 

Contact knoco for guidance on building a bubble-proof lesson-learning system

Do learning leaders produce learning organisations?

Do learning organisations require learning leaders? Almost certainly they do, but will learning leaders require their organisations to learn as well?

How well do leaders learn?

There is the stereotype of the bull-headed CEO, hanging on to their dream, forging ahead single-mindedly until they dominate the industry. But is that reality? Can leaders win in today's world without being continuous learners?

A lot of work has been done by the Korn Ferry institute on what they call "Learning Agility" in leaders (see this book for example).  I quote from one of their online reports (now no longer available).

"Successful executives learn faster than those who ‘derail’, not because they are more intelligent, but because they have the necessary skills and strategies, and are therefore ‘learning agile’. By contrast, those that do not learn from their jobs, and simply repeat their previous performance in each new role, will never become the most effective leaders"

I was reminded of this when reading a Guardian article about the All-Blacks Rugby coach, Graham Henry, describing how his autocratic leadership style changed under challenge. Here is an excerpt

Henry says. “I was arrogant, just so up myself. And it killed me. I’m still alive but it killed me. I realised then that I had to change.” In 2005, Henry was approached by the All Black captain, Tana Umaga. “Coffee, Ted?” he said. “Alright, T,” Henry replied, thinking to himself ‘What’s going on here?’ After a while, Umaga asked: “Ted, what do you give those team talks for?” Henry thought about it. “Well, T, I thought they might provide the team with a bit of motivation, a bit of direction, before the match.” Umaga paused. “Ah, but are they for you, Ted, or are they for us?”  

 The team talk had been part of Henry’s ritual for 30 years. “You spend the week before each game building the momentum of the group. As you do that, you transfer the responsibility from the coaches to the players but then an hour before the game, there is a fella up the front telling them what to do. I realised it just didn’t fit.” He never gave another team talk.

Thats the story of a leader willing to change under challenge.  But if a leader is willing to learn and change, will they come to expect that from their organisations? And will they enable and expect their teams to give them clear and honest feedback, so the organisation and leader can learn together?

If the future CEO is learning-agile, can we expect them to develop a similar learning agility in their organisations?

Building an agile learning organisation

The Graham Henry story certainly goes on to describe how, having dropped his autocratic style, he set about building an agile organisation involving

• Empowerment - involving the players in building the culture and strategy of the team
• Delegation of decision making - the decision making within the match was delegated, with the team overriding the coaches instructions if they felt there was a better way
• Inclusivity - bringing new players into the coaching set-up to start building their knowledge and experience
• Contingency planning - working out what might go wrong, and having contingency plans

 And ultimately Henry was successful, coaching the All Blacks through a winning World Cup in 2011 before retiring. 

Leaders who learn could, and should,  build learning organisations around them. That's how you win. 

How even 10-year-old space scientists capture their lessons

Here is an interesting story about a couple of scientists who created a craft which reached the edge of space, and who (as good knowledge workers should) captured their lessons learned afterwards. The surprise is that they were only 8 and 10 years old at the time!

The young scientists' lessons log
image linked from Geekwire

(Thanks Vince for forwarding the story)


The story tells of two Seattle girls who designed, built and launched a balloon-powered craft which took a camera, a lego R2D2 and a picture of their cat Loki to the edge of space at 78000 feet, and then recovered the craft and the video footage.

The video below tells the whole story, but the part which most interests a knowledge management professional like me is that they captured their lessons learned afterwards.  The image to the right is their lessons log, linked from the geekwire article.

This is excellent practice, Should the two girl scientists build another craft, their lessons will help them to build on the success of their first launch, and exceed it in terms of height, flight duration and video record.

Lessons log

If you click on the picture you can see the details of the lessons. These are typical lessons from an After Action review, written as short sentences and as aides memoire for the same team to re-use in their next attempt. If these were lessons to share with other space scientists, the girls would need to go beyond statements like "use a bigger balloon" to actually define how big a balloon they think is needed.

It is interesting to see 11 lessons. If the girls could collect 11 great lessons from one balloon flight, then it makes a mockery of project managers saying "just give me the top three learning points". Top three are fine if you have only learned 3 things, but if you have learned 11 things, record them all!

Congratulations to the girls on their pioneering flight, and also to their mother and their father  for teaching them not only how to do good science, but also how to capture their knowledge for next time.

Contact Knoco for a free lessons log template

How to learn like an ant

Social and organisational learning is so easy that even ants can do it, and we can learn from the principles they apply.

Leafcutter ant trail by Jasper Nance on flickr

If you look at an ant trail from the nest to a source of food, it is pretty direct. The food may have been found by a random foraging ant, but pretty soon the whole colony has been alerted to the food, and developed a path that approximates to the quickest route between the food and the nest.

So how do ants collaborate to build the "best route"? Do they design it, or do they evolve it through continuous improvement? And if the latter, exactly how are these continuous improvements made? How do ants LEARN to make a straight path?

1. When ants move, they leave a scent trail behind. It's a fading trail - immediately after depositing, it starts to fade. Initially their trail is pretty random, and may zigzag all over the place. Other ants follow the trail, following the strongest scent, but not 100% faithfully. There's a little bit of variation built in.
2. Because of that variation, ants will sometimes find a shortcut, and cut out one of the zigzags. Wherever they cut the corner and get there faster, their scent is stronger, and becomes the dominant trail. Other ants follow them. If their new way takes longer (a longcut), their scent has faded, and others don't follow. For the ants - faster is better as it is more efficient.
3. So the improvements in the trail are reinforced, and the trail gets progressively better and straighter. Over time, the trail becomes straight.

For ants, the organisational memory lies in the trail itself, embedded in the scent. For organisations, the organisational memory lies in the processes. We can follow the principles of Ant-learning, if we replace the scent-trail with the operational procedures.

1. We record our knowledge in operational procedures, which represent our current best approach to doing a particular task. Initially the procedures may not be particularly effective, and people are allowed to vary from the procedures if they find a better way.
2. The variations are recorded as process improvements or lessons learned and embedded in improved procedures, like the new scent trail along the shortcut.  There needs to be some way to know whether the new variations are better. Perhaps they improve efficiency, or quality, or cost, or customer satisfaction. You need to be able to tell what "better" looks like.
3. Other teams follow the new better procedures (like the ants following the stronger scent) so that these become the dominant procedures - until the next improved variation is found. Over time the procedure becomes optimal. 

You can see this learning process at work in any continuous improvement process, whether it is a drilling crew improving their rig procedures, a lean manufacturing team improving their manufacturing procedures, or an Army improving their doctrine. They all learn like an ant - recording and embedding the improvements until the trail is straight.

Personal learning, KM and the 170:20:10 rule

The 70:20:10 rule is commonly quoted, as in this video by Steve Trautman, as representing the three ways in which people learn.

• 10% of our learning, comes from formal training
• 20% of our learning comes from structured mentoring, from a senior to a junior, or teacher to learner
• 70% of our learning comes "On the job". 

In the video, Steve suggests that this on-the-job learning happens by osmosis - "they go to work, they hang out, they are in the space, and they learn".

The dictionary calls osmosis "the process of gradual or unconscious assimilation of ideas, knowledge, etc". Well, in KM its not gradual, it's "just-in-time", and it's conscious, not unconscious. The use of Knowledge Management can deliver on-the-job learning in a far more effective way than just osmosis.

• Reflective team learning practices such as After Action Review and Retrospect allow people to discuss what have been learned, and become conscious of learning, thus accelerating personal learning. 
• Good knowledge bases form an explicit learning resource for people to learn on the job.
• A community of practice forms a tacit learning resource for people to learn on the job.

So instead of knowledge "just happening to flow", as in the random movement of molecules through a membrane which we call osmosis, the KM processes and framework become a sort of "ion pump for knowledge" (one for the cell biologists there).

So maybe we can change the 70:20:10 rule. If KM is better than osmosis, maybe its a 170:20:10 rule, and people learn twice as much.

• 10% of our learning through formal training
• 20% of our learning through mentoring and coaching
• 170% of our learning through KM processes and tools. 

A combination of formal learning and development, mentoring programs and Knowledge Management therefore covers, and expands, the entire spectrum of learning.

KM and Hansei, where "no problem" becomes a problem

Effective learning within an organisation requires consistent and rigorous self-analysis, in order to pick up learning points and points of improvement. In Japan, this process is known as Hansei.

Hansei, by Jim O'Neil, on Flickr

Although alien to many in the west, Hansei is an important part of the Japanese culture. Han means “change” and Sei means “to review”, so the whole thing means “introspection” or “reflection for the purposes of change”.  This translates into a behaviour , instilled from childhood, of looking for mistakes, admitting responsibility, and implementing change.(When Japanese children do something wrong, for example, they are scolded and are told: hansei shinasai - Do hansei!).

Hansei can become very public, as the footage of the crying Toyota CEO shows. As a response to poor safety performance, the CEO admitted responsibility, apologised, promised change, and wept - behaviour lauded in Japan but deemed strange in the West. In the West we would probably avoid responsibility, deny the mistake as "fake news", and insult our detractors.

Hansei is at the heart of Kaizen - the "learning from experience" approach seen in Japanese industry. It may part of the reason why Japanese companies succeed so well at Kaizen as a core component of Knowledge Management, while other cultures struggle. Where a European company might see lesson-learning as a witch-hunt, for example, a Japanese company would see it as a way to put right the embarrassment of self-acknowledged failure. Where a US company might fear a blame culture, Hansei means that individuals already accept any blame and if they fear anything, they fear the lack of ability to make restitution.

How do we develop Hansei?

In non-Japanese cultures we have not been brought up with Hansei. Seeing our leaders accepting full responsibility for mistakes and sincerely, with emotion, promising change is something exceedingly rare (name me one example!).  However this is a behaviour we would dearly love to promote at work, so that mistakes are not hidden, but lead to learning and change.

So here are six things we can do to begin to develop Hansei behaviours.

1. We can understand the current culture, and recognise the barriers. One of the 10 cultural barriers is defensiveness - an unwillingness to take responsibility and examine your mistakes. Our cultural assessment service allows you to see whether this is a major barrier in your own organisation.

2. We can build reflection into the work process. After Action Review, for example, is a Kaizen activity that can be embedded into the working pattern, to trigger reflection and change on a regular basis.

3. We can adopt no-blame learning processes. The Retrospect is widely recognised as a no-blame lesson-learning process for use at the end of projects or project stages. The open questioning within the Retrospect gives people the opportunity to examine what went wrong, and to suggest how this might be improved.

4. We can ask the team leader to set the tone. If we are concerned about lack of openness in a Retrospect, we can work with the team leader before hand to identify an area where they can openly admit to making a mistake, and explore how to avoid this happening again. When the leader sets the tone, the rest of the team may follow.

5. We can ensure all learnings lead to action. We must make sure that everyone present in a Retrospect or After Action review can see that their admissions, introspections and lessons will lead to action. Lessons will not just rot away in overstuffed databases, but become embedded in changes to process. Knowing that your mistakes can be turned into successes for others can make Retrospects into something like group therapy. This is the positive outcome of Hansei.

6. We can become intolerant of complacency. Another of the 10 cultural elements, complacency is the feeling that "we did alright, there was no problem, we don't need to change anything".  Here is what the Toyota website says about "no problem":

"Even if a task is completed successfully, Toyota recognises the need for a hansei-kai, or reflection meeting; a process that helps to identify failures experienced along the way and create clear plans for future efforts. An inability to identify issues is usually seen as an indication that you did not stretch to meet or exceed expectations, that you were not sufficiently critical or objective in your analysis, or that you lack modesty and humility. Within the Hansei process, no problem is itself a problem".

This type of thinking - where "no problem" is seen as symptom of a lack of introspection and a lack of analysis, and something to challenge rather than to feel smug about - may be what separates the  true learning cultures from the also-rans.

More on learning from success and failure

Here is a useful boston square on learning from success and failure

I blogged earlier this month about "Win or lose, you should always learn".  However the learning strategy you employ depends very much on whether you are in a fail-safe environment or whether (as in the Apollo 13 tagline) "Failure is not an option". 

There is a lot of praise on the internet for learning from mistakes, almost to the effect that  it seem that if you don't fail, you can't learn. Learning from mistakes is imperative for sure, but in some contexts, where mistakes are costly or fatal, they should be avoided at all costs. In these contexts the focus should be on learning from the experiences of others (both successful and unsuccessful) to eliminate your own mistakes as much as you can, and when you do eventually encounter the mistakes, to know how to recover quickly.. 

The Boston Square above breaks out these scenarios.

1. In  failsafe environment, study carefully the root causes for your own success and failures (and those of others) to continuously improve and finally succeed. 
2. When failure is not an option, study carefully the root causes for your own success and that of others, to avoid failing, and study even more carefully the root causes for failure of others, and the mitigations they used to address that failure, to minimise failing yourself and to recover quickly if you do.

I make the point about root cause - it is not enough to replicate the actions of others if you want to succeed; you need to understand the root causes behind success if you want to replicate it on your own context. 

For a final word on the matter, here's a quick video from Jack Ma.

Win or lose, you should always learn

People often make a big thing about learning from failure, but learning from success is just as important, and can often be overlooked.

Crossroads by Chris Potter on Flickr and stockmonkeys.com

The impetus to revisit this topic came from a one-liner post on LinkedIn by Oleg Vishnepolsky reading "Sometimes I win, sometimes I learn."

My reply was "Win or lose, you should always learn".

Sometimes it seems as if learning is reserved for failures. If there is a safety near miss, or an incident in a hospital, or technical non-conformance, then learning swings into action. When all goes well, learning is an afterthought. And it is certainly true that individuals learn much better from their mistakes, as a result of the emotional charge and the emotional scars that failure brings.

However you can argue equally strongly that success is a better teacher, because a fail mode only tells you one option not to try; it does not tell you how to succeed. So as well as learning from a hospital incident, you should learn from, and emulate, those hospitals that never had an incident, or those suppliers whose technical products always conform. This is the principle behind positive deviance - the idea that there are always positive outliers; individuals, groups or companies that perform far better than their peers, and which should be the first place you look to for learning.

Which is the better approach - learning from success, or learning from failure?

This is of course another one of KM's "false dichotomies". Someone in NASA once said (and I can't find the source of this quote I am afraid) that "in NASA we say there are no successes or failures, there are only Events. We learn from Events." The whole concept of success and failure is irrelevant to learning. Most events, most projects, are a mix of both, and we need to learn from both.

Learning from failure helps you learn how not to fail, learning from success helps you learn how to succeed. You need to decide which is more important. 

At a corporate level, or as a society, we collectively make the biggest learning steps when we finally succeed. Think of Edison and his light filament; when did he do the most learning? When he tried each of the 99 options that didn’t work, or when he found the one that did? Now obviously he learned from both, but let’s look at the value of that knowledge to others.

If you were a light bulb maker, which of these two statements from Thomas Edison would be of most value to you?

1. You can’t make a light bulb filament out of cat hair 
2. You can make a light bulb filament out of tungsten 

Obviously, the second one. He learned from the first, but all of us have learned from the second.

And here are a couple of quotes from the Business insider article mentioned earlier about some of teh risks from learning only from failure;

When you continually focus on failure, you actually create an environment where people are afraid to share their successful actions, lest they appear to be bragging, making light of an otherwise bad situation, or taking advantage of someone else being called out for their failures. This keeps truly useful learning from becoming a part of your organization's practice. 

More existentially, continually focusing on failure is disastrous for morale. It's one thing to avoid sweeping toxic stuff under the rug, but it's another to always leave a stinking pile of crap in the room. 

Fortunately, it's very easy to make a cultural shift here. You just need to ensure that at least some of your "after action" reporting, whether it occurs in meetings or memos or informal hallway chats, is dedicated to what went right. Even an event that was largely a failure probably has some small successes that need to be shared.

 This is why, in the Retrospect meetings that Knoco often facilitates, we give equal discussion time to success and failure. An in some cultures such as the UK culture (where people are always happy to talk about failure) we start by discussing the successes, lest these get ignored.

The implication for Knowledge Management

The implication for Knowledge Management is this:

You need to learn from both success and failure, but you need to learn much more carefully and deliberately from success, because: 

• success can be less obvious - you may have to look for those positive deviance examples;
• learning from success can be more difficult (it is easier to isolate what went wrong than what went right); and
• ultimately, success is what you want others to replicate.

As an example, let's look at the typical systems set up to learn from safety incidents. Most of these systems have detailed root cause analysis when there is a near miss or an incident, and the lessons from these are sent around the organisation so others can learn from this safety failure.

However it is far more important to learn from the (positively deviant) factory or plant that never has an accident, and never has a near miss. That is the factory everyone needs to emulate, which means they need to carefully understand WHY they are so safe, and then learn from this.

We know that it is human nature to learn best from mistakes, but we don’t want to be at the mercy of human nature. We don’t want people to have to screw up in order to learn. We don’t want failures and screw ups if we can possibly avoid it, because mistakes and screwups can cost money, they can cost lives (in certain cases), and they can cost careers if they are big enough.

Learning in a KM Framework

The ideal situation, in any mature KM or lesson-learning framework, is that you learn as a matter of course from every event, whether you deliver failure, success or a mixture of both (and it usually is a mixture).

Learning, as in lesson identification meetings such as After Action reviews and Retrospects, should be a routine exercise, regardless of success or failure. Address both, learn from both, and give particular attention to understanding the causes of success.

Fail fast and fail often is a good mantra, so long as it leads to success, and it is the success that is the greatest learning opportunity.

A simple picture to link KM and continuous improvement

Knowledge Management is the discipline that drives continuous improvement. Here is a diagram that makes this clear

We are all familiar with the link between Knowledge and continuous improvement in our personal lives, as demonstrated by the familiar saying "Practice Makes Perfect". The more we do something, the better we become. The more experience we have, the higher our performance.

This can also be true for Organisations, provided we apply KM. Organisations can also find that Practice Makes Perfect, and that the more experience they have the higher their performance.

The diagram here shows how - feel free to use with acknowledgement.

The two crucial elements are as follows.

1) There needs to be a learning loop in operation. Knowledge must be applied to activity and to problems, and must be reviewed and gained from activity, problems and experience. The challenges for an organisation are two-fold - firstly finding a way to gain knowledge from experience (through effective lessons capture for example), and secondly being able to find the knowledge from the past (practices like Peer Assist help here). This is one elements of Knowledge Management already. 

2) The second element is to embed new knowledge into processes, procedures and structures. This is represented by the blue wedge in the diagram marked KM. Without this embedding step, the new knowledge is lost over time as human memory fades, or as lessons become buried within lessons databases, and performance slips back down the hill. The embedding KM wedge makes sure that performance gains are maintained (through the use of Lessons Management Software for example).

This combination of the KM components of learning loop and embedding means that

• the more experience an organisation has, the more it learns
• the more it learns, the more it improves its knowledge base
• the more it improves its knowledge base, the more it improves its processes, procedures and structures
•  the more it improves its processes, procedures and structures, the more it improves performance.

"Speed of learning" as a competitive advantage

In today's rapidly changing world, the speed at which your organisation learns can be a competitive advantage.

Spitfies and Bf109 Dogfight, by Adam Purves on Flickr

The world is changing, and the rate of change is speeding up.

In the past, when progress was slower and the rate of change was lower, an organisation could compete on its products, its patents, its reputation and on its people.

However the rate of change is increasing, and companies need to adapt. Markets are changing, customers are changing, expectations are changing, regulations are changing, the world is changing, and it is changing faster and faster. If companies are to adapt, they need to unlearn old habits and learn new ones. And in a competitive world, the fastest learner wins.

The analogy is with the aerial dogfights in the first world war.  There, the maneuverability of the aircraft was key. If you could maneuver faster than the opposition, you could get inside their turning circle, and shoot them down.

Today, the learning agility - the intellectual maneuverability - of a competitive organisation is key.

If you can get inside the opposition's learning circle, you can shoot them down.

So how fast is your learning circle? How quickly does the organisation learn from experience?

• How long does it take for a new lesson from experience to become embedded into the way you work?

• How long does it take a question in a Community of Practice to be a) asked and b) answered?

• How long does it take a piece of new knowledge to show up in the company knowledge base, and how long does it take for this to be re-used and applied?

Do you even know? Do you have the metrics to measure your speed of learning, as an organisation?

Contact Knoco if you need help with tuning up your learning circle!

The four most costly words in KM - "this time it's different"

"This time it's different" can be the four most costly words in project knowledge management, if they are used as a reason not to learn from the past.

Albert Einstein's definition of insanity was "doing the same thing over and over again and expecting different results".

And yet, any analysis of a collection of corporate lessons will show the same mistakes being made time after time. So organisations obviously DO "do the same thing over and over again and expect different results".

Are organisations insane?  Or is there another factor at work?

The factor may well be what the Farnam Street blog calls the "This time it's different" fallacy. I quote from the blog -

“This time is different” could be the 4 most costly words ever spoken. 

It’s not the words that are costly so much as the conclusions they encourage us to draw. We incorrectly think that differences are more valuable than similarities. After all, anyone can see what’s the same but it takes true insight to see what’s different, right? We’re all so busy trying to find differences that we forget to pay attention to what is the same.

Different is exciting and new, same is old hat. People focus on the differences and neglect the similarities. In projects, this becomes the "my project is different" fallacy that I described here. People look at their projects, see the unique situations, find the differences, overlook the similarities to all similar projects on the past, and assume that "this time it will be different".

It never is.

The same old mistakes will creep up on you and bite you in the bottom, as they always do.

Instead of assuming "this project is different", perhaps we should start with the assumption that "this project is just like any project. It involves building and understanding client requirements, choosing and forming the team, selecting and managing sub contractors, balancing the innovation against the risk, communicating within the team and with the client, keeping the client requirements always in mind, managing quality, managing cost, managing time, managing expectations, managing risk, and so on".

Then look for the lessons that will help you with all those tasks, and will help you avoid all the old pitfalls. As the Farnam Street blog says,

If you catch yourself reasoning based on “this time is different” remember that you are probably speculating. While you may be right, odds are, this time is not different. You just haven’t looked for the similarities.

A great antidote to the "This time it's different" fallacy is that good old, tried and tested mainstay of Knowledge Management, the Peer Assist. Once a project team gets into a room with a bunch of people with experience, the conversation automatically focuses on the similarities. "Yes, we've seen that, we've been there, here's what we learned" and it becomes increasingly difficult to maintain that "This time it will be different".

Operationalising Lessons Learned in a small organisation

Here's a really great video on a small organisation operationalising a lessons learned process

The organisation is Boulder Associates, an Architect and Design firm with a couple of hundred staff working out of a handful of US locations. The video was recorded at the KA-connect conference in San Francisco in 2018; an annual knowledge-focused conference for the AEC community organised by Knowledge Architecture.

The video is of a 27 minute presentation given by Todd Henderson and James Lenhart of Boulder Associates, and thanks Todd for the namechecks!

They make the point that collecting lesson is not the purpose of lesson learning, and they drive lesson learning through just in time delivery, using checklists as the final destination for the learning. Their combination of spreadsheet, tracking dashboard and checklists is a very simple, very appropriate system for an organisation of this scale.

Why admitting mistakes is so hard, and what we can do to counter this

It is part of the human condition to deny our mistakes, but that makes it hard for us, and for our organisations, to learn.

make no mistake, a photo by Meshl on Flickr.

I can recommend a really interesting book called "Mistakes were made - but not by me - (why we justify foolish beliefs, bad decisions and hurtful acts)".

The book is about cognitive dissonance - how people square their self-image of being a good, competent and smart person, with the realisation that they can make mistakes - sometimes pretty big mistakes.

The way most people deal with this problem is to maintain the self-image and explain away the mistake.

"It wasn't really a mistake" - "Of course I didn't see the stop sign, it was in such a stupid place" - "The sun was in my eyes" - "Nobody told me it was wrong" - "He pushed me" - "I don't see why I should say sorry, he started it" - "I'm not wrong, aliens really DO exist; the government is covering it all up" and so on.

They didn't REALLY make a mistake; they were smart people all along. It wasn't their fault.

This cognitive dissonance works particularly strongly in cultures that are intolerant of mistakes, and to be honest, that's most cultures. As the playwright Lillian Hellman says about US culture, for example

"We are a people who do not want to keep much of the past in our heads. It is considered unhealthy in America to remember mistakes, neurotic to think about them, psychotic to dwell on them".

Knowledge Management, however, requires that organisations, and the people within them, learn from experience, and 50% of experience comes from Mistakes. KM, if it is balanced, must allow learning equally from failures and from successes. Somehow this very powerful driving force of cognitive dissonance, present in every culture and every human, must be allowed for, sidestepped and redressed.

How do we do this?

Firstly, there much be a very conscious top-down drive for a culture that allows learning from mistakes. Call it a no-blame culture, call it an organisational learning culture, call it openness - it needs to be a clear and conscious expectation. This sets up a counter-dissonance. "I am a smart person. But I made a mistake. But the company expects me, if I am smart, to admit mistakes. Hmmmm!"

We all know the story told about Tom Watson Sr, the first president of IBM.

A young worker had made a mistake that lost IBM $1 million in business. She was called in to the President’s office and as she walked in said, “Well, I guess you have called me here to fire me.” “Fire you?” Mr. Watson replied, “I just spent $1 million on your education!”

That is a very powerful story that sets up a counter-dissonance.

Or look at the NASA approach, of getting senior leaders to publish stories entitled "my best mistake".  I suggested this to an organisation recently, and the head of KM actually said "you will NEVER get leaders to publish their mistakes". And yet that's just what they did at NASA.

Or look at the Japanese attitude of Hansei. Although alien to many in the west, Hansei is an important part of the Japanese culture. Han means “change” and Sei means “to review”, so the whole thing means “introspection” or “reflection for the purposes of change”.  This translates into a behaviour , instilled from childhood, of looking for mistakes, admitting responsibility, and implementing change.(When Japanese children do something wrong, for example, they are told: "Hansei shinasai - Do hansei"!). Hansie also contains the thought that "to say there were no mistakes, it itself a mistake"

Secondly, we use objective facilitation.

Take lessons-identification meetings, for example. The temptation, when scheduling a meeting for a project team to identify lessons from experience, is for the project leader to lead the meeting. However the outcome, most of the time, is that the project team made No Mistakes. Sure, mistakes were made, but not by the project team!

You see this, for example, when the lessons coming from the team are like this ....

We ordered a set of number 6 widgets, and when they arrived, they were very poor quality. We had to send them all back, which delayed construction by a week.  The lesson is not to use that supplier again".

So the fault was with the supplier.

However a good objective facilitator would dig deeper. They would ask - what were your quality control procedures? What was your ordering philosophy? Did you wait for the widgets to arrive before doing quality control? If so, why did you leave it until the last minute, so that re-ordering caused delay? Did you just assume that everything would be top quality?" The lesson would be more about quality control procedures and mental assumptions, that it would be about suppliers and vendors.

Any good system of lessons identification and lesson-learning has to use objective external facilitation, if you are to overcome the tendency to say "mistakes were made, but not by my team." That's why an increasing number of companies are calling us in, for example, to provide that skilled external evaluation as part of their lesson learning system.

This is even more the case with high level review and learning. As the authors of the book say,

"Few organisations welcome outside supervision and correction. If those in power prefer to maintain their blind spots at all costs, then impartial review must improve their vision ....... If we as human beings are inevitably afflicted with tunnel vision, at least our errors are more likely to be reduced or corrected if the tunnel is made of glass".

This goes for teams and individuals as well as organisations - impartial assistance is vital.

So, set the high level expectation for openness, and use external facilitation to probe the blind spots.

We all make mistakes - mistakes have been made, often by us, and those mistakes are an opportunity to learn and improve, despite our best efforts to pretend that they never happened.

The 4 steps of learning within a project

As a project learns, it goes through 4 stages (see Donald Rumsfeld)

I blogged yesterday about the need for knowledge transfer between a project and an organisation.

This post goes a little further, and talks about the development of knowledge within a project.

The diagram here shows how KM can take a project through a progression of learning in a project, and is particularly applicable to product development projects or R&D projects.

1. In step 1, the project becomes clear about what it already knows (about the challenges, about the technology, about the market). These are the Known Knowns.

2. In step 2, the project should identify its knowledge gaps, through a process such as Knowledge Gap Analysis or KM planning. Through this process, the team becomes clear what they don't know, but can learn from others.   As far as the project team is concerned, these are the Unknown Knowns; things that others know, that the project team doesn't. Here the team needs to learn from the wider organisation as described in yesterday's post, or learn from other organisations. By mapping out the known knowns, the project team can then limit their scope to the truly unknown (because if they start researching known territory. they are wasting effort and reinventing the wheel). (See for example Wilbur Wright's attempt to map out the known knowns when researching Powered Flight). This step also helps overcome the overconfidence bias.

3. In step 3, the project steps into the unknown. They define what they need to learn about but cannot just learn from others (the Known Unknowns), and put in place processes to gain that knowledge - R&D, Market Research, Rapid Prototyping, Business Driven Action Learning.  Through these processes, they fill in the Known Unknowns  as they become known.

4. In step 4 the project butts up against the Unknown Unknowns - the nasty surprises. They can only address these by a secure process of "Learning while Doing" - through After Action Reviews or some other process of project learning. They won't discover all the Unknown Unknowns, but can make some headway into this territory.

5. Then of course comes step 5, where all of this knowledge is fed back to the organisation, as described yesterday.

And then, of course, at the end of the project, they can share what they have learned with the rest of the organisation.  All of these steps should be covered by the project Knowledge Management Plan. 

Through this series of steps, the project can build on the known and learn about the unknown in a planned and efficient way.

The importance of "learning urgency"

How urgent is learning in your organisation?

Image from wikimedia commons

When I give my Knowledge Management Training courses, I start proceedings by presenting three stories from organisations who are doing knowledge management, showcasing some of the benefits KM can bring.

I then ask the class to discuss the stories, and to identify the success factors that lie behind each one. Often these are a mix of successful interventions, and successful cultural elements.

One of the success factors a recent class identified was a "sense of urgency". In each case, the protagonists in the story treated learning as Urgent - one of the first things to be done before leaping into action - and as a result, delivered great results.

This was a really good insight.

All too often, learning (and Knowledge Management in general) is seen as important, but not treated as urgent. In these stories, the urgency was there, and learning followed.

So how had the organisations in the stories created that sense of urgency?

• In the first story, the organisation gave a high-profile task to an individual who had never done that sort of thing before, with clear instructions not to "screw up". A risky move, were it not for the Knowledge Management system which gave the individual all the knowledge they needed to succeed.
• In the second story, the organisation challenged a team to improve on the past benchmark performance by nearly 20%. An impossible challenge, were it not for the access the team was given to all the lessons and knowledge from past performance.
• In the third story, the organisation gave the same audacious goal to twelve different teams simultaneously. A crazy thing to do, were it not for the way they set up knowledge-sharing between the teams, so they reached the goal far faster collectively, then they did individually. 

There is a saying, by the Greek philosopher Epictetus, that "you cannot teach someone something they think they already know". This means that if you give people problems they know how to solve, they will not look for additional knowledge, and they will not think outside the box. 

Learning, for them, will not be urgent. They will use the knowledge they have, do what they have always done, and deliver the performance they have always delivered. Safe, but no improvement.

An organisation can really drive Knowledge Management by giving people challenges they don't know how to meet, or putting them in positions where they don't know what to do. This is not as risky as it sounds, once KM is in place. 

Once KM is in place and is trusted, KM and management work together in delivering breakthough performance. Management gives people challenges they don't know how to meet, KM provides the knowledge they need to meet them. 

Learning becomes both Urgent, and Easy. Everybody wins.

The Risk Radar - what could possibly go wrong?

An analysis of your past lessons can be used to create a Risk Radar for future projects.

Michael Mauboussin, in his book "Think Twice", talks about the planning fallacy, and compares the inside and outside view.

He points out that people planning a task or a project tend to take the inside view - they think through how they will do the project, they think about the risks and challenges they will face, and how they will overcome them, they add up the times for each step, and use that as their baseline. Almost always they are over-optimistic, unless they also use the outside view, and calibrate their baseline against what usually happens.


Mauboussin says

If you want to know how something is going to turn out for you, look how it turned out for others in the same situation"

To find out what happened to people in similar situations, we can use Lessons Analysis. If you have an effective lesson learning system you may have records from hundreds or thousands of past projects, and you have a huge database of "how things turned out". Through lessons analysis you can recognise common themes across a number of lessons, and see the challenges and risks that projects are likely to meet, and identify those which are most common and most impactful. You can then use these to create a risk radar for future projects.

In the 90s, I was in charge of a lesson-learning system in Norway. At one point we had lessons from over 300 projects in the system, and we grouped them into a series of "things that commonly go wrong in our projects".

In Norway, we treated our list as our "Risk radar" - the more of these problem areas that a project faced, the greater the risk to effective project delivery. The top 7 problem areas were as follows (remember these were small office-based projects)

1. The project team is new, or contains a significant number of new members
2. There is no clear full-time customer for the project 
3. Satisfactory completion of the project relies on an external supplier. 
4. The project is a low priority 'back-burner' project. 
5. The project scope is poorly defined. 
6. The project relies on an unusual degree of IT support. 
7. The project involves consultation with large numbers of staff.

Any project where more than one of these was true had "Danger on it's Radar".

Such a project therefore needed to pay considerably more attention than usual to project management, and was advised to scan back through the relevant lessons and guidance, and speak to the people involved, in order to find out how the danger can be averted.

A few years later, the organisation applied the same concept to big engineering projects, and came up with what they called the "Train Wreck Indicator" - a similar indicator based on common reasons for failure, determined through lessons analysis. Any project that scored a Red Light on the train wreck indicator was given additional help and oversight in order to help it steer a path through the problem areas, and avoid becoming a train wreck.

Tools such as this help projects gain the Outside View to aid them in their planning.

If you have an effective lessons learned system, and are building up a library of project lessons, then consider a similar analysis, to build your own "Risk Radar".

 Contact us if you want to know more about our lessons analysis service.

A lesson is not just something you learned, but something you can teach

People who have learned from experience must understand their responsibility to teach others.

Photo by US Army Africa, on Flickr

I often say at the start of Lessons learned meetings, that when identifying and recording lessons we should think of them not as something we have learned, but as something we can teach others.

This is a subtle shift in emphasis form looking inwards, to looking outwards, and from looking backward, to looking forwards. It also identifies the responsibility of the knowledgeable person; a responsibility to others rather than to themselves.

For much of the lessons workshop, the participants are looking back at what happened. "We had a difficult time with the client", they might decide, and then follow this Observation with a whole set of reminiscences about how difficult the client was, and what trouble it caused.

With good facilitation, they can also reach Insights about why the problems happened.

However the facilitator then has to turn the conversation outwards, and ask - "based on what you have learned from your reflection on the client difficulties, what can we teach the organisation about how to better deal with clients". The participants need to stop analysing history, and start looking at generic learning they can pass on to others.

That is a critical value-added step, and it is that step, and the subtle mindset shift from passive learners to active teachers, that allows the participants to turn an observation and the subsequence insights, into a Lesson.