Failure is good. We learn from failure.
Failure is learning; the information content of a failure may be more than the information content of success. Failure isn’t failure, it’s an opportunity to pivot.
Failure is capitalism’s Darwinian evolutionary mechanism to remove the less productive, the less relevant. Fail fast, fail cheap, learn, try again.
Creative Destruction is the way capitalism remove legacy companies to create space for the new by allowing resources to be redeployed.
All true… well at least to some degree but lets not argue about that today.
The problem is: How do you know you’ve failed?
Or to put it another way: What does failure look like?
Or: When do you know its time to pivot?
Some failures are clear cut: customers don’t buy your product, or too few customers buy your product to allow you to stay in the market.
Our software does not perform as expected, it doesn’t process transactions fast enough, or a rocket blows up.
As engineers we like clear cut failure and success. We look for clear failures or at least clear bottlenecks if only because we are certain they exist. But that isn’t always the case. Sometimes there are no clear success or failure states. And sometimes we don’t call it a failure because we really think we can make it work.
Rationally the business plan or strategy should allow us to know what success loos like and what failure looks like. But what if the strategy is itself flawed?
Flawed strategy might be obvious to one person but hidden to another. When strategy is flawed it runs like a fault-line under everything that is being done. One clue is that lots of little failures keep appearing, seemingly unconnected perhaps but actually connected because they are originate in the fault line.
(Think if this like a stack corruption bug, you don’t normally know you’ve got stack corruption but you get apparently random failures. When you chase these failures they move. Back when I was still programming I knew I had stack corruption because the fault moved every time I thought I was getting close.)
Even when surrounded by failure we look to explain it away, we believe (hope?) we can fix it – after all, we are learning from those failures and we are trying to fix them aren’t we? And people like me (consultants!) asked to help you address your problems and fix your faults.
But when do you call time? When do you say things are irreparable? When do you stop trying? To use a better know example: When is a war won? And when is it lost?
In 1945 Victory meant the Allies taking Berlin. Once Berlin was taken and the genocidal Government was disposed the war was over. In 1991 Victory meant retaking Kuwait.
Afghanistan 2015? – some say success, the west was victorious! and some say it was a failure. Failure and success is not clear cut. For the generals and politicians its hard to walk away from a failured war, far better to find some success, get out and disown the subsequent failure – like the 1973-1975 gap in the fall of Vietnam.
Since failure is not clear, and especially since victory could be grasped out of the jaws of defeat by calling in more troops, more consultants, better consultants, more expensive consultants how do we know it is time to pivot?
When do we pivot and when do we surge?
And since failure is still failure, and no matter how much we call it a pivot or repeat that we learn from failure we still don’t like it; when, o when, do we call failure failure and when do we call it pivot?
And like Generals, Senior Managers can’t walk away from a failure, that would be career threatening. Far better to surge, get to something which looks like victory, get out and disown what happens next. (If you are spending your own money you have an incentive to get out quick, if you are spending someone elses money…).
When pivoting is unattractive, when pivoting means people loose jobs, when pivoting means executives have to explain to their board, when pivoting means shaman consultants no longer take their cut… why pivot when you can surge?
Surge – call for help.
When we are failing without a clear cut failure we see problem after problem and each one is explained away.
When do you declare failure and pivot?
Undercover Economist Tim Hartford had a good piece recently: “You don’t know when to quit”. The true grit, carry on trying idea doesn’t seem to stand up to analysis. Rather than persevering at something difficult a better strategy might be to try something else.
The more money that has been sunk into the initiate the greater the difficulty in pivoting – nobody likes sunk costs, why sink the money?
For a Silicon Valley start-up living on credit cards illusions are painful, there can be very little tolerance for failure, failure must result in a pivot or death.
But for a corporation, for an established vendor, a brand, a reputation; failure might mean they are simply not trying hard enough – and heaven knows some companies tie themselves in knots. Why not through more money at the problem? More people, more experts – surge!
And so we are back to Do it Right and then Do the Right Thing (blog) (and Do Things Right Thing and then Do the Right Thing presentation.)
For a software team capability means: delivering working software. If you can’t deliver working software you have a clear failure. But if you are delivering software slowly, so, slowly, how do you know? What software developer or product manager hasn’t wanted to deliver more faster?
If you lack the capability to iterate then you can’t deliver.
If you lack the capability to iterate you cannot build feedback loops.
If you can’t build feedback loops then you cannot validate your market or your product.
If you can’t validate product or market then your strategy is high risk.
If your strategy is high risk then you really need a high pay-off to justify it. But if you can’t iterate then its likely your costs are going to absorb far more of that pay-off.
You might be able to buy victory but the price will be so high it is worth asking: is it a victory you want? Is it a victory you can recognise?
| Reference: | Surge or pivot? – notes on failure from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog. |
