Call It What You Want
Last week’s newsletter on more rapid decision-making resonated with many readers. Some comments about rapid decision-making included the phrase, “fail fast”. I found in follow-up replies that many are uncomfortable with this phrase. They were even more uncomfortable with “fail fast, fail often”. Apparently, no one wants to fail. Of course not. Let’s look more deeply at what this phrase is supposed to mean. You can then call it what you like.
Associated with agile, the fail fast concept is probably most familiar to those in software development:
“in systems design, a fail-fast system is one which immediately reports at its interface any condition that is likely to indicate a failure (1).”
The general approach is to test the software code as soon as possible. If it’s not doing what you think it needs to do, then make changes before moving on. Don’t build more wrong on top of wrong.
Likely, because many startups are software companies, fail fast started and has become an overused phrase associated with the startup culture. In this application, fail fast is intended to mean that:
“businesses should undertake bold experiments to determine the long-term viability of a product or strategy, rather than proceeding cautiously and investing years in a doomed approach (1).”
In this case, the company undertakes a bold experiment on (read tests) a product or strategy. If the product or strategy is not right, they make a change before moving on, avoiding building too many resources into the wrong product or strategy. You can probably see the parallel.
So, what if you are not in software development or in a startup? In an attempt to be more creative, innovative and fast, large established companies often talk about having a startup mentality and bring this jargon along without teaching individuals in the company what it really means and how to apply it.
Fail fast isn’t about the big decisions, it’s about the little decisions.
Note the relative scale in both examples above—the assessments are done on a small part of the whole. The company is not taking a bold experiment on the whole company—only one part of the company—a product or a strategy. The software is tested as soon as possible, not when it is complete.
How long do you spend working on a vision, a set of strategies or a project plan before you put it out to your group? Are you trying get it perfect first? Are you afraid to be wrong? Do you find that you become overly invested in your ideas because “I spent so much time on this”? This is an example of not failing fast. Do you find you wait until you’ve spent a week collecting data before you ask someone if you are doing it right? This is an example of not failing fast.
As soon as you think you have a few ideas, or you’ve given the new data collection process a good effort, get some feedback. Ask others if you are on the right track or if they see any opportunities to improve. So, you learn you are reporting data in the incorrect units. Good to know. Aren’t you glad you didn’t have to correct a week’s worth of data?
There’s no formula for when to get feedback. Ask for feedback on potentially small problems before being wrong would be a big problem.
Try calling it “Frequent Feedback”
Fail fast is about learning fast and modifying fast, not about quitting fast.
When a company learns a product is not quite right, they don’t close the company. They probably don’t even abandon the product. They likely modify the product based on what they learned. If a software developer finds a problem in today’s code, they don’t throw it away and start over. They usually find the error and edit. The editing is not random. The editing is based on what they learned from testing the software.
In the same way, when you put out various versions of your strategy, you will get feedback, and you will modify the strategy according to the feedback. You will not quit your job, just throw it all away and start over, or make random changes.
You are asking for the feedback in order to learn something. Be open to the feedback and be prepared to change. You do not have to agree with the feedback (you are the Decider, they are the Consulted). However, if you find that you are not willing to pivot your approach because it would require you to alter too much previous work, this is an example of not failing fast. If you feel like you’ve invested too much time in the process to change your mind, this is an example of not failing fast.
Trying calling it “Early Learning” or “Directed Modification”
You are not alone in finding this “Fail Fast” difficult. In the book, Just Start: Take Action, Embrace Uncertainty, Create the Future, authors Leonard A. Schlesinger and Charles F. Kiefer (2) suggest.
“In the face of an unknown future, entrepreneurs act, more specifically, they:
- Take a small, smart step
- Pause to see what they learned by doing so; and
- Build that learning in to what they do next.”
How about getting feedback today? Just share what you are working on with someone and ask for their feedback.
