I didn't tell them the bricks would need to merge. That was the point.
When I designed the LEGO challenge for my design team's workshop, I made a deliberate choice to withhold one piece of information: that their individual models would eventually have to become one. I wanted to see what they'd build when they thought they were only building for themselves. I wanted to see what their instincts looked like before the pressure of consensus arrived.
What I got was more revealing than I expected.
The Problem
The scenario I gave them was a city in crisis. Severe flooding. Rescue teams needed immediately. Conditions chaotic. Data fragmented or missing. The brief was precise: design a system that helps prioritise response effectively. Not an interface. Not a wireframe. A system — with information sources, decision points, alerts, response teams, and actions taken.
The constraints were strict: no notes, no drawings, only physical LEGO models. Use bricks as symbols. Build your thinking with your hands. No safety net of a keyboard or a slide.
Fifteen minutes. Work alone. Trust your instinct.
Four People, Four Completely Different Instincts
What spread across the table when the timer ended was one of the most honest things I've seen from a design team.
The first person had built everything on a single base plate. Every element was connected — stacked, interlocked, part of one unified structure. If you lifted the plate, the whole system moved with it. Nothing was separate. Nothing would fall apart. It was immediately legible as a system that had been thought through completely before the first brick was placed.
The second person had built two distinct blocks — two sub-systems that related to each other but existed as separate units. A practical choice: they had recognised the problem had two distinct layers and hadn't tried to force them into one structure before they'd understood both.
The third person's model was pieces arranged across the table in a deliberate spatial pattern. They had prioritised storytelling over structure — each brick represented an element of the scenario, placed in relation to the others to communicate sequence and flow. You could walk through the story by moving your eyes across the table. It was evocative. It was also fragile. Nothing was actually connected.
The fourth person's model was bricks laid loosely next to each other in a rough shape. They are someone who thinks in stories — naturally, fluidly, with strong narrative instinct. But in this exercise, the storytelling impulse had overtaken the structural one. The details, the logic of how the system actually functioned, had been left out in favour of atmosphere.
Four designers. Four different orientations. All of them visible in fifteen minutes of LEGO.
The Person Who Surprised Everyone
The first person — the one with the single base plate, everything connected, the system that moved as a whole — is the most junior person on my team. An associate product designer.
I want to be honest: this surprised all of us. In daily work, junior designers are often in execution mode — responding to briefs, implementing feedback, building what they're directed to build. The structure of the job doesn't always create space for the quality of thinking they actually have.
The LEGO exercise created that space. And what it revealed was a mind that thinks in systems before it thinks in screens. That thinks about integrity first — how does this hold together, what happens if you move it, what are the dependencies — before thinking about aesthetics or story.
That's a rare quality. And I would not have known it was there from a design review.
The Constraint That Changed Everything
Round two: merge everything into one system. Use all the bricks. Twenty minutes.
The room changed immediately. Not panic — but a visible shift. The constraint of using every brick felt impossible when four people had built in completely different directions, with completely different logics. And the frustration surfaced quickly: why hadn't I said from the beginning that they'd need to combine?
I let them sit with that for a moment.
Then the junior designer looked at the pile of bricks from four different models — all the overlapping pieces, the redundant parts, the elements that didn't fit each other's logic — and said something I've thought about many times since:
"I can't use all of this. Some of it is just noise. But in a disaster, there's always going to be debris. That's the context. We're not designing for clarity. We're designing for chaos."
The room went quiet. Then it went to work.
What Collaboration Actually Looks Like Under Pressure
Three of the four aligned relatively quickly — there was shared logic they could build toward. The fourth, the person whose model had been all story and atmosphere, struggled to find their place in the merged structure. Their instinct was to contribute narrative — to make the combined model feel like something. But the group needed architecture first.
The tension wasn't about ego. It was about incompatible modes. The storyteller and the systems builder were both bringing real value. They just couldn't yet speak the same language fast enough.
What eventually happened: the junior designer listened, asked questions, and found the part of the storyteller's model that was actually the strongest element on the table — the spatial logic of how information moves through the scenario — and built it into the centre of the combined system. No one's thinking was wasted. But it required someone to actively translate between modes.
The final model was organised but not self-explanatory. If you walked into the room and looked at it without anyone presenting it to you, you would see neat arrangement. You would not see a system. The bricks couldn't speak for themselves. That turned out to be its own lesson.
The Baton Pass
The presentation format was structured as a baton pass. Each person owned one part of the S3 structure — Scenario, Science, Solution — and had to begin exactly where the previous person stopped. No recap. No overlap.
The fourth person went first. The storyteller.
And within thirty seconds, the baton dropped.
Not because they didn't have things to say — they had too many. They tried to tell the whole story in the Scenario section. They circled back to things already covered. They couldn't hold themselves to just one part of the structure, because the S3 method requires you to trust that the other sections will carry what yours can't. That trust is hard when your instinct is to carry everything yourself.
The room noticed. There was a pause — the kind that happens when everyone realises something has gone off track but nobody quite knows how to name it yet.
We debriefed it openly. Not as a failure but as data. The same instinct that made the storyteller's individual model atmospheric and evocative was the instinct that broke the baton pass. Strength and weakness living in the same place.
The Remove-a-Part Question
After the presentation, I asked them to do one more thing: identify the single most important piece in their combined model and physically remove it. Then answer: what breaks immediately if this part disappears?
This was where the session hit its deepest point.
Because the combined model was organised but not self-explanatory, identifying the critical piece required the team to do something they hadn't fully done during the build: articulate the logic of dependency. What does this element support? What relies on it? If it's gone, what else fails?
The answers revealed hidden assumptions every system carries. Things that had been built in as given — specific pieces of infrastructure, specific decision points — that nobody had explicitly designed, but that everything else was quietly resting on.
Identifying these in a LEGO model takes five minutes. Identifying them in a live product, after the client has already found them, takes months.
What the Room Said Afterwards
In the group reflection, someone said it felt eye-opening — that they hadn't understood how much a small element could matter to an entire system until they'd physically held it and then removed it.
Someone else said they were surprised how much harder the presentation had been than the building. They'd assumed that once the model existed, describing it would be straightforward. What they found was that the model was only as good as the story you could tell about it. A system that can't be explained isn't really a system. It's an object.
That insight — that building and communicating are two different skills, both necessary, neither sufficient without the other — was the real outcome of the session.
What I Learned About My Team
I knew this team. I'd worked with them, reviewed their work, given them feedback for months. I thought I understood where their strengths and gaps were.
The workshop showed me I was partially wrong.
The junior designer who thinks in systems. The storyteller who needs structural scaffolding to channel their instinct. The person who builds two careful sub-systems because they respect complexity. The person whose spatial logic, once translated, was the most useful element in the merged model.
None of this was fully visible in design reviews. Reviews show you the output. Activities show you the thinking behind it.
I came out of that session with a clearer picture of what each person needed — not what they said they needed, not what their job title suggested they needed, but what the fifteen minutes of building alone and twenty minutes of merging under pressure had made visible.
That's what workshops are actually for. Not training. Revelation.
For the Leader Thinking About This
You don't need a training budget or a formal programme. You need a problem worth solving, a physical constraint that forces real choices, and the willingness to let the room be uncomfortable long enough for the real thinking to surface.
The panic when all the bricks need to merge — that's not a design flaw in the exercise. That's the lesson. Design for chaos, not for clarity.
And find the person in your room who already knows the difference. They might not be who you expect.