30 people in a room, divided into 6 teams. Each team gets 20 sticks of spaghetti, a yard of string, strips of scotch tape, and one marshmallow. They have 18 minutes to build a free-standing structure that will support the marshmallow to rest on top. This is the so-called marshmallow challenge, a staple of many design schools.

In an arresting seven-minute TED talk, Autodesk fellow Tom Wujec shares data suggesting that, while the average team produces a tower with a height of about 20 inches, business school students tend to significantly underperform the average.

I’ve seen it with my own eyes. Graduates gather together. They spend the first few minutes trying to establish dominance. One emerges as a leader. The next few minutes are devoted to planning. Construction begins, usually with less than eight minutes left on the clock. Then, with about a minute to go, someone places the marshmallow on top of the beautiful tower, and… it collapses.

While MBA students do poorly, kindergarteners beat the average. Children don’t dither; they simply try something small at first. And if it doesn’t work, they try again – little time wasted. Once something works, another stick is placed, and another and another.

It’s fascinating to watch, and completely expected if you’re familiar with Gall’s law.

Complex systems and Gall’s law

John Gall’s 1975 book Systemantics: How Systems Work and Especially How They Fail explores what we can learn from system engineering failures and how not to design systems. The analysis spans a vast amount of disciplines, applications, time and space.

Gall’s conclusion is as profound as it is simple: complex systems can only emerge from simple systems that have stood the test of time.

Beautiful, right? Empirical evidence supports something we can intuitively resonate with.

The world appears to be just too difficult to plan for. Starting with (and building on) shippable, simple designs that are used in the real world is the only way to succeed. The fabric of reality is simply too thick to penetrate with foresight alone, no matter how good the intentions are.

We know this. The surgeon student will not operate a heart transplant straight after mastering and passing the theory test. The astronaut will not launch into space straight after reading the briefing.

We know this. And yet, we expect our everyday to be an exception to the rule. How many times have we come up with elaborate New Year resolutions for complete life transformations, only to fail 1 week into the year? How many times have we come up with a new routine we draft for ourselves, only to abandon it immediately after hitting the open water?

We know this. And yet we expect our projects to be an exception to the rule. How many times have we produced beautiful deliverables, charts, plans and milestones, only to have the entire roadmap challenged by the first process analysis results? How many times have we allocated weeks/ months of planning ahead of any direct work towards the outcome we seek?

So, if we know that overplanning rarely works, why do we still do it? Why are so many marshmallows still falling and is there a way to fix it?

The false promise of overplanning

Few things are more seductive to anyone with a mission than a clear plan of action. Think about it:

1. I’ll read the book by the end of the week – no problem. Without having finished any book in the last 2 months
2. I’ll go to the gym/ exercise every day – no problem. Without having worked out regularly in years/ ever
3. We’ll go-live by the end of the year – totally achievable. Without writing a single piece of code.
4. The app will hit 100,000 active users by year 2 – this projection makes it seem ok. Without even launching a beta.

Admit it. We love the clarity and apparent predictability that a robust plan gives. But often (read “almost always”), that feeling of comfort is really all we’re going to get out of a complex plan.

The book will probably not get read, the gym subscription will probably go underutilised, the go-live will probably be delayed and the user base targets will have to be adjusted.

We get so excited about ensuring things look right on paper probably because paper is something we can control – and controlling chaos is what projects are all about (be it personal or professional). The more control, the better.

But what happens when control on paper doesn’t translate well to control in real life? How can we stop confusing the menu with our dinner, and how can we stop growing ever hungrier?

Underspecification – the agile way

In systems design, the solution overplanning seems clear. Underspecification.

You have a meaningful destination in mind (a desire, a need, a want, an ideal end-state). Forget about plotting the entire path, just focus on the next step! And then the next, and the next after that.

You want to build a marshmallow tower? Forget about drawing the structure and discussing the best types of joints. Just focus on getting the marshmallow off the ground first. And then how to get it higher, and higher.

You want to have a better life? Forget about planning your year on the 01 of January. Just focus on having a better day. And then another one, and then another one after that.

You want to have a successful go-live? Forget about laying out 100s of fixed milestones. Just focus on a minimum viable product that your users can give feedback on. And then the next feature, and then the next feature after that.

Sure, you might fail one day, or one increment – even two or three, that’s ok. That’s what you want – small, continuous course corrections (be them positive or negative) to spiral you towards success.

Agile is the methodology that I found to work best with projects. This replaces the comfort of plans with the far more useful comfort of shipped (shippable) product. And when it comes to life, perhaps atomic habits are better than life transformation wishes.

Key takeaway

Complex change does not survive on its own, propped up only by ephemeral concepts and plans. It has to grow. The only way to achieve this is to take things one step at a time, adjusting course where necessary (no matter what your preconceptions were at the start) and keeping your end-state/ mission in mind all the way.

That’s how we change our life. That’s how we change organisations. That’s how we win the marshmallow challenge.