By Jeff Shoemaker

Nobody wants to fail because we assume failure equals incompetence, regardless of the assumption’s validity (spoiler alert: it’s false). Plus, failure often comes with the wasting of resources: time, money, physical materials, reputation. Once it’s wasted, we can’t ever get it back. There’s a lot of valid reasons to avoid and fear failure. But is failing always bad?

Absolutely not. Failure is totally normal, and it should be expected. Failure comes with growth and innovation and courage, and it’s almost unavoidable if you want to do anything worthwhile. I’m not talking about big, huge failures that result from ignoring common sense and sound information. Those aren’t productive. The secret to success is not avoiding failure but failing fast and often. Positive failure experiences are more like smaller experiments as you work toward a solution. Really, the great irony is that failing intentionally early in the process can lead to great success at the end.

You may be thinking, “Hey, I’m a brain surgeon, and I can’t intentionally fail! You’re crazy.” You’re exactly right. Brain surgery and rocket launches and air flight and many other things are not good candidates for this approach to failure.

But many other fields of study can benefit from failing fast. You should experiment if…

• you are the first person to try this thing,
• if failure can be easily fixed and has a low cost,
• and if investing in extensive research would be more expensive than experimentation.

Also, obviously, all creative endeavors like art, music, and food can benefit from experimentation.  Oh, and software development. Custom software development can be a great candidate for failing fast because it’s generally unlikely to harm anyone or lose resources other than a little time and effort. So the benefit of failing fast far outweighs the risk for us. What is that benefit exactly?

Exploring the Neighborhood

In his book, Creativity, Inc., Ed Catmull describes Pixar’s process of failing fast. He calls it “exploring the neighborhood.”

“It isn’t enough to pick a path—you must go down it. By doing so, you see things you couldn’t possibly see when you started out…at least you will have ‘explored the neighborhood.’”

Exploring the neighborhood is an excellent analogy for experimentation. Imagine you are driving to visit a friend who lives in a neighboring city. And for the sake of the analogy, let’s assume your phone died and you forgot your charger. So all you know is the general location of your friend’s house and the street address. He said it was just off the highway on the south side of town, next to a baseball diamond. Now, you are driving through the south side of town looking for your destination. What do you do?

Certainly you don’t park and hope that a map to his house comes to your mind in a flash of inspiration. And you don’t park, look out the window, then try to guess your whole path to his house based on what you see. You start driving. From the main road, you begin turning into different neighborhoods. You are checking and evaluating as you go. When you make a turn and see a commercial district, you quickly turn around and go back to the main road. When you see a baseball diamond, you turn down that street and spend more time looking for the street name that matches your friend’s address. Your search continues, and soon you arrive at your destination.

Each turn down an incorrect street was a failure, but you failed fast. As soon as it became obvious that you’d made a wrong choice, you turned around. But what was the benefit of going through this process? Well, now you know the city. When you and your friend decide to do some shopping or go out to eat, you know which road to take. You also narrow down your options as you go, so you can feel confident that you’ve found the right place when you finally ring your friend’s doorbell.

Going through this process gives you more time seeing and experiencing than discussing and deciding. In custom software development, I often face challenges that I know have a solution, but the path to the solution is not always clear. I have to solve new problems daily, and the process of recursive experimenting (or failing fast) lets me quickly test options and learn from mistakes. I could sit down and try to map out each possibility and evaluate the likelihood of succeeding, or I could start experimenting and see actual results. Planning is important, but once you know you’re in the right part of town, just start driving.

How to Fail

Let’s break down failing fast into some specific steps.

1. Start with the unknowns. What do you need to know today? If you are going to fail fast, start by exploring those unknowns.
2. Don’t belabor the decision of which path to take first. If you consider two options and they both have pros and cons that are fairly equal, just pick one. But, if one is faster, then try it first.
3.  Just begin. Make your best choice and get started. Ed Catmull said, “I have found that people who pour their energy into thinking about an approach and insisting that it is too early to act are wrong just as often as people who dive in and work quickly.”
4. Once you recognize that you are not exactly in the right place, you need to quickly decide if you should look harder or if you should move on. Deciding to double-down and work harder on a possible solution can be expensive, so keep an open mind and learn how to tell a road block from a dead-end.

Now that you’ve experimented and found a viable solution, record what you’ve learned. Ask yourself what you learned and how this knowledge could be valuable down the road. Write it down, create some process documentation, and share it with your team to solidify your learning. Embracing failure as a tool for learning and problem solving will help build a creative company culture. As you practice failing fast, you’ll get better at problem solving and improve the quality of your product.