-
Website
http://andrewchenblog.com/ -
Original page
http://andrewchenblog.com/2009/07/13/built-to-fail-how-companies-like-google-ideo-and-37signals-build-failure-tolerant-systems-for-anything/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
Roger.
http://en.wikipedia.org/wiki/Fail-fast
There are a lot of analysts that would wholeheartedly disagree with this concept.
I think its more likely that this just demonstrates that relationships and planned outcomes are a lot more complicated than we can expect or perhaps even understand fully.
"Planning to fail" is a key part of contingency planning and risk mitigation, but its a very different thing than expecting random outcomes (particularly in personal relationships).
MKS
The key should be finding the right metrics to measure failures and learn from them quickly. If you have read "The Game-Changer" by A.G. Lafley and Ram, you will find out even P&G has adopted similar approaches.
Additional information on how failure breeds success, including the examples of GE, Intuit, Coke...etc:
http://www.businessweek.com/magazine/content/06...
We are scaling up our company right now and pressing forward and this piece is fantastic. Thanks.
Jon at zhiing
You didn't just one day say -- ok lets start walking today!
A nuance I think you touch on is that it's not so much that organizations who embrace the reality of failure are motivated by a fear of not succeeding, they know that the knowledge gained from failure only speeds them to success. So, yes, they love the idea of lots of low cost experiments because its the failure as much as the success with these that will provide a durable advantage. IDEO's "structured brainstorming" is a wonderful "operationalization" of this philosophy.
Organizations who fear failure build in a structural inability to be nimble, to learn, and to make the critical adaptations rapidly that will get them to even be in the same game/ They may succeed at not making a "mistake" but winning that battle will lose them the war.
I wrote a post on this theme of "Lots of Low Cost Experiments" earlier in the year, which touches on some of the key points in your post today. http://openambition.com/2009/04/22/lots-of-low-...
Pete
Based on his comments about not embracing failure, I have a feeling he might disagree with your thesis about his company. Maybe you should consider updating the post to reference Ruby On Rails specifically, rather than 37 Signals. That seems to be a more accurate comparison.
Well, it's a different architecture - different needs too. The mainframe is much more expensive, so it all comes to requirements. If one Google box fails that references 10000 of websites, and these are absent of a search result, that's no big deal. Also if 1000 Gmail users can't log in during 15 minutes, that's no big deal - no one is going to be fired or to sue Google for that.
Now think about 1000 of transactions on the NYSE that fail. That's another type of consequences. That signifies $$$ of losses. Or would you like your monthly paycheck to be lost randomly? Probably not. These are the case where you need special hardware. It's fault tolerant, complex & expensive, because it would be even more expensive not to have that degree of tolerance-fault. That's why both architectures coexist. There is not a "one fit all" solution.
BTW, some study has shown that people that have a plan B tend to be less depressive because they can adapt better to the new reality... So failure has to be in the plan, too.
The concepts outlined in this post probably apply to bigger organizations that have significant resources. A small resource-constrained startup is not going to plan for failure and build the redundancy that you prescrible.
NOT a good post Andrew - it does not sound like you know your material! Sorry for this harsh criticism.
Thanks for stopping by my blog! You have some interesting articles here. If you need to reach me, you can email me at happycloudmoments at gmail.
Have a great night!
The difference is subtle between "no" as feedback and "no" as correction, but the result is dogs that are problem solvers rather than ones afraid to try new things for fear of being punished. The goal of any company should be to "breed" problem solvers. You do this, as Andrew points out, by planning for, accepting, and even celebrating failed attempts to solve problems.
Don't play to the "cowboys" here -- there is always a need for process, and anything has a process, even if it is chaotic. It can be documented and managed well to produce a better result.
Also, as Cedric mentioned, Google's 20% policy is huge. In a way, they bake failure into the culture. Relative to other companies, at Google there doesn't appear to be the blamed placed on those who tried and failed.
However, for a large organization in the middle of a massive IT project affecting supplies, employees, or vendors, failure may be less acceptable. The consequences can be so severe that it affects employees receiving paychecks, corporate security, the accuracy of financial reports, and the like. This is particularly pronounced in development efforts that follow the Waterfall method.
If adopted, methodologies like Agile software development should decrease failure rates. Of course, people will ultimately determine whether these projects fail much more than any methodology or technology.