Should We Really Embrace Failure?

When you work in digital you hear all the time that we should embrace our failure. But is that true and how do we convince our boss of that?

“Fail fast” seems to be the mantra of digital professionals everywhere. But why would we want to fail at all? Isn’t failure something to avoid, rather than embrace? After all, hundreds of years of industry, we have avoided failure and with good reason.

Where Does Our Fear of Failure Come From?

If you consider most of the projects people undertake, failing is not something they would seek to embrace.

If you are constructing a building and it collapsed your failure would cost lives. The cost of failure can be high in reputation, money or even lives. Mistakes can sink companies and even bring down governments. One mistake can make all the difference.

When the consequences of failure are as big as the BP oil spill in the Gulf of Mexico. it is unsurprising that it is not acceptable.
When the consequences of failure are as big as the BP oil spill in the Gulf of Mexico. it is unsurprising that it is not acceptable.

It is not surprising that companies plan projects in excruciating detail. That before work ever begins they produce detailed specifications and gantt charts. Or that once work starts, deviation from those plans is not an option.

Agreeing on that plan can be a painful process too. Let’s imagine you are manufacturing a new car. Until the car goes to market you have little idea of whether it will be a success. Will people like the design? Will it get favourable reviews? That is not even considering the risk of a manufacturing error that could force you to recall vehicles. Sure, you can do some market research. But you don’t know whether people will buy the car until it goes to market. You are working with limited information.

No wonder planning such projects involves endless committee meetings. After all, no one individual is going to want the responsibility if things go wrong. Everybody has to agree to proceed.

If failure is so damaging in most scenarios, why would digital be any different?

Why Failure Has Its Place

Running a digital project is not like constructing a building or launching a new car model. In fact digital is not like any physical goods. It differs in three significant ways.

  • Pixels are cheap. You can build something and discard it at little cost compared to physical goods.
  • You can make corrections. You cannot make changes to a car after launch without recalling every car you have sold. But with digital services you can update it many times a day if you so wish.
  • Information is abundant. Digital services provide a wealth of date on how people are using them. This makes it easy to see what is working and what is not, allowing you to adapt.

These key characteristics of digital encourage a culture of experimentation. This is much like you see in scientific research. You form a hypothesis about what will work. You build an experiment to test that hypothesis and gather data on the result. Whether the hypothesis is correct or not is secondary. It is the data that matters. Data that moves you towards success.

Winston Churchill once said:

Success is going from failure to failure with no loss of enthusiasm.

Nowhere is this more true than in the digital field. Building something that fails in someway provides valuable information. This will inform your next version.

In someways we do this concept a disservice by referring to it as ‘failing fast’. What we are talking about is a culture of experimentation. That sounds much more palatable to colleagues and management unfamiliar with digital.

A culture of experimentation is an iterative process that moves you towards the final result.
A culture of experimentation is an iterative process that moves you towards the final result.

But ‘failing fast’ does have some merits. Scientific experimentation is a slow and meticulous process. But in the commercial world, speed is everything.

An iterative approach lets you get a minimum viable product (MVP) to market fast. This allows you to start grabbing market share. You can then iterate on that MVP overtime based on the feedback from real users.

The chances are that this isn’t a particular revelation to you. But it will be to your non-digital colleagues. This is the reason you struggle with committees, detailed specifications and unrealistic project plans. Your colleagues and managers have been trying to run digital projects like physical ones. It falls to you to show them that there is a better way to work.

How to Make Failure Acceptable

As I have already said, you may wish to stop talking about failure at all. It is just too big a mental shift for most. Or you could use the wording of the Government Digital Service in the UK and talk about ‘only make new mistakes‘. This sounds more palatable.

But semantics aside, what we are talking about here is a different way of working. One that moves away from specification, project plans and finite projects.

Instead we are seeking to create a culture of iteration. We build, test and iterate based on what we learn. It is an approach based on the ideas of prototyping and usability testing.

Don’t expect colleagues to embrace this overnight. Instead begin with a single pilot project. A place where you can test this approach. Pick something that is relatively high profile. Something people care about, but not something business critical. If it is too important people will get nervous about trying new things.

I often find an internal project works well. Something where your colleagues are the people you are testing with because they are the users. This engages them in the process and lets them see the benefits.

Intranet projects are great for this. As are backend systems like booking a holiday or claiming expenses.

Intranets are great pilot projects for iterative working because they are high profile but not business critical.
Intranets are great pilot projects for iterative working because they are high profile but not business critical.

Not that you shouldn’t choose an external facing project. The key will be to include stakeholders in the project as much as possible, to expose them to the different way of working.

You will also want to share the process with the rest of the organisation. Write blog posts, give presentations and share results. Invite people to the usability sessions and make your prototypes available for colleagues to see.

When running a pilot project to introduce this new way of working there is an important thing to remember. Your job is more about education than it is delivery. Yes, the pilot needs to be a success. But people need to see it as a success and understand why.

So failure has a place and we should be ‘failing fast’. But getting our colleagues and management to embrace this kind of thinking is going to take time. We will need to think long and hard about how we are going to communicate the benefits to them.

Paul Boag

About the Author Paul Boag

Paul Boag is the author of Digital Adaptation. He is a leader in digital and user experience strategy with over 20 years experience. Through consultancy, speaking, writing, training and mentoring he passionately promotes digital best practice.