Howard Tullman writes the Perspiration Principles blog in Inc. His recent post “Who Said Failure was Fashionable? Frankly, It Sucks” made four great points:
Mistakes vs. Failures
Somehow, it has become cool to brag about how your last business failed–and what a wonderful learning experience it all was. But that’s a crock. You only fail when you give up, and giving up is something that winners never do. In my opinion, only cretins celebrate their failures.
Making mistakes, on the other hand, is something you have to do from time to time. It’s a sign of a healthy, active and risk-taking business. Mistakes are a critical part of growing and expanding your company and, if you’re not stubbing your toe from time to time, you’re not pushing forward. Rapid growth and constantly changing circumstances are inherently embarrassing – you need to get used to it. A thick skin helps a lot in a start-up.
If you have a plan for what you will do if your current course of action does not bear fruit it’s much harder to fail. It’s when you believe you cannot lose or you decide to put all your reserves on one last effort that you can fail. Trust and relationships can survive mistakes, but not if you actively misled your partners or customers.
1. Make cheap mistakes but be selective-don’t try to do things cheaply that you shouldn’t do at all.
Prototypes are cheap mistakes. They are designed to capture a significant aspect or fraction of the total challenge at much lower cost than the final solution. Like crash test dummies prototypes can also be instrumented in ways that would compromise the final product. New mistakes are better than repeating old mistakes at lower cost.
3. Don’t dwell on the past.
This is one that I have trouble doing well. I revisit old mistakes so that I can learn from them, but I sometimes find myself reliving the emotions in a way that’s not productive. I can tell when I am under stress because I start to dream that I am back in school faced with an exam I have not studied for. But there is a great feeling of contentment when I revisit an old mistake and unlock an insight for an new approach next time. I think that may be the reframing that’s essential: from “if only I had not…” to “next time I will..”
4. Distinguish between mistakes (errors that happen once) and systemic problems (errors that happen over and over again).
I think it’s common to attribute systemic problems to a one time occurrence. I remember when I was at Cisco the compiled system image grew too large to fit onto the EEPROMS that system booted from. We had not anticipated this so we were not tracking image size growth and were surprised that we could not ship new upgrades. We did some quick re-arrangement of the code to buy ourselves a few weeks and then came up with a workaround where a small boot module was included with a compressed image to uncompress it at system startup.
Of course we didn’t start tracking image size so 9 months later we were surprised when even the compressed image would not fit. When we plotted code base size and image growth we discovered that growth it was correlated with the number of active developers. We had been adding staff continually so the image was growing faster and faster.
The first time the image grew too large it was arguably a mistake, the second time it was clearly a systemic error.