A month ago, as I was waiting to start my first day with AIIM, I can across several tweets that I felt over-stated the benefits of failure. I decided to write a quick little post on how Failure is Not a Positive on my tablet over my morning coffee.

There were some great comments, but I had little time to respond. I am taking some time now to respond because this is an important topic. First, let me start with my baseline statement:

Failure is bad.

I still stand by that 100%. It should be noted that once you are no longer in grade school, you realize that good and bad are on a sliding scale and are rarely absolutes. Something can be bad and not be the “worst”. Bad in this context refers to the simple fact that if you draw a line in the middle, failure is something to be avoided.

Mistakes versus Failure

One thing that I think is going on is that people are not distinguishing between failure and mistakes. Mistakes happen and are usually recoverable. You can make mistakes and still succeed.

Think of it like war. Each war is composed of battles. You can lose a battle but still win the war. Sometimes you have to risk battle because to not fight may lead to losing the war.

Same thing here. During a project or initiative, you have to move forward. You can change direction, or “pivot”, but you are always moving forward. If you make a mistake, you learn, adjust, and keep going.

This is where Max Pucher and I differ on our viewpoints…

Targeting and demanding a ‘failure free’ of anything is doing two things: First it usually involves going to extreme length to try and ensure that something will not fail. it is very expensive often more expensive than fixing a problem. Second, once things are error free they are considered to be perfect.

He is correct, mostly. Perfect is the enemy of the good. (Voltaire) If you strive to be perfect and mistake free, you will fail. The opposite of perfect isn’t failure. I have run almost no projects that were “perfect”. The one or two that may have been mistake free were as much due to low complexity and a little bit of luck.

According to Max, even Steve Jobs knew the difference between the two and talked about making mistakes, not failing.

When you innovate, you make mistakes. Admit them quickly, and get on with improving your other innovations. (Steve Jobs)

Making a mistake isn’t failure. People need to stop confusing the two. The English language is hard enough as it is.

A Learned-From Experiment is Success

Keith Swenson then chimed in with a great observation:

Learning requires experimentation, and experimentation necessarily requires trying approaches that do not succeed … they fail. You can not have innovation, and you can’t even have learning without along the way failing.

I agree 80%, give or take. If you conduct an experiment, the purpose is to learn if something works. If it succeeds, GREAT! If not, you still achieved your goal of learning. The definition of the word Experiment carries this out:

an operation or procedure carried out under controlled conditions in order to discover an unknown effect or law, to test or establish a hypothesis, or to illustrate a known law

If you perform something as a test or experiment in the process of innovating, then as long as you learn from the outcome, you have not failed. If you don’t learn anything, then you have a failure which is not good by any stretch of the imagination.

This is true even if the experiment “works”. If you don’t know why it works, you haven’t learned anything and then are unlikely to repeat the “success”. THAT is a failure and it is always bad.

One more thing, it is always important to know going in if something is an experiment or not as that drives both the execution and evaluation of the effort. Calling something an experiment AFTER it has already failed is a failure unto itself.

True Failure Has Consequences

The other comments are worth reading and some include links to supporting posts. There were comments on both sides, but I don’t see the need to argue with those that agreed.

When you look at real failure, not mistakes and not experiments that didn’t “work”, but projects/initiatives that never completed or that didn’t achieve their goals, you see a large cost.

• Technology: People blame the technology. The products and technology involved are branded in people minds as not being any good. This is rarely the case but has long ranging effects. I knew one Director of IT that would never consider one major vendor because of one failure in a past life. Thing was, that vendor actually had the ideal solution. That failure cost two organizations.
• People: When you role out a new system, you are putting reputations on the line for the leaders and departments involved. Failure leads to people to distrust the next effort from the same leader and/or group.
• Money: Consultants, licenses, hardware, and employee time all cost money.
• Time: What could have been achieved in that same timeframe? If you fail after nine months, you have to start over but now your competition has moved forward in that same timeframe.
• Process: When the new way fails, the old way becomes more entrenched. The belief that it is unique or difficult to replicate becomes more engrained.

You can’t be afraid of failure or you will never do anything. On the flip side, you need to work to avoid it. Put together a plan that has a chance to succeed. Track, manage, and mitigate risks. If it looks like success is no longer possible, go ahead and fail early because it has less costs.

The more open you are to accepting failure, the more self-fulfilling the prophecy becomes for you.