How Do You Deal With Marshmallows?

Yesterday, Kris left great comment with a compelling link to a TED presentation by Tom Wujec, a fellow at Autodesk.

Back in June, I commented on Steve Spear’s article “Why C-Level Executives Don’t Engage in Lean Initiatives.” In that commentary, Spear contends that business leaders are simply not taught the skills and mindset that drives continuous improvement in an organization. They are taught to decide rather than how to experiment and learn. Indeed, they are taught to analyze and minimize risk to arrive at the one best solution.

Tom Wujec observes exactly the same thing. As various groups are trying to build the tallest structure to support their marshmallow, they consistently get different results:

So there are a number of people who have a lot more “uh-oh” moments than others, and among the worst are recent graduates of business school.


And of course there are teams that have a lot more “ta-da” structures, and, among the best, are recent graduates of kindergarten.[…] And it’s pretty amazing.

[…] not only do they produce the tallest structures,but they’re the most interesting structures of them all.

What is really interesting (to me) are the skills and mindsets that are behind each of these groups’ performance.

First, the architects and engineers. Of course they build the tallest structures. That is their profession. They know how to do this, they have done it many thousands of times in their careers. They have practiced. Their success is not because they are discovering anything, rather, they are applying what they already know.

In your kaizen efforts, if you already know the solution, then just implement it! You are an architect or engineer.

BUT in more cases than we care to admit, we actually do not know the solution. We only know our opinion about what the solution should be. So, eliminating the architects and engineers – the people who already know the solution – we are left with populations of people who do not know the solution to the problem already. This means they can’t just decide and execute, they have to figure out the solution.

But decide and execute is what they are trained to do. So the CEOs and business school graduates take a single iteration. They make a plan, execute it, and fully expect it to work. They actually test the design as the last step, just as the deadline runs out.

The little kids, though, don’t do that.

First, they keep their eye on the target objective from the very beginning.

Think about the difference between these two problem statements:

  • Build the tallest tower you can, and put a marshmallow on top.


  • Support the marshmallow as far off the table as you can.

In the first statement, you start with the tower – as the adults do. They are focused on the solution, the countermeasure.

But the kids start with the marshmallow. The objective is to hold the marshmallow off the table. So get it off the table as quick as you can, and try to hold it up there. See the difference?

More importantly, though, is that the kids know they do not know what the answer is. So they try something fast. And fail. And try something else. And fail. Or maybe they don’t fail… then they try something better, moving from a working solution and trying to improve it. And step by step they learn how to design a tower that will solve the problem.

Why? Simply because, at that age, we adults have not yet taught the kids that they are supposed to know, and that they should be ashamed if they do not. Kids learn that later.

Where the adults are focused on finding the right answer, the kids are focused on holding up a marshmallow.

Where the adults are trying to show how smart they are, the kids are working hard to learn something they do not know.

Third – look what happened when Wujac raised the stakes and attached a “big bonus” to winning?

The success rate went to zero. Why? He introduced intramural competition and people were now trying to build the best tower in one try rather than one which simply solved the problem.

Now – in the end, who has advanced their learning the most?

The teams that make one big attempt that either works, or doesn’t work?

Or the team that makes a dozen attempts that work, or don’t work?

When we set up kaizen events, how do we organize them?

One big attempt, or dozens of small ones?

Which one is more conducive to learning? Answer: Which one has more opportunities for failure?

Keep your eye on the marshmallow  – your target objective.

Last thought… If you think you know, you likely don’t. Learning comes from consciously applied ignorance.

Edited 2 August 2016 to fix dead link. Thanks Craig.

8 Replies to “How Do You Deal With Marshmallows?”

  1. Perfect!

    This information and insight is helping me a great deal as I plan some new and improved Kaizen events……

    Thank you.

  2. I’ve always said that “Engineers understand how something is supposed to work. The folks who actually run the process “understand how it really works.” As I think we all know, sometimes there’s a big difference between the two.

  3. Mark,
    How correct you are. Maybe that’s why Mr. Nakao (of Shingijutsu) always valued Engineers “with dirt under their fingernails.” They knew both how is was supposed to work and how it really worked. A rare breed indeed!

    1. I have great respect for engineers. It is engineers who harness scientific knowledge and put it to practical use. Engineers put a man on the moon – indeed the astronauts themselves were mostly engineers.

      Today I think engineers get a bad rap, not so much for the values that they hold, but rather because of the processes and systems they work within.
      Their organizations try manage them in ways that separate “thinking” from “doing.” They are prevented from learning by those processes.

      Of course there are a fair number of engineers who believe learning is no longer necessary, but I would contend that they are more rare than our experience might suggest. Most, given the choice, would rather “get dirt under their fingernails.”

  4. Mark,

    On behalf of dirty-fingernailed engineers everywhere, thank you.

    Appreciation of the practice is rare but very much welcomed.

    And you’re absolutely correct, few organizations encourage it. Some even forbid it. Most systemically discourage it either actively or passively by their structure and procedures.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.