Marilyn Darling and Sam Moody (2016)
Sometimes the biggest challenge we face in getting our organizations to invest in learning is finding a source of motivation that’s great enough to overcome the inertia of the status quo. And sometimes that source ends up being something that is seen as “a failure,” and our motivating urge is to “make sure we never do that again.” Over the last few months, we’ve had several conversations with members of the Emergent Learning community who are trying to figure out how to approach learning in these potent and challenging conditions that follow project closures or failures. The urge to “make sure we never do that again” can motivate learning, but can lead to learning the wrong lesson or over-learning. In a fast-changing environment, the capacity to learn lessons is more valuable than any individual lesson learned, and avoiding yesterday’s mistakes won’t always prepare us to tackle tomorrow’s challenges. So how should we think about engaging in learning at the end of a project or program, especially one that is deemed to be a “failure”?
When we talk about what it really means to be doing Emergent Learning well, the specific tools we use are less important than when and how we use them. The purpose of Emergent Learning is to learn in real time, during a project, so that we can apply what we learn to this work the next time we have a decision to make — so that when we do get around to doing that post-project reflection, the news is good! In contrast, the learning tools organizations most commonly turn to at the end of things are post-mortems and project retrospectives. The fact that these are a team’s “last step” tends to define the kind of learning they encourage more than anything else, but each has its own specific impacts on how teams learn — or don’t.
The Post-Mortem: In the classic post-mortem, disaster has already struck. The patient is pronounced dead, and everyone weighs in on the mistakes that contributed to their demise. As the children of disasters, post-mortems set up mental models that can hinder learning. Accountability tends to be a search for “whoever was responsible for causing the failure,” rather than a recognition that we all make well-intended decisions for a range of reasons and we are all responsible for learning about what contributed to a failure. What we tend to focus on learning about is “what not to do” in the future. We sacrifice opportunities to explore what it would take to achieve our future goals in order to focus on how to avoid our old mistakes.
From an Emergent Learning perspective, waiting until failure strikes to develop hypotheses denies us many useful opportunities to test those hypotheses in the thick of the work, when the potential for success is still on the table. There is a time and place for a post-mortem — if broad institutional changes are needed to mitigate human error and ensure that that kind of irreparable mistake is never made again, but the cost is risk-averse teams who are burdened by infrastructure (rules, checklists, and added procedures) and less able to experiment and learn.
The Project Retrospective: Regardless of a project’s success or failure, a retrospective aims to capture learning from the project once it is completed. This approach assumes that learning is like data collection, and that the best time to learn about a project is once the work is done and we know what the final score is.
Unfortunately, the most significant impact of waiting until the end of a project to start learning is that the humans doing the learning have to rely on memory instead of observation. Important moments blur together, and details are sacrificed for big, abstract lessons and feelings. What gets remembered may also be influenced by who has the most power or authority. A team might agree that a project was incredibly successful, or enjoy griping together about the ways in which that one frustrating partner was, in fact, frustrating, but specific lessons that can inform and be tested by tomorrow’s work are harder to come by. Relying on a project retrospective to “take care of the learning” at the end of the project can be especially challenging in longer projects, as the amount of information to process and learn from can become overwhelming. Longer projects often see team members change roles or leave the organization, taking key insights with them. Finally, as with a post-mortem, waiting until the end prevents us from using what we learn to improve the outcomes of this project.
The After Action Review: An iterative cycle of Before Action Reviews (BARs) and After Action Reviews (AARs) addresses the shortcomings of last-step learning by providing a simple way to embed real-time learning in the midst of the work at hand. There are always small failures inside big successes, and small successes inside big failures. These are often the source of the most important (and actionable) lessons teams can learn — if they can learn them while there is still time to experiment, and before those small lessons are blurred into the final outcome.
We use AARs to review our initial hypotheses about an important component of a project, check how they hold up against real-time observations (not memories), make modifications, and most importantly, identify the next step or important opportunity we’ll be able to test new or refined hypotheses against. By focusing on the goals that today’s work carries us towards, teams can maintain a clear line of sight through the thickest tangles of uncertainties, without stifling risk-taking or experimentation. By embedding learning in the midst of a project, AARs give us the opportunity to explore new opportunities, make course corrections, and learn from each of our decisions.
– – –
But what if, like many of our colleagues, the work you have in front of you today is to collect learning from a completed — or failed — project? Luckily, learning is like planting trees: the best time to start was definitely ten years ago, but the second-best time to start is right now.
Starting at the End: Let’s say you’re at the end of a failed project, and there is appetite — or even just awareness of a need — for learning. How can you help your team avoid risk-averse perfectionism in response to failure, “learning” fuzzy or wrong lessons from too much old information, or wasting energy pointing fingers and avoiding blame?
- First and always, focus forward. Remind everyone that we are doing this to think together about how to be more successful next time, not to assign blame. It is even better to know what “next time” is, so you can focus your reflections forward to what the next project is likely to involve.
- Create a timeline of a long or completed project and identify the defining moments you want to reflect on — and focus on those that are most relevant to your next project. Thinking about a whole project all at once tends to lead to big, abstract lessons, pet peeves, or finger-pointing, so break it into smaller pieces.
- Conduct a series of short AARs around each of those defining moments. This will help your team get very specific and generate practical, realistic lessons, with a clear sense of when those lessons will next be applicable.
- During each AAR, “turn back the clock” and dig into why someone made the decision they did that may have contributed to a negative result. There was probably a good reason for it, even if the reason was lack of time. Follow up by asking “if we could turn the clock back, what could we have done to achieve a different result, and what lesson should we take forward?”
- Rehearse the meeting in advance with people in positional power, and discuss how to talk about what happened. Inviting those in power to take the lead in sharing what they did that contributed to a negative result can have a tremendous impact on the tone of the meeting, and the kind of reflection the team engages in.
- As always, set the stage with forward-focused goals, ground rules, and expectations.
The objective of this approach is to recreate (to the best of our ability) the learning experience that several AARs throughout the project would have provided. This helps the team hone a broad lesson like “leadership is important” or “community engagement should happen earlier” into more practical lessons that connect to specific parts of their next project. Such lessons can be communicated to others in a script like this:
“The question we came together to talk about was [Framing Question]. We reflected on our experience so far. What we noticed that worked was [story of success]. What we learned from that is [insight] and what we plan to do going forward to take that lesson with us is [hypothesis]. What we noticed that didn’t work so well was [story of failure/disappointment]. What we learned from that is [insight] and what we plan to do going forward to take that lesson with us is [hypothesis]. We plan to apply those lessons in [upcoming opportunity/opportunities].”
At the end of something — especially something disappointing — curiosity and humility help us look to the future, and they help us learn far more from failures than “what not to do”.
— Sam Moody is a nonprofit consultant, photographer, and Emergent Learning practitioner based in Denver, Colorado.