What is Really Meant by Failing Early, Failing Often, and Failing Cheap?

What do we mean about failing early, failing fast, failing often, or failing cheap? Why is "failing" a good, positive outcome for some features, agile projects or agile delivery? Why is it needed for innovation?

Failure was once an absolute outcome. You either succeeded or failed in your business, your project or your investment. Once something was marked as a failure, it was almost beyond hope to fix it without a major "turn around" or dramatic rescue.

Failing early, fast, often, and cheap gives business and IT leaders many advantages:

  • It basically implies that you've defined indicators for success or failure ideally as key performance metrics. That definition creates an alignment of goals, transparency, and process to discuss improvements.
  • Failing early implies that you're taking some (appropriate) risks up front and can adjust your course while your business or project is in early stages.
  • Failing fast implies that you're making small, tactical changes with easy mechanisms for measuring that you're tactics are meeting strategic expectations.
  • Fail often is an attribute of agile and iterative delivery. If you deliver often you can accept some failures because you have a mechanism to recover, respond, and adjust faster. (Corollary: Deliver often should also encourage success often!)
  • Failing cheap is exactly how it sounds - but it encourages the leadership team to find inexpensive investments and expressions to validate a hypothesis.
  • Talking about failure openly allows teams to think offensively rather than defensively. It helps to avoid a "fear of failure" organizational culture.
By failing early, fast, and cheap, there is a mechanism to avoid absolute failure.

I like the open acceptance of failure as a mechanism to encourage smart risk taking, however, I do wish there was a better form of expressing this mindset. When I hear leaders encouraging teams to fail early, fast or cheap, I often wonder if they deliver the message correctly. Do team members understand the message as I describe above, or do they hear something entirely different? Maybe they hear, "give this your best shot, but don't worry, we won't penalize you if it doesn't work out because failure is ok". Or maybe they hear "it's ok to make errors as long as you fail early, fast and cheap". Also, even if you fail early, the right decision may be to pivot rather than abandon the current strategy (see Pivot, don't jump to a new vision and When your first product isn't selling).

Should we change lingo? I doubt it because the concept is easy to understand as long as leaders take the time to explain what they really mean by failing fast, early, and cheap.

4 comments:

  1. Then it seems we can say that failure must be mediated. Shortcomings must be understood and individuals and teams should be permitted to feel the pain and humiliation of failure in a constructive way. Leaders should participate to engage people in productive dialogs so the failure mode is understood and appropriate options are identified to avoid similar problems in the future. And in that scenario leaders are very important mediators of the process.

    Regards,

    Sal.
    ---
    Salvatore Saieva

    ReplyDelete
  2. Sal - Thanks for the comment. I like the idea on productive dialogs around failures. Some orgs call these postmortem, but I think a healthier view is a product/business level agile-like retrospective. So instead of focusing on failure, focus on review and improvements. Hopefully, this can avoid the pain/humiliation of larger scale failures.

    ReplyDelete
  3. If this article appeals to you, you are the type of person we value for your intelligence, motivation and ability. Please contact us for the best executive jobs. The market is not dead - it is simply competitive.
    www.TheLadders.co.uk
    executive jobs

    ReplyDelete
  4. Well, detecting failures fast, early (and
    by that, somewhat cheap) is fine. And while
    it works well in application development -
    what do you do when building new technology?

    I think there are areas where you can compare the granularity with cooking a turkey - you can win or fail only for the whole turkey, and it hardly matters whether the breast is tender when the rest is burned to coal ...

    ReplyDelete

Comments on this blog are moderated and we do not accept comments that have links to other websites.

Share

About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld, CIO.com, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.