Failure is always an option

Far too often I sit in meetings where we're trying to find the perfect solution or get it right the first time. It frustrates me a lot. Caveat, what I'm about to say may be fairly ranty. It's a philosophical point of view and it's okay if you disagree with what I have to say. I just want to put this out there.

We're conditioned to think that failure is a negative thing, that we should have the right answers, that the thing we create will be excellent. These expectations are not helpful. Failure is a mechanism to learn, it's okay to admit that you don't know something and you should learn as you work your way towards success.

Let's take a detour about why we are employed. My simple answer is that it is to add value. If you're employed in an educational setting you may, for instance, add value furthering the combined knowledge of mankind or perhaps creating something that your commercial partner can use. If you're employed by a not-for-profit organisation, you may add value by generating awareness, raising funds or increasing the social value of that organisation. If you're in a commercial organisation you could add value to your customers by making a product that fits their needs, or to the business by improving the productivity of your colleagues. I hope you see what I'm getting at, we are employed to add value and that value is very much dependant on the context.

What's all this got to do with failure? Well, the thing we never talked about is how quickly you deliver value. My hypothesis is that the value you deliver needs to be timely and incremental. The first part is simple, if you are shipping sprockets and your competitor ships before you then they are getting value sooner, they are solving a customer's need when you aren't. The second part about the value being delivered incrementally is a bit more interesting. Delivering incrementally ensures you are maximising value created.

Let's assume you're building a self-driving spacecraft (it's only a matter of time), this sounds like a non-trivial problem. Where would you start? There has to be a lot of stages where you don't know if you're building the right thing. The way to approach this is to build incrementally and test whether you've built the right thing. I'm not going to defend this statement, you can google agile delivery. What I want to focus on is how I structure this approach in my head. 

1. Identify one customer/stakeholder that you can deliver value for. 
2. What's the smallest acceptable increment for them?
3. Do or build that thing.
4. Measure (Get feedback, look at metrics), learn.
5. Repeat

You'll notice that I haven't talked about whether it was successful or not, the outcome I'm looking for is learning. That learning then feeds back into the cycle so that I can increase the value delivered.

Let's apply this to the spacecraft. Our first customer could be the test-pilot that is going to sit in this crazy contraption. For this person, we'd build a giant red button that could be pushed to stop everything. Value delivered is we now have a pilot who has a slight increase in psychological safety - if the test pilot doesn't feel safe we're never going to get a real customer. We can measure this before and after, and we can assess whether we have delivered value. We haven't solved the self-driving problem, but we're a step ahead. What if it didn't increase psychological safety? Well, in that case, we'd have learnt something and would have an idea of what to try next. At no point was I looking for a perfect solution, or had an exact idea of how to build the spacecraft, all I was looking for was learning what would get me closer to the spacecraft.

Now I used some very specific wording in steps one and two. For the first step, we only focus on one customer or stakeholder at a time. Delivering value for everyone in one go is complicated, and if you do fail it will also be complicated to unpick why. For the second step, I used the word acceptable because you have to use your judgement about what is acceptable or not. These increments don't have to be uniform in size, they just need to be discrete enough that you can deliver it and also learn from delivering it.

It's okay to fail and learn. It's okay to not have all the answers before you start. It's okay if the first thing you create is not perfect, those imperfections will guide you on the path to perfection. Failure is a mechanism to learn and I encourage you to think of failure as an acceptable outcome.