- Channel HP
- :
- Enterprise Business Blogs
- :
- Services
- :
- Transforming IT Blog | The HP Blog Hub
- :
- Test fast, fail fast, adjust fast
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content
Test fast, fail fast, adjust fast
I just read through an article called "To Increase Innovation, Take the Sting Out of Failure" by Doug Sundheim, Harvard Business Review, January 9, 2013. To quote an overused cliché, I felt like I had déjà vu all over again. It seems that this idea is still holding on from the dotcom era when it was stylish to invest in a failing business. True, some of those then-failing business models produced some of the most important corporations today (but sadly, many did not).
One of my personal heroes, Tom Peters, writer and expert on business management, also used this mantra in his discourse. The books and audio tapes (yes tapes) that I have read and listened to over the years (In Search of Excellence, The Circle of Innovation, The Brand You, The Project, and The Professional Service Firm, to name a few) might have presented a little more liberal approach in the application of his concept fail, fast, forward, than others did. But Peters was convinced that excellence will only come when failure occurs quickly and often.
In a 2001 lecture for the Stanford Technologies Venture Program, then Autodesk CEO Carol Bartz illustrated how her employees were encouraged to follow the mantra fail, fast, forward, primarily to encourage innovation while embracing the fact that failure is inevitable when implementing a new process or developing a new product. To further clarify her ideas, she stressed that if something does fail, there is fast response and immediate root cause analysis of the failure, and that even though a failure occurred, hopefully the overall process is still moving forward. Using this controlled methodology will tighten up the failure process.
Similarly, in the Apr 14, 2011 edition of The Economist, an article titled Fail often, fail well with the sub-title “Companies have a great deal to learn from failure—provided they manage it successfully” provided some sage advice on success and failure:
- Amy Edmondson of Harvard Business School articulates the importance of distinguishing between productive and unproductive failures. She goes on to say that “…simply embracing failure would be as silly as ignoring it.”
- When Alan Mulally became boss of an ailing Ford Motor Company in 2006 he required his managers to produce reports that clearly delineated all failures. When all of the reports came back with perfect marks, he was astonished, given that the previous year Ford lost $7 billion. His managers were afraid to admit failure.
- “Placing little bets” and minimizing collateral damage from a failure allows for a quick rebound in order to keep going.
These principles also apply to the technology domain. Certainly there is absolutely zero room for error in keeping a data center on line where failure IS NOT an option, but the research and innovation process that goes into designing the data center creates an environment where new ideas can be explored and analyzed. Through an iterative research and analysis process (that includes failures), the methods used in the strategy for planning and designing a new data center are honed, becoming more cohesive and repeatable. I think Tom Peters said it best: “Test fast, fail fast, adjust fast.”
So I ask readers: is the notion of failing smart still applicable in today’s tough economic environment, especially in the IT sector? Or have we all reigned in our risk-takers, playing it safe until the storm passes?
Get solutions from the Experts. See what else they can do for your Business here.
- Mark as Read
- Mark as New
- Bookmark
- Highlight
- Email to a Friend
- Report Inappropriate Content
Bill,
I think there is also value in taking the sting out of failure for failures of data centers and infrastructure. IT organizations that operate a culture of blame, "if there is a major failure in IT then let's punish the guilty", have some of the least reliable IT services. Other organizations that accept failure and use it as an opportunity to learn do much better.
I have seen technical people hiding the truth about the real cause of failure from their management, because they couldn't afford to take the blame for the outage. As a direct result of this culture the underlying causes have remained unfixed. IT organizations really do need to understand that the most important thing to do when things go wrong is to encourage and reward transparency, so that they can learn from their mistakes and get better.





