The Blind Build

Teams of four rebuild a hidden model they are never allowed to see and touch at the same time. It is the cleanest demonstration there is of how much gets lost between the person who knows and the person who does — which is why it survives in facilitation after thirty years.

What it is good for

• CommunicationPractising clear hand-offs, active listening and saying the hard thing early.
• CollaborationWorking a shared problem where no one person holds all the information.
• Problem solvingStructuring an ambiguous problem under a time limit.

What you need

• Identical sets of building bricks, one per team of four
• A pre-built model, hidden from the room
• A screen or a sheet to hide the model behind

The run sheet

1. Build the model and hide it (prep)

   Build something with roughly twenty-five bricks, asymmetric, with at least one piece in a counter-intuitive orientation. Put it on a table in a corner or behind a screen, out of sight of the working tables.

2. Assign roles (3 min)

   Teams of four. One Looker (may go and look at the model, may not touch bricks), one Builder (may touch bricks, may not look at the model), two Runners (may do neither — they carry messages). Roles rotate every five minutes.

3. Round one, no questions (10 min)

   The Looker may describe; the Builder may not ask anything back. One-way communication only. Let this fail.

4. Round two, questions allowed (12 min)

   Open the channel both ways. The difference in build speed is dramatic and makes the point before you say a word.

5. Reveal (5 min)

   Bring the model out. Put it next to each team's attempt. Say nothing while they look.

Facilitator notes

• The temptation is to skip round one. Do not. The contrast is the entire lesson, and teams only feel it if they have suffered the one-way version first.
• Rotating roles every five minutes matters: whoever is Looker when the clock stops gets the credit, and that is worth noticing out loud.
• Watch for the team that invents a vocabulary — 'the blue flat four' — and point it out in the debrief. That is what good handover documentation is.

Debrief questions

Ask these immediately afterwards, not next week. Fifteen minutes of these is what turns the activity into something the team refers back to — see the debrief guide.

1. What changed between round one and round two, in concrete terms?
2. Did your team develop any shorthand? Where does that shorthand already exist in our real work, and where is it missing?
3. Where in our actual process do we have a one-way channel that should be two-way?

Variations