The Freedom to Fail

Recently I had a discussion with a colleague about his strong 'fear of failure'. We spoke about it and hopefully I put his fears into context, and I will try and build on that here.

Now the Fear of Failure is important, it helps keep us motivated, it keeps us diligent and for some people its is truly what drives them. However in our industry it also stifles growth, innovation and promotes over conservative behaviour.

I am quite lucky in my current role, I lead a team of engineers who have explicitly been given 'The Freedom to Fail' - it is actually in the team mission statement, how neat is that?

Now that doesn’t mean its ok to sit back relax and just let projects crash on to the rocks. There are some projects that we should not ever fail on, those where a solution is self-evident, where we have more than adequate resources and where risks are contained.

But what it does mean is, we can be more experimental in our approach, we can truly try and learn whilst tackling the challenge, and we can try things that normally would be considered risky. We get a chance to learn and grow.

In an organisation that in many ways is very conservative, and in a current climate that promotes that conservatism, we break the mold.

Now that doesn't mean we do things purely because we like the idea of them (well I lie, we occasionally do but as a learning exercise). But we question the traditional approaches, we ask ourselves if the "typical" solution is appropriate, if the corporate template is appropriate and seek out other approaches which may indeed prove to be a better fit.

Perhaps luckily our choices have proved successful more often than not. But things do go wrong, we on occasion do fail and wind up either having to restart, rework or abandon a piece of work.

It is not wrong to fail, however it is very very wrong to hide, deny or ignore failure. That failure may only be partial or minor, but it is still a failure and needs to be addressed.

So here is what is important...

Identify Failure

Have a way of identifying failure (and subsequently success). There are many useful techniques that can be applied here, including time boxing, acceptance testing and "done means done".

Time boxing can be vitally important. Estimated work often overruns its a fact of life, we are poor at estimating and often something simple takes a lot longer than expected. Using a time-box you can identify that you have failed, and you need help, need to change approach or need to give up.

Acceptance testing lets you prove that you haven't failed. In many cases I take a pessimistic view of success, if its not passing all the tests its a fail.

Done means done" - all too often you can ask if feature X finished and you'll get the reply "oh yes that's done but this part needs tweaking". Sorry pal, if that part needs tweaking its not done, now put that card back into "in progress" and finish it properly before declaring it done.

Understand the consequences of Failure

It is important to understand what the consequence of failure is at every point. There are varying magnitudes to this, both at a project planning "will we get this done on time" point of view and real life consequences of failure of the project after release.<

It is important to know what can be done (if anything) to mitigate the failure. Can a different approach be taken, can another team undertake the work, can we just ditch it?

Structure what you do to ensure any failure occurs as early as possible in the process. Failing quickly increases the chances that we can mitigate the failure or if that is not possible then stop work before more resources are wasted.<

Understand the Root Cause of the Failure

All too often the root cause of a failure is not fully understood. "We think its because the connection pool was used up and that caused ..." - wait up here, stop, "We think?"

In some cases the root cause is obvious and at other times it requires investigation (root cause analysis) however something that is often over looked is what I consider "people problems".

Dealing with people is hard, especially in an industry known for having anti-social tendencies. Quite often people without the correct skills, experience or support are given problems they are just not equipped to handle - and thats a management failure.

Disseminate the Failure

This is the bit a lot of people shy away from. I have a great deal of respect for someone who can stand up in a meeting and say, "yeah I screwed that up, I need help to find a way to resolve it".

In my experience the failure to discuss failure is worse than the original failure - it dooms others to repeat it. And covering up a failure is far far worse than than actually failing, perpetuating a lie that something works when it doesn't.

Honesty is indeed the best policy. Of course I don't mean that companies should publicly air their dirty laundry but rather within your team (and hopefully within your entire company) there should be open, honest and frank communication.


Final Whitterings

Does your team fear failure to the extent they don't think outside what they think is expected of them? Worse yet do they fear it to the extent they will actively hide or deny it? Are you holding your team back through your own fears?

Building a sense of trust within a team is vital, how you address the issue of failure I think is vital.

If you work in an environment where failure is expensive then try and create a space where it is acceptable. Code Dojo's, Hack Days and similar events give people a chance to flex their mental muscles, their creativity and lets them grow, it gives them that freedom to fail.

Can't afford to fail? Can't afford not to learn from failure.