Safe to Fail

I’ve just returned from speaking at an Agile conference in Winnipeg. Yes, Winnipeg in November. It actually wasn’t too cold, and the quality of conversations were amazing, so all-in-all, an amazingly worthwhile and valuable experience to learn and share.

I wanted to think about failure this week. Something I’m pretty familiar with!

In order for innovation to occur, we need to be in a safe environment. Only when it’s okay to get something wrong will we be willing to push the boundaries.

I often hear from folks who work in financial services, insurance, health care, and even telecommunications say that we can’t really take risks. So what’s the alternative? If we’re going to dream and make a real impact, we can start be making really small experiments. We need to be pushing the boundaries in a way that doesn’t put our customers at risk, and doesn’t put us at risk. So we need to find safe ways to fail. We need to encourage each other to look at tiny bits of work that we’re doing, and look for those improvements that might not revolutionize our work and industry. But if we keep at it, I believe we’re likely to find that the sum of our improvements can make an impact.

I participated in a Lego Serious Play session in Winnipeg. I was having some fun creating a model of what I would do with team members who let me down. The model shows that person being pushed off the top of a tall tower by another team member.

Have you ever worked in an environment when you made a mistake, and got punished? Maybe it was significant enough that it resulted in a lower performance review at the end of the year. Maybe it was by public shaming. Maybe it was just an idea that wasn’t aligned with your manager, and you were told that in a meeting.

Regardless, how likely are you to take another risk in that environment?
Yeah. Me neither.

When someone takes a risk through a controlled experiment, we should celebrate the learning that comes from that experiment. No matter the outcome of the experiment, because learning is an outcome that can be used to guide and inform the next experiment.

If we’re running huge experiments, with months of investment, and weeks to roll back if we find an issue, there’s a huge risk! Not only is the initial outlay expensive (we’re risking a lot of money, time, and effort to begin with), but we’re also risking the fact that no one might want to use whatever it is we’re creating for them. Oh, and by the way, we’re not learning anything along the way.

In project management, we talk about the “iron triangle”. That is, there are three elements that need to be managed during a project – they are Cost, Quality, and Scope. (There’s a joke here that on almost any project, you can pick two of them at the expense of the third). But that’s not the point I want to make. Imagine if I deliver on all three of those elements – I deliver exactly what was asked for (scope), I deliver it with on time and on budget (cost), and I build it perfectly, in a way that it’ll last forever (quality). Sounds like a successful project.

But wait a second… If no one uses it, if it creates no additional revenue, if it doesn’t help with customer satisfaction… Would you really call it a success?

If we have a hypothesis, we need to look at running the smallest experiment to validate it (or disprove it).

Once we’ve validated it, let’s invest more money and release the next experiment.

Lather, Rinse, Repeat.

But in order to enable this, we need to have a safe environment to encourage experimentation. And failure. That creates opportunities for learning.

And that seems like a safe way to lead to success.