I’m really excited to bring you a guest post from my friend Andrew Webster.  Andrew is the Director of Change and Innovation Simulations at ExperiencePoint, a really innovative learning company that condenses real-world experience into one-day simulations. They work with most of the world’s top executive education providers (including Knightsbridge), and a good chunk of the global Fortune 500 – from ExxonMobil, Citi, GE, Microsoft and Google, to The NHS, United Nations, and Habitat for Humanity. I invited Andrew to share what he’s learned about helping teams make better mistakes.

It is a strange thing to be asked to write a guest post about mistakes.  Should I be insulted?  Is having failure as your recognized expertise a good thing? Oh well, I’ve come to terms with the importance of mistakes.

Mistakes are simultaneously the best source of learning and the worst way to learn.  Best, because our most profound learning and most evident opportunities to learn spring out of our failures (see Liane’s post on higher quality mistakes here).   Worst, for at least four reasons:

  1. Learning from real-world experience just takes too damn long.
  2. Mistakes carry risk.
  3. We can extract the wrong lessons from our failures.
  4. High stakes failures can permanently damage trust and team dynamics.

Here at ExperiencePoint, having helped build change and innovation capability on six continents, we’ve come to the inescapable conclusion that you can’t build change management or innovation capability without giving people a chance to make mistakes together.  We build simulations that allow people to make those mistakes in a low-risk situation.

Change leadership and innovation are necessarily collaborative pursuits.  To give people the opportunity to practice as they perform, we put participants into teams to tackle simulated projects in a web-based environment.  With complex issues like change and innovation, simulations provide both content knowledge and practice fields for team dynamics.

A few tips for helping teams learn through mistakes:

  • Make the context realistic, but not real.  If your context is too fantastical or removed from the team’s real business issues, then the learning will be isolated to that fantastical context.   It has to be real enough that people will demonstrate some typical behaviors that they can reflect upon.  At the same time, if your learning environment is the same as everyday work, people will often defend their current approach instead of trying new ones.
  • Don’t be afraid to shine a light on mistakes.  We all want the delicious hot-dog, but don’t want to see how it gets made.  It’s a counter-productive desire, as messiness is where the value is.  Provided you have set the context as a learning opportunity with safety around mistakes, you don’t want to let anything slip.  Ask people what conditions and conversations led to flawed decisions.
  • Allow for pain, but contain it.  Mistakes are the richness that allows people to learn, but if you hang people out to utterly and consistently fail, you can compromise engagement, reputations, and self-esteem.  Keep an eye out for just enough mistake-making to reflect upon.  It’s invaluable for that domineering jerk to see how they warp a team, but they can corrupt that team beyond repair if appropriate boundaries aren’t set.
  • Model best behaviour… eventually.  Traditional learning theory suggests that we should teach people ideal models, and expect them to adapt.  With a good simulation, it can be helpful to allow people to explore counterproductive behaviors, like telling instead of questioning a team, before holding up a mirror, providing some scaffolding around new concepts, and helping them to try out those new concepts.

It took a great many mistakes for us to arrive at these lessons ourselves.  Hopefully, you can avoid making some and learn from ours!

Further Reading

Are you Making Higher Quality Mistakes?

Dealing with a Change that’s Hard to Swallow

How to Build your Resilience

Leave a Reply

Your email address will not be published. Required fields are marked *