What You Can Learn From Kindergarteners

In a 2006 Ted Talk, Peter Skillman introduced a very interesting design challenge known as The Marshmallow Design Challenge.

The experiment itself is very simple. You take a large group of people and divide them into teams of five. The goal of each team is to build the tallest free-standing structure possible out of 20 sticks of spaghetti, one yard of tape, one yard of string, and a single marshmallow that is gingerly placed on top. Each team has 18 minutes to build their tower and the tallest structure wins.

Technology pioneer and Autodesk fellow Tom Wujec saw great value in this experiment and decided to implement the design challenge in several workshops he hosted on teamwork. The people who would attend such workshops spanned from engineers, architects, and C-suite execs to lawyers, business school graduates, and… kindergarteners.

Among these groups, he found that the teams comprised of engineers and architects obviously performed the best. What was more surprising, though, was that kindergartners regularly beat out all the other teams, with business school grads and lawyers building the worst structures.

Even more interestingly, when Wujec would introduce a high-stakes reward for building the biggest tower, not a single group was able to build anything.

Astounding, isn’t it? Kindergartners are keener than your average CEO. High stakes make us all suck. Or is it that simple?

Looking at the kindergartners versus the business school graduates, we can see a very clear difference in what works versus what doesn’t.

Business school graduates would complicate the problem by aiming to find the singular, most perfect solution. They would orient the approach, plan the project, and spend maybe 10% of that time actually building. They would run out of time and fail spectacularly.

Kindergartners intuitively do what most developers, technologists, architects, or any problem-solver should always do. They start with the marshmallow on top and build several prototypes over the course of 18 minutes. They iterate early and often.

Now you might think that since engineers and architects were already the most successful in this design challenge, you may have nothing to improve.

Quite the contrary. When all of the participants redid the challenge four months later but were told to intentionally iterate and build out prototypes, every single group improved a considerable amount — including the engineers and architects.

The question is: What were the engineers’ flaws in the first place to make them perform worse than they could have?

The Fear Factor

An issue I see among many developers, including myself, is the need to be perfect. The need to know the most correct outcome. The need to know every token of knowledge a project requires.

Newer developers lack confidence in their own skills simply because they can’t solve an algorithm, a programming problem, or build a basic project without having to look something up. This catalyzes their imposter syndrome and the internal belief that they are incapable.

Even experienced developers I know are scared to tackle harder problems and more complicated projects simply because they feel uncomfortable with the knowledge required to build out such a project.

Some developers, especially myself, spend so much time planning and thinking about all potential routes towards a solution that we counterintuitively impede progress.

We fear uncertainty. We fear failure. We fear our own ability. It’s that very fear that impedes our ability to grow and get things done so much.

“I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.” — Frank Herbert, Dune

The Other Side of Fear

So, you ask, “What could the engineers have done better in building their marshmallow spaghetti tower?” I mean, they already did so well. Honestly, given their improvements over time, I’d say that intention to “move fast and iterate quickly” is a very important factor.

That intention is what separates a good or fast-growing developer from a struggling, slow-moving one. That intention to move fast, fail early, and iterate quickly is enough to eliminate a good amount of fear.

You can’t worry about whether or not your approach is the right approach. You can’t be anxious over your lack of knowledge. You can’t eliminate all uncertainties.

In truth, the only way to eliminate uncertainties, bridge the gaps in your knowledge, and know the right path is simply through action.

Failure illuminates the certainties in the approach to your solution. When you know what’s certain about what will or will not work in your strategy, then you’ll have even more to build off of in order to construct a more resilient solution.

Failure allows you to really gauge and understand your point of knowledge — it allows you to see your capabilities. From experience, there is nothing more rewarding than seeing my knowledge grow, no matter how small the improvement is.

It is for this exact reason that I willingly take on projects that are beyond my recognized level of skill. I discover more about what I don’t know and realize that it’s not as hard to figure out as I thought. As a result, it makes me grow. Fast.

Therefore, be like a kindergartener! Let your ego subside and your pride wash away. Allow yourself to become comfortable with the discomfort and fear of not knowing.

Dive into your problem and learn to understand it, build it, and optimize it as you are moving along. It’s OK to figure out things as you go. It’s OK to not know everything. In reality, we hardly know a thing anyways.

My memory is trash and I have to pretty much Google my way to a solution 85% of the time! That’s OK. After all, the whole point of innovation is to tackle the unknown with confidence and courage that you can figure it out.