Lessons Learned Part 2: What is a Lesson?

This article is part 2 of a series of articles exploring the Lessons Learned Life Cycle.

Before we can discuss lessons learned, it helps to know what we’re talking about. So what is a lesson, particularly an organizational lesson? The question is a simple one but amazingly difficult to answer. I looked both at what academic research says and also how the people who try to put lessons learned systems into practice define them. The end result was that I still can’t come up with a succinct, pithy definition of an organizational lesson learned (maybe one of you can!), but at least we might be able to put some boundaries around the concept.

Here are four characteristics I believe are necessary for something to be a lesson learned:

• A persistent independent existence. Since organizations are made of people, the only way they can learn is through their members. So it’s possible for them to learn independently of any specific member but not independently of all members. A simple test I have used to identify a learning organization is to ask the question “Does the knowledge stay when people leave?” If it does, then the organization has truly learned something, otherwise the lesson has only been learned by individuals. Think about the times when your company has sent someone off to a conference to learn something new. The employee comes back full of new knowledge and ideas. The company might now seem smarter if this new knowledge is having a positive impact on that employee’s work. But unless the knowledge has been shared with others, the organization goes back to being its old dumb self as soon as that employee leaves. So the lesson has to exist in some way that keeps it from walking out the door. Most people immediately jump to the need for databases and repositories to create this independent existence, but a theme I will probably return to repeatedly is that there alternative ways to solve this problem. Organizational memories and lessons aren’t just stored in files but can be embedded in cultures, in relationships between employees, and in work processes. In fact, the best way for an organization to learn a lesson is to embed it so deeply that individual employees don’t even have to consciously learn it – they just do their jobs.

• Transferability. This is closely related to the first characteristic above but not exactly the same. For example, a common problem of many lessons learned systems is that they are repositories which are difficult to access, which hardly anyone knows about, or which contain lessons lacking the context that would make them useful. Impediments to transferability might be the form the lesson takes, the mechanisms for storing or disseminating it, or the lack of systems for identifying and capturing new lessons.

• Applicability. Knowledge management folks often talk about “know-how” (operational learning) vs. “know-why” (conceptual learning). Know-why can be very useful for uncovering new lessons, but strictly speaking it’s not nearly as important as a component of the lesson itself than is know-how. But a critical aspect that is often overlooked is “know-when,” the situational awareness that allows someone to understand not only what the lesson is but when (and when not) to apply it. In fact, there is some argument that this may be the most critical issue when learning from experience.

• Behavior change. This is the crux of the difference between a lesson and a lesson learned. Organizational learning can be viewed as either cognitive or behavioral. So it’s possible for an organization to acquire knowledge without ever using it (cognitive learning) or conversely, to change behavior in a purely reactionary way without any cognition being associated with it (behavioral learning). When knowledge is captured and stored for future use, it’s not really a lesson unless it has the potential for behavior change within the organization. And since we cannot give organizational exams, the only way to really know if it is a lesson learned is if it has actually induced some behavior change.

While academics often focus on the attributes of organizational learning, practitioners tend to think more in terms of process when defining lessons learned. Here are three examples.

From the U.S. Department of Energy’s Project Hanford:

A ‘good work practice’ or innovative approach that is captured and shared to promote repeat applications, or an adverse work practice or experience that is captured and shared to avoid recurrence.

From the International Fund for Agricultural Development (IFAD):

Knowledge generated by reflecting on experience that has the potential to improve future actions. A lesson learned summarises knowledge at a point in time, while learning is an ongoing process.

Perhaps the most comprehensive definition is one promoted by the U.S. Department of Energy’s Society for Effective Lessons Learned Sharing (SELLS) and used by the American, European, and Japanese space agencies:

A lesson learned is a knowledge or understanding gained by experience. The experience may be positive, as in a successful test or mission, or negative, as in a mishap or failure. Successes are also considered sources of lessons learned. A lesson must be significant in that it has real or assumed impact on operations, valid in that is factually and technically correct, and applicable in that it identifies a specific design, process, or decision that reduces or eliminates the potential for failures and mishaps, or reinforces a positive result.

That last one is probably the closest we’re going to get to a succinct definition of Lessons Learned, and even having said so I still have a quibble with it, which is that a lesson is “gained by experience.” Lessons can also be learned in other ways, such as observation or experimentation, which I’ll discuss in future posts.

Next part (part 3): Initiation and Recognition.

Article source: Lessons Learned Part 2: What is a Lesson?

Header image source: Mohamed Hassan on pxhere, Public Domain.

References and further reading:

• Chris Argyris: Overcoming Organizational Defenses

• Rob Cross and Lloyd Baird: “Technology is Not Enough: Improving Performance by Building Organizational Memory”

• Anthony DiBella and Edward Nevis: How Organizations Learn: An Integrated Strategy for Building Learning Capability

• Mark Easterby-Smith, Mary Crossan, and Davide Nicolini: “Organizational Learning: Debates Past, Present, and Future”

• C. Marlene Fiol and Marjorie Lyles: “Organizational Learning”

• Daniel Kim: “The Link between Individual and Organizational Learning”

• Bertrand Moingeon and Amy Edmondson: Organizational Learning and Competitive Advantage (Theory, Culture and Society)

• Michael Morris and Paul Moore: “The Lessons We (Don’t) Learn: Counterfactual Thinking and Organizational Accountability after a Close Call”

• Joseph Raelin: “A Model of Work-Based Learning”

• Rosina Weber, David Aha, Irma Becerra-Fernandez: “Intelligent Lessons Learned Systems”