Welcome Catalysts to the next stage in your Shift Expedition!
This week we are going to focus on a popular notion: that you should “fail fast.”
I don’t know about you, but I don’t like to fail. In fact, I don’t know anyone that does.
As Shift Thinkers, we want to help people jump to new mental models that deliver breakthrough results. I wholeheartedly support the move away from a perfectionist mindset towards one of test and learn. But we have to move people to mental models that can be readily embraced.
“Fail fast” comes from the agile software movement. It is a mantra designed for writing code in test environments, not production environments. We want the people who build jet engines to fail in the wind tunnel, not at 30,000 feet.
The truth is there are some type of failures that are simply not acceptable. But we don’t make that clear when we say to “fail fast.”
So how should we think about failure? And how can we empower people to “test and learn” without creating confusion or sending them mixed messages?
This short video gives an overview of the differences between falling and failing, and how to empower teams to test and learn effectively by finding their edge through effective falling - without failing!
For those interested, there is a whole discipline of “how to fall” for activities like skiing and martial arts. It turns out that knowing how to fall is as important as knowing how to stay up. In fact, in martial arts, students spend a lot of time practicing ukemi - the art of falling. Also note that the skill of how to get back up is equally important, in martial arts as well as in business and life!
The key takeaways on Falling vs. Failing are:
In the interest of “test and learn,” it’s become common to tell people to “embrace failure” or “fail fast”.
But people don’t like to fail, so it’s useful to shift your thinking from ”Fail Fast” to “Fall Well”.
When you fall, it’s a “fail” if you don’t learn anything or hurt yourself. Not falling is also a way of failing.
Give teams a clear shared purpose and decision principles to empower experimentation:
To find the Shared Purpose:
What is the “edge” you are trying to find?
What value will that create for all stakeholders?
To design the Decision Principles:
How can a team know if they are “falling” or “failing”?
What is the equivalent of (a) not falling enough, (b) not learning enough, (c) getting hurt?
How can the team “get back up” after they fall?
