The importance of failing quickly and often

Friday, December 3rd, 2010 by Robert Cravotta

When do recent graduates of kindergarteners outperform recent graduates of business school? Believe it or not, according to Tom Wujec, kindergarteners consistently perform better than business school graduates in the Marshmallow Challenge. This is not a challenge to see who can eat the most marshmallows; rather, it is an exercise in teamwork and rapid prototyping.

The challenge consists of a team of four members building the tallest structure they can using only a single marshmallow, strands of dry spaghetti, a roll of masking tape, and some string. The major constraint is that the marshmallow must go on the top of the structure. The mass of the marshmallow makes this project more challenging than you might first assume.

In Tom’s video, he explains that kindergarteners do better than the business school graduates because they approach the process of building the structure in a more iterative and prototyping sequence than do the business graduates. The kindergarteners start building and placing the marshmallow at the top of the structure right away and they receive immediate feedback from when the structure stands or falls that enables them to make improvements in the next attempt. In contrast, the business graduates discuss a plan of action, choose a direction, and typically do not place the marshmallow on the top of the structure until near the end of the challenge, and when the structure fails, there is not enough time to perform another iteration of rebuilding the structure.

I bring up the Marshmallow Challenge because it augments Casey Weltzin’s recent article “To Design Innovative Products, You Must Fail Quickly” about the importance of prototyping and the role of failures during the prototyping process. Engineers are intimately familiar with failure – in fact, I remember there was a unit on errors and failure as part of my engineering undergraduate studies. Not surprisingly, the people who consistently do the best in the challenge are engineers and architects.

The unrelenting and almost predictable pace of technological improvements that engineers deliver decade after decade belies the amount of failures that engineers experience and iterate through behind each of those publicly visible successes. In a sense, our repeated success as an industry to deliver ever more functional systems at a low price point engenders a sense that it is easier than it truly is to perform these feats of innovation over and over again.

Another interesting observation in Tom’s presentation is that adding an executive admin to a team of CEOs and company executives significantly improves their performance in the challenge than the team without an admin. One take away I see from this is that it is important to be able to expose and remind your management that design is an iterative process where we apply our assumptions to the real world and the real world smacks us down by pointing out our hidden or unspoken assumptions that do not quite align with reality.


4 Responses to “The importance of failing quickly and often”

  1. Jon Titus says:

    Kids in kindergarten also feel less peer pressure that people with MBAs, to they’re likely to try many things that might seem “dumb” to people with more education.

  2. I.B. @ LI says:

    Thanks for pointing on the Embedded Insights – it’s the interesting resource.

  3. A.N. @ LI says:

    Instead of “business school graduates”, it would be interesting to see how Engineers perform – you’ve already hinted that Engineers are also more likely to adopt an interative, prototyping approach.

    It would also be interesting to compare how recent engineering graduates compare with experienced engineers.

    A very disappointingly large number of posts on internet forums are along the lines of. “I wrote this code and it doesn’t work. What’s wrong?”
    There is no attempt at analysing what, exactly, is “wrong” – it should be obvious that this is an essential precursor to fixing the problem, but simply doesn’t seem to occur to the posters!

    The important thing is not that you fail, but that you can analyse the reasons for failure – and do better next time!

  4. A.F. @ LI says:

    An interesting point raised in the article is the misuse of planning for the resolution of unstructured problems. A hidden assumption by those doing the planning is that they have “perfect knowledge” of the problem domain. In embedded software or any other software realm for that matter, such an assumption is misleading at best and delusional at worst. I’ve seen far too many well crafted “plans” go off the rails because of unanticipated problems. Unfortunately in today’s corporate world, you won’t get the go ahead for a project unless you have a plan, hence the use of hedging and hidden contingencies in the schedule.

Leave a Reply