One Trigger, Eight Segments: The Chain Reaction Build in Singapore
In Singapore the chain reaction build is the one corporate format that is sold as a competition and delivered as a dependency, which is why it turns up in briefs for merged departments far more often than in briefs for a normal social afternoon. Local and regional listings put it in a room for two to four hours, hand every team an identical box of dominoes, marbles, string and tape, and ask each team to construct one segment of a Rube Goldberg style machine. At the end the segments are pushed together into a single line and one trigger is released. If every join works, the energy travels from the first domino to the last. If one join fails, everything downstream of it never moves.
That last sentence is the entire activity. Not the machine. The machine is a pretext. What is actually being tested is whether groups that spent three hours competing for the best segment can, in the final ten minutes, hand off cleanly to the people they were competing against. This page is written so an HR or admin lead can specify, run, score and debrief that properly, or brief a supplier precisely enough to stop being sold a craft session with a clever name.
Singapore's chain reaction build, and the structural fact that defines it
A chain reaction build is a construction challenge in which each team builds an independent segment of a single continuous machine, and the segments are joined into one sequence that is set off by one trigger at the end of the session. The published local and regional versions describe a kit of dominoes, marbles, string, tape and paperclips, a build window, a public demonstration, and a combined finale in which all segments run as one.
Singapore listings cluster around a few consistent numbers. Group sizes in published listings run from six people at the low end to a hundred and fifty at the high end, with one facilitator per twenty to forty participants depending on the package tier. Published durations are all over the place and worth reading carefully: some listings publish thirty minutes to an hour, which is the runtime of the build phase only, while others publish a minimum of two hours for brainstorming, designing and testing, with a full sample schedule running from nine in the morning to one in the afternoon. Both are describing the same format. One is quoting the part where people are holding dominoes, and the other is quoting the part where an event actually happens. When you compare two quotes, this is the first thing to reconcile.
Per person rates for facilitated build formats in this market are not usually published on the product page. The published general bands for corporate team building here are $25 to $40 per person for a single facilitated activity run in your own office without food, $45 to $90 per person for a standard half day with a facilitator and light refreshments at an external venue, and $100 to $180 per person for a premium full day with catering and a managed venue. A chain reaction build with supplied kits, facilitators and judging sits in the middle band for most groups. Weekend loading of fifteen to twenty five per cent and public holiday loading of around thirty per cent are published as standard, and bundled catering carries a published markup of thirty to forty per cent.
The format is moderately common here rather than saturated. Roughly three operators in this market list it as a named product, which is unusual: most formats in the corporate catalogue are re-badged by ten different suppliers under ten different invented product names. The relative scarcity is not because the format is weak. It is because it is harder to deliver than a station rotation and it fails in public.
Compete for three hours, then depend absolutely: what makes this format different
Every other team format in the corporate catalogue keeps teams separate from start to finish. In a station rotation, teams never touch each other's work. In a route race, one team's wrong turn costs only that team. In an escape room, the group either opens the door or does not. In each case a team's outcome is a function of that team's own behaviour, and the scoreboard at the end is a list of independent results laid side by side.
The chain reaction build breaks that. For most of the session it behaves exactly like a competitive build: identical kits, identical time, a judged segment, and the natural drift towards making yours the most impressive one in the room. Then in the last ten minutes the structure inverts. The segments are pushed together, the machine becomes one object with one owner, and every team's result becomes a function of every other team's work. A team that built a beautiful segment in position six gets no run at all if the join between segments two and three is a centimetre out of alignment.
This is not a metaphor bolted on afterwards for the debrief. It is a property of the physical object. The energy has to physically travel across an interface that neither team fully owns, and there is no way to score around it. This is why the format is chosen for merged departments, post reorganisation groups, and teams that have just been told they now share a delivery pipeline with people they used to compete with for budget. Those groups already understand competing. What they have not yet learned is that a handover they both treat as the other side's problem will fail, and that when it fails the cost lands on people who did nothing wrong.
Two specific behaviours fall out of the structure, and they are the reason to run this rather than something easier:
Local optimisation stops paying. A team can make its own segment more spectacular by making it more sensitive, and sensitivity at the join is exactly what kills the run. The team that understands this first usually starts trading margin for reliability at around the halfway mark, and you can watch it happen.
Ownership of shared work becomes visible. The join between segment three and segment four belongs to two teams, which in practice means it belongs to nobody unless someone claims it. Whether anyone claims it, and who, is the single most useful observation you will take out of the room.
Running it end to end, from the first brief to the single trigger
This is the run order for a self organised chain reaction build. It assumes you have already chosen your segment count and your table run, both covered further down.
Lay out and number the table run before anyone enters. Physically mark segment boundaries with tape on the tables and a numbered card at each station. Teams must be able to see, from the first minute, that they are building into a fixed physical slot with a neighbour on each side.
Brief the whole room once, together, for fifteen minutes. Cover the shape of the day, the fact that all segments will be joined and run as one at the end, the scoring scheme, the safety rules, and the interface standard. Do not let anyone start building before the interface standard has been agreed, because retrofitting it later costs an hour.
Run the interface negotiation as a separate timed block of ten to fifteen minutes. One representative per team, standing at the table run, agreeing how a segment hands over to the next. This is the most important quarter of an hour in the session and it is the part almost every in house version skips. The method is set out in its own section below.
Write the agreed standard on a flipchart and leave it visible for the rest of the day. An interface standard that lives only in the memory of eight representatives is not a standard.
Distribute identical kits and confirm the segment assignments. Identical kits matter. If one team has more dominoes than another, the debrief turns into a conversation about fairness rather than about handovers.
Open the main build window of sixty to a hundred minutes. Teams design, build and test inside their own segment. Announce the remaining time at the halfway point, at thirty minutes, at ten minutes and at two minutes, because build teams lose the clock completely.
Close the build and open the join window. This is a distinct, announced phase. Building inside a segment stops. Adjacent teams now work together on their shared boundaries. Give this fifteen to twenty five minutes, and see the section below on whether they are allowed to test those joins.
Freeze the machine. Hands off. Nothing is touched from this point except by a facilitator resetting a fallen piece. Announce the freeze clearly, because a hand reaching in to make one last adjustment is the most common cause of a premature trigger.
Walk the line for the segment presentations. Each team gets sixty to ninety seconds at their own segment to explain what it does and what they were worried about. This is worth keeping even when time is tight, because it gives every team a moment of ownership before the shared outcome takes over.
Run the reset and readiness check. A facilitator walks the whole run and confirms each segment is in its start state. Each team lead confirms out loud that their segment is ready. The verbal confirmation matters, because it makes readiness a claim someone made rather than an assumption everyone held.
Release the trigger. One person, usually the most senior person in the room or someone the room nominates, sets off the first element. Film it. Nobody speaks.
Record where it stopped, if it stopped. If the run breaks, name the point precisely and out loud: inside a segment, or at a join, and which one. Do not skip this and do not soften it. The location of the break is data the debrief needs.
Run the repair window and the second attempt. Covered in the scoring section below. Almost every organiser should plan for more than one attempt.
Debrief within fifteen minutes of the final run, in the room, before anyone leaves.
The handover interface, and why the failure is almost never inside a segment
Here is the observation that should drive your whole design. In a well run session, segments themselves rarely fail. A team spends ninety minutes testing its own eight elements and will have run them successfully a dozen times before the freeze. What almost nobody tests a dozen times is the boundary, because the boundary is not theirs.
The interface is the specification of how energy leaves one segment and enters the next. Left unspecified, it produces this exact conversation at minute one hundred and five: team three's segment ends with a marble rolling off a ramp at table height, and team four's segment begins with a domino that needs to be pushed horizontally at table level, and the marble arrives travelling downward with almost no forward momentum, and it is now nineteen minutes to the freeze.
An interface specification has four parts, and a usable standard names all four.
The physical handover point. Where, exactly, the energy crosses. The cleanest version is a marked zone of fixed width, say fifteen centimetres, straddling the tape line between segments, into which the outgoing team must deliver and out of which the incoming team must receive. Neither team may build permanent structure inside the zone during the main build window. It exists so both teams have somewhere to work in the join window.
The carrier. What physically crosses the boundary. A rolling marble, a falling domino, a released weight on a string, a tipped cup. Standardising the carrier is the single highest value decision available to you, and the usual choice is a marble of an agreed size, because a marble is easy to deliver, easy to receive, and forgiving about exactly where it arrives.
The state at the boundary. Height above the table, direction of travel, and roughly how much energy. A workable formulation: the marble arrives at table level, travelling forward, with enough momentum to roll thirty centimetres on a flat surface. That last clause is what stops a team handing over a marble that technically crosses the line and then stops dead.
The receiving obligation. What the incoming team must guarantee. The strongest version is a stated catchment: the receiving team must accept the carrier anywhere inside the marked zone, not only at a single point. This one clause removes most of the alignment failures, because it moves the burden from precision to tolerance.
Specify it too tightly and you have removed the exercise
There is a genuine tension here and you should resolve it deliberately rather than by accident.
If the facilitator issues the complete interface standard as a rule in the opening brief, down to the height, the carrier and the tolerance, the machine will very probably work. It will also have taught nobody anything, because the hardest problem in the room was solved by an authority figure before anyone had to negotiate with a peer. What you have run is a craft afternoon with a satisfying ending. Groups enjoy it. It changes nothing.
If the facilitator says nothing at all about interfaces and lets teams discover the problem, the run will fail, usually at the first or second join, and usually in a way that feels arbitrary rather than instructive. Worse, the failure will be discovered with twenty minutes left, which is not enough time to fix anything, so the lesson lands as frustration rather than as insight.
The resolution is to mandate the process and leave the content to the teams. Say this in the brief, in these terms:
The teams must agree an interface standard. This is not optional and there is a timed block for it.
The standard must cover the handover point, the carrier, the state at the boundary and the receiving obligation. Name these four headings. Do not fill them in.
The agreed standard is written up and is binding on everyone.
The facilitator will not arbitrate. If the standard turns out to be ambiguous at minute one hundred, that is the teams' problem to solve with each other.
That structure keeps the difficult part where it belongs. The teams still have to decide whether a marble or a domino crosses the line, still have to discover that "the marble arrives at the edge" is not a specification, and still have to find out whether anyone will speak up for a tolerance that helps their neighbour more than it helps them. What they are protected from is failing because nobody thought of the question at all.
A useful facilitator intervention, if the negotiation is going badly, is one question asked out loud and then dropped: "Who is responsible if the marble arrives but does not trigger anything?" Ask it, do not answer it, and walk away.
Build clock, test clock, and whether neighbours may rehearse the join
Three separate clocks, and organisers routinely publish only the first.
Build time. Sixty to a hundred minutes for the main build window. Below sixty minutes teams produce three dominoes and a cup and the machine is trivial. Above a hundred and twenty minutes the room saturates: teams stop improving and start fiddling, and fiddling immediately before a freeze makes things less reliable, not more. Ninety minutes is the number to reach for with eight segments of five people.
In segment test time. Not a separate block. It happens continuously inside the build window and it is what teams should be spending at least the last third of it doing. State this explicitly in the brief, because the natural instinct is to keep adding elements until the whistle. A useful instruction: from the two thirds mark, no new elements, only repeated end to end runs of your own segment.
Join time. Fifteen to twenty five minutes as its own announced phase, after building inside segments has stopped. Adjacent teams work the boundaries. This is where the day is won or lost and it should never be the ten minutes you have left over.
The rule you have to decide before the day
May a team test its join with its neighbour before the final run?
There are three defensible answers and they produce genuinely different events.
Full rehearsal allowed. Adjacent pairs may run their boundary as many times as they like during the join window. Success rate goes up sharply. The lesson shifts from "what happens when you never test the handover" to "how do you organise the testing of a handover", which is a legitimate and arguably more useful lesson for a group whose real work involves scheduled integration. This is the right default for most corporate groups, and it is what a working software or operations team would recognise as their own reality.
One rehearsal each. Each join may be tested exactly once. Teams have to decide what to spend that single test on and what to leave to faith. This produces the sharpest conversations of the three, because a single test is not enough to be confident, and teams discover that they have to reason about the join rather than just try it repeatedly.
No rehearsal at all. Segments are built independently to the written standard and joined only at the freeze. The first time energy crosses a boundary is the live run. This is the version that most reliably fails, and it makes the strongest possible point about integration debt. Run it only if you are prepared to own the outcome, only with a group that can take it, and only with the repair window and second attempt described in the scoring section already promised in the brief.
Whatever you choose, publish it in the opening brief. The one thing you must not do is stay silent and then decide at minute ninety, because a group that assumed rehearsal was allowed and finds out it was not will read that as a trick, and you lose the room.
Total session length
Fifteen minutes brief, fifteen minutes interface negotiation, ninety minutes build, twenty minutes join, ten minutes presentations and reset, five minutes for the run, fifteen minutes for a repair window and a second attempt, fifteen minutes debrief. That is three hours and five minutes with no break and no buffer, so publish three and a half hours and take a ten minute break at the end of the build window. Published listings that quote thirty minutes to an hour are describing the build phase alone.
Headcount, segment count, and how the two numbers pin each other down
The design variable is the segment count, and everything else follows from it.
Team size. Four to six people per segment. Five is the right default. Below four, a segment has no spare pair of hands during the join window, which is precisely when you need someone free to walk to the neighbour's table. Above six, a metre of table cannot physically accommodate everyone and two people end up watching for ninety minutes.
Segment count. Five to ten. Below five segments the chain is too short for the dependency to bite, and the whole point of the format is lost. Above ten, the compound reliability problem in the next section makes success improbable enough that you are running a demonstration of futility. Eight is the number that most clearly produces the intended experience, and it is the number the arithmetic below uses.
Total headcount. Five segments of four is twenty people at the low end. Eight segments of five is forty, which is the sweet spot. Ten segments of six is sixty, which is the practical ceiling for one table run and one facilitator team. Published listings go to a hundred and fifty, and above roughly sixty this must mean either multiple parallel machines, which quietly removes the shared dependency, or a very long table run with several facilitators. Ask which, because the two are not the same product.
How to split. Split across departments, deliberately, before the day. The format's value comes from the joins, so put the people whose real world handovers are broken on either side of a boundary and let them negotiate an interface in a room where the consequence is a marble rather than a quarter. That single act of casting is worth more than any amount of facilitation. Announce teams and segment numbers by printed list at the door.
Roles inside a segment. Nominate two roles explicitly and require every team to fill them. A build lead, who owns what happens inside the segment, and a join owner, who owns the boundary with the neighbour on one nominated side and is expected to spend time at someone else's table. Making the join owner a named person, in advance, is the most effective single intervention available to an organiser, and it is worth deliberately withholding it if the whole purpose of your session is to show a group what happens when nobody owns the boundary.
The kit list, and what one team's box realistically costs
Everything below is per team. Multiply by the segment count.
The core kit:
Dominoes, 100 to 200 per team. The workhorse. Wooden toppling dominoes, not the pipped game set, which is too thick and too few. Published retail for a 1,000 piece toppling set is roughly $25 to $45, which spreads across five to eight teams.
Marbles, 20 to 30 per team, of two or three sizes. Standardise the interface marble size across the room. Retail bags run about $3 to $8.
Ramps and channels. Foam pipe insulation split lengthwise is the best value ramp material available, around $2 to $5 a length at a hardware shop. Rigid plastic curtain track, cut cardboard tubes and split PVC also work. Allow three to five lengths per team.
Paper or plastic cups, 20 to 30. For cascades, weights, catchments and levers. Around $2 to $4 a sleeve.
String or twine, 5 to 10 metres. For pulls, releases and pendulums. Around $2 to $4 a roll.
Masking tape, one to two rolls. Masking tape rather than clear tape, because it releases from tables and does not leave residue. Around $2 to $4 a roll. Some venues will ban tape on their furniture entirely, which you must check.
Small weights. Metal washers, coins, sealed water bottles. Often free from what is already in the office.
Blocks and books. For height. Also usually free.
Scissors, one pair. Around $2.
Rulers or straight edges, two. Doubles as a ramp. Around $2.
A realistic kit cost per team is $45 to $90 if you buy everything new at local retail, with dominoes and ramp material accounting for most of it. Buying at the eight team scale brings it down, because the big items divide: eight teams of 125 dominoes each is one 1,000 piece set. A full eight team, forty person build can be equipped for roughly $350 to $650 in materials, and almost all of it is reusable across future sessions if you store it properly. That is the number worth holding in your head when you read a facilitated quote, because it tells you exactly what you are paying for: the facilitation, the judging, the venue and the setup labour, not the dominoes.
Optional additions that materially improve the machine: a few toy cars, mousetraps for a snap release, balloons, small dowels, elastic bands, magnets. Add these only if you also add time, because a richer kit lengthens the design phase.
Things to ban outright: liquids, anything that burns, anything that shatters, and any element whose failure mode is a mess someone else has to clean. Also ban glue in most rooms, because it destroys venue furniture and it makes the build permanent, which removes the ability to adjust.
Table run, floor and the vibration problem nobody quotes for
The physical requirements are the reason this format cannot simply be dropped into any function room, and they are almost never in a quotation.
The table run is the binding constraint. You need one continuous line of tables, or a small number of connected lines, with roughly one and a half to two and a half metres of table per segment. Eight segments therefore needs twelve to twenty metres of continuous run. A standard trestle table is about 1.8 metres, so budget eight to twelve tables. A single straight twenty metre line is rare in a Singapore function room, so plan an L shape or a U shape, and put a join at the corner deliberately rather than by accident, because a corner join is the hardest one in the room and should be given to a team that can take it.
Table height must match across the run. Two tables that differ by three centimetres create a step at exactly the point where a marble is meant to cross. Walk the whole run with a straight edge before anyone arrives. Where a mismatch is unavoidable, tape a folded card ramp across it yourself and tell the affected teams it is there.
Tables must be stable, and this is the requirement people underestimate. Folding trestle tables flex. A person leaning on the far end of a 1.8 metre trestle will move the surface enough to topple a standing domino two metres away. Test it: set up ten dominoes, then lean on the table end, and see what happens. If the tables flex badly, the fixes are to lock the legs, to pair the tables back to back for rigidity, to place a rigid board on top of the run, or to accept it and tell teams to design with a lower centre of gravity.
Floor surface matters as much as the tables. A suspended floor, a raised access floor, or a mezzanine will transmit footsteps into the tables. Forty people shifting their weight during the reset countdown is enough vibration to drop a marginal domino. On a concrete slab this is a non issue. If you are on a suspended floor, mark a standing line half a metre back from the tables and enforce it during the run, and instruct people not to walk during the countdown.
Other physical requirements:
Air conditioning vents and ceiling fans. A vent blowing directly onto a table run will move a paper cup and a light domino. Identify the vents before you place the tables and ask the venue to shut or redirect the ones over your run.
Doors. A door opening into the room creates a pressure pulse. Put a sign on it and post someone there during the run.
Circulation space. At least one and a half metres of clear floor on both sides of the table run, because teams have to reach their neighbour's boundary and forty people need to be able to walk the line during the presentations without brushing the tables.
Light. Bright, even, from above. People are placing millimetre alignments and a dim function room makes that harder than it needs to be.
Power and a camera position. Film the run from a fixed position at table height and a second one from above if you can. The footage is genuinely useful in the debrief, and it is the only record of exactly where the run stopped.
Venue cost. Published function room hire in this market runs roughly $40 to $250 per hour depending on size and address, with three hour minimums common, and published planning guidance of thirty to forty square feet per person for a seated function. For this format the seated figure understates it, because a table run plus circulation needs more floor per person than a banquet does. Your own office boardroom or training room, if it has enough continuous table, costs nothing and is very often the better choice.
Eight segments at ninety per cent: the arithmetic that should change your brief
This is the section to read to the room before the build starts, and it is the intellectual core of the whole format.
Segments in a chain reaction machine are in series. Every one must work for the run to complete. So the probability of a complete run is the product of the individual segment probabilities, not the average of them.
Take a chain of eight segments, each independently ninety per cent reliable. Ninety per cent sounds good. It is the number a team gives you when their segment worked nine times out of the last ten tries, and they will say it with confidence.
The chance of a complete run is 0.9 multiplied by itself eight times.
0.9 to the power of 8 is 0.430, which is 43 per cent.
Eight segments, every one of them working nine times out of ten, and the machine completes less than half the time. Write that on the flipchart.
The rest of the table is worse and better in instructive ways:
Five segments at ninety per cent: 0.9 to the power of 5 is 0.590, so 59 per cent.
Eight segments at ninety per cent: 43 per cent.
Ten segments at ninety per cent: 0.9 to the power of 10 is 0.349, so 35 per cent.
Twelve segments at ninety per cent: 0.282, so 28 per cent.
Eight segments at eighty per cent: 0.8 to the power of 8 is 0.168, so 17 per cent. A one in six chance.
Eight segments at ninety five per cent: 0.95 to the power of 8 is 0.663, so 66 per cent.
Eight segments at ninety nine per cent: 0.99 to the power of 8 is 0.923, so 92 per cent.
Run the calculation in the other direction and the point lands harder. If you want a nine in ten chance that an eight segment machine completes, each segment has to be reliable to the eighth root of 0.9, which is 0.9869. Every segment must work 98.7 times out of a hundred. Not nine times out of ten. Ninety nine times out of a hundred.
Now apply it to the joins. If you count each of the seven joins as its own element in the series, an eight segment machine has fifteen things that must work, not eight. Fifteen elements at ninety five per cent each is 0.95 to the power of 15, which is 0.463, so 46 per cent. The joins are where the low probabilities live, because they are the elements nobody has tested twenty times.
What this does to the design brief. It reframes the goal. A team that hears "build the most impressive segment you can" optimises for cleverness, and cleverness in a chain reaction machine means more elements, and more elements in series means lower segment reliability. A segment with twelve elements, each at ninety nine per cent, is only 0.99 to the power of 12, or 89 per cent reliable, which is worse than a boring five element segment where each element is safe.
So the correct brief is not "build something impressive". It is "build something that works, then make it interesting with whatever margin you have left". Most teams do the reverse and only discover the arithmetic when the run stops at segment two.
The lesson is not really about dominoes. Any group that runs a multi stage process, a handover chain, an approvals pipeline or a release train is living inside this same product. Each stage at ninety per cent, eight stages, and the end to end delivery works less than half the time, while every individual stage owner honestly reports that things are going well. That sentence is the whole reason this format is worth three hours.
Marking it so a fragile masterpiece cannot beat a dull machine that works
If you score creativity alone, you get spectacular fragile builds and a failed run. If you score reliability alone, you get eight teams building three dominoes in a row and a boring afternoon. The scoring has to make robustness the dominant term without making ambition worthless.
The recommended scheme
A 100 point scale per team, weighted like this:
Own segment completion in the live run: 40 points. All or nothing. Your segment either passed the energy through or it did not. This is the largest single term and it must be, because it is the one that makes reliability the priority.
Join into the next segment: 20 points, awarded to both adjoining teams. The join between segments three and four earns twenty points for team three and twenty points for team four, or zero for both. This is the clause that does the real work. It makes a shared boundary a shared score, so a team cannot protect its own total by treating its neighbour's problem as their own affair. It is also the single most quoted rule in the debrief.
Whole machine completion: 20 points, awarded to every team or to nobody. A collective term. It cannot be won by any team alone and it cannot be lost by any team alone.
Design and ingenuity: 15 points, judged. Element count, use of the kit, elegance, a moment that makes the room laugh. Judged by a panel, announced before the build so teams know what is being rewarded.
Presentation: 5 points, judged. The sixty second explanation at the table.
Ingenuity is therefore fifteen per cent of the score and reliability terms are eighty per cent. A gorgeous segment that fails scores at most twenty out of a hundred. A plain segment that works, joins on both sides and is part of a complete run scores eighty even before the judges arrive. That ratio is deliberate and it should be published in the opening brief, because scoring only changes behaviour if teams know it in advance.
The variant for a group that needs less competition
Drop the individual terms entirely and score the room as one number: complete run is a hundred, and each segment reached before the failure is worth twelve and a half. The whole room gets the same score. This suits groups where internal competition is already the problem you are trying to fix, and it suits a merged department where a leaderboard would be actively unhelpful. You lose the individual accountability that the forty point term creates, so use it knowingly.
How many attempts
Run more than one. Two attempts minimum, three if the schedule allows. There are two reasons.
The first is arithmetic. If a complete run has a 43 per cent chance, then over three attempts the probability of at least one complete run is one minus 0.57 cubed, which is 0.815, or 81 per cent. Three attempts converts a coin flip into a reasonable expectation, and a room that sees the machine complete once goes home differently from a room that never sees it.
The second is that the repair between attempts is where the best behaviour of the whole session appears. Give a repair window of eight to twelve minutes between attempts. Watch what happens: whether teams whose segments already worked go and help the team that failed, or stand around congratulating themselves. That is the observation you will use in the debrief, and it is worth more than the run itself.
Scoring across attempts. Score the best attempt, not the first, and not the average. Scoring the first attempt punishes teams for a failure they could not have foreseen and makes the repair window pointless. Scoring the best rewards the repair, which is exactly the behaviour you are trying to produce. If you want to preserve the drama of the first run, add a small bonus of five points for completing on attempt one, and no more than that.
One thing not to do: do not let the machine be rebuilt wholesale between attempts. Repair means fixing what failed and re seating what fell. A team that uses the repair window to redesign its segment is not doing the thing you are measuring.
Dialling the challenge up or down without rewriting the format
Change one variable at a time. Each of these is a real dial and they are ordered from easiest to hardest.
Easier. Fewer segments, five instead of eight, which lifts the compound probability from 43 to 59 per cent. Facilitator issues the interface standard rather than requiring teams to negotiate it. Unlimited join rehearsal. A hundred and twenty minute build. Marbles standardised and supplied pre sized. Straight table run with no corners. Three attempts.
Standard. Eight segments. Teams negotiate the interface standard inside a timed block, with the four headings mandated. Unlimited join rehearsal in a twenty minute window. Ninety minute build. One corner in the table run. Two attempts with a repair window.
Hard. Ten segments. Teams negotiate the standard with no headings supplied. One rehearsal per join. Seventy five minute build. A mandatory element that every segment must include, such as a change of direction or a vertical drop. Two attempts.
Brutal, and only for a group that has asked for it. Ten to twelve segments. No join rehearsal at all, so the first time energy crosses a boundary is the live run. Sixty minute build. A mandated minimum of eight elements per segment, which forces the reliability problem into the open. One attempt. Expect a 20 to 30 per cent chance of a complete run and be honest with the room about that number before you start, because a brutal version run without warning is a bad experience, while a brutal version run with the arithmetic on the wall beforehand is a memorable one.
Two additional dials worth knowing about:
The blind segment. One team builds a segment they may not see joined until the freeze, working only to the written standard. Adds a strong specification discipline lesson and is more instructive than making everything harder.
The moving requirement. Announce at the sixty minute mark that the interface standard has changed, for example that the carrier is now a domino rather than a marble. Cruel, realistic, and only for groups where the theme of the day is genuinely change management.
The four ways this collapses, and the intervention for each
The team that over engineers. Symptom: a segment with fifteen elements at minute eighty, still adding, never yet run end to end successfully. This team is optimising for the ingenuity points, which are worth fifteen, and quietly forfeiting the sixty that depend on their segment and their joins working. Intervention: publish the scoring weights in the opening brief, then at the two thirds mark announce a hard element freeze across the room, with only testing and simplification permitted after it. If one team is a serious outlier, ask the build lead a single question: how many times has your segment run end to end without a hand touching it? If the answer is fewer than three, they know what to do.
The team that finishes early and does not help. Symptom: a team is done at minute sixty, sitting down, on their phones, while the team two segments away is in trouble. This is a structural failure, not a character failure, because nothing in the default setup gives them a reason to move. Intervention: the twenty point shared join term, published upfront, gives them a direct financial interest in their immediate neighbours. For the rest of the room, create an explicit and honourable role: announce at the start that any team that finishes early may loan people to any other team, and that loans will be noted by the judges and count towards the ingenuity term. Then actually mention the loans in the results.
The join nobody owns. Symptom: at minute one hundred and ten, the boundary between segments four and five has a gap of eight centimetres, and both teams believe the other one is building into it. This is the defining failure of the format and it will happen unless you design against it. Intervention: name a join owner in every team at the start, with a nominated side, so that every boundary has exactly one person whose name is attached to it. Give the join owners a two minute stand up meeting at the halfway mark, at the table run, where each states out loud the current condition of their boundary. If the point of your session is to demonstrate the failure rather than prevent it, withhold this and be ready to talk about it afterwards.
The premature trigger. Symptom: someone leans across the table at minute one hundred and twelve, catches a domino, and forty dominoes go down in front of the whole room. It is upsetting out of proportion to the actual damage and it can sour a session. Intervention: a hard freeze rule announced clearly and enforced without exception, plus a physical discipline during the build. Ask teams to build in blocks of ten to fifteen dominoes with a deliberate gap, and to place a removable blocker, a ruler or a book, in each gap. When a section falls it costs fifteen dominoes rather than a hundred and fifty. Blockers come out during the readiness check. This one habit saves more sessions than any other piece of advice on this page.
A fifth, less common but worth naming. The team that solves its segment by cheating the interface: ending its segment with a hand placed marble, or a length of ramp that reaches into the neighbour's territory and effectively takes over their first element. It is not usually malicious, it is a team solving its own problem at the boundary. The intervention is the marked zone in the interface standard, and a facilitator who walks the line at minute seventy and points at anything crossing a tape line.
What this genuinely develops, and where it offers nothing
What it produces, reliably:
Cross team interface discipline. This is the primary output and very few corporate formats produce it at all. The mechanism is specific: the teams have to write a specification before they build, discover during the build that their specification was ambiguous, and repair it under time pressure with a peer rather than through a manager. That is the actual shape of the work in any organisation with handovers, and running it in ninety minutes with dominoes lets a group feel the whole loop, including the part where the specification was wrong, in one afternoon rather than over one quarter.
A concrete vocabulary for shared ownership. After a session, "who owns that join" is a phrase a team can use in a real meeting, and it carries the memory of the marble that arrived at the edge of table four and stopped. Formats that leave a group with one usable phrase are doing better than most.
A visceral understanding of series reliability. The arithmetic section is a slide. The run stopping at segment two is an experience. A team that has watched their own successful segment sit there unused because something upstream failed will not need the compound probability explained again.
What it does not do, and you should not sell it as if it does:
It is not an icebreaker. It is slow, quiet and detailed, and it puts strangers into a fiddly technical task where the confident people will dominate the first twenty minutes. If the group has never met, run something loud first and this second.
It does not build trust in the interpersonal sense. It builds interface trust, which is narrower: I believe you will deliver what you said in the shape you said it. That is valuable and it is not the same thing as a group that has been through something together emotionally.
It produces almost no physical energy release. Nobody sweats. If the brief was "get the team out of their heads for an afternoon", this is the wrong format.
It is weak on decision making under uncertainty. The problem is well specified and the constraints are visible, so there is little of the ambiguity that makes decision exercises useful. What it tests is execution and coordination, not judgement.
It can quietly disadvantage some people. Fine motor precision, the ability to kneel or bend over a table for ninety minutes, and good near vision are all genuinely required. Ask about this in the sign up rather than in the room, and create real non building roles: join owner, timekeeper, camera operator, the person who documents the segment for the presentation.
The honest limits: table, time, and the run that dies at segment two
Three constraints that should stop some organisers booking this, and a supplier who does not raise them is not being straight with you.
It needs a long uninterrupted table run. Twelve to twenty metres of continuous, level, stable table for eight segments. Many function rooms in this market cannot provide that in a single line, many hotels will not let you tape their furniture, and a room with pillars in the wrong place forces corner joins that make the whole exercise harder. Check the room with a tape measure and a straight edge before you commit. This constraint alone rules out more venues than any other format in the corporate catalogue.
Three hours is the floor. Under three hours you are cutting either the interface negotiation, the join window or the debrief, and each of those cuts removes the specific thing this format is for. A ninety minute chain reaction build is a craft activity with a nice ending, which is a perfectly reasonable thing to run, but it is not this. Do not let a supplier sell you a sixty minute version and describe it in the language of cross team collaboration. Ask them directly how many minutes are allocated to the joins.
It can genuinely deflate a room. This is the real risk and it is not hypothetical. Forty people spend three hours building, the room goes quiet, the trigger is released, and the machine stops at segment two. Six teams never get to see their own work run. There is a particular silence that follows, and if the session ends there, people go back to their desks having watched their afternoon fail. Compare that with a station rotation, where the worst case is that your team came last, which nobody minds much.
Three mitigations, and you should use all three:
Say the arithmetic out loud before the build. A room that has been told that eight segments at ninety per cent completes 43 per cent of the time has already agreed that failure is a likely outcome, and the failure reads as physics rather than as anyone's fault.
Always plan a repair window and a second attempt, and say so in the opening brief so that the first run is understood as a first attempt rather than as the verdict.
Never end on the failed run. Even if the machine never completes, the last thing that happens in the room must be the debrief, and the debrief must be about what happened at the interfaces rather than about whose segment failed. A session that ends with a good fifteen minute conversation about handovers is a success regardless of whether the last domino fell.
One more limit worth stating: this format punishes a room where the senior person cannot tolerate being on a team that fails in public. If you know that is true of your organisation, either fix the casting or choose something else.
Fifteen minutes on the interfaces: what to actually ask
Do not open with how did everyone find that. Open at the boundary. The whole value of the debrief is that this format produces evidence, and the questions below point at evidence rather than at feelings.
About the interface specification:
When you agreed the standard at the start, what did you leave out, and when did you find out that you had left it out?
Which part of the written standard turned out to mean two different things to two teams?
Did anyone argue for a tolerance that made things easier for a neighbour and harder for themselves? What happened to that argument?
If we ran this again tomorrow, what is the one clause you would add to the standard before anyone touched a domino?
About the joins, which is the core of the session:
Whose job was the join between segments four and five? Say the name out loud.
For the join you were responsible for, how many times did you actually test it, and how confident were you at the freeze? Compare those two answers.
Where did the run stop? Was it inside a segment or at a join? Show of hands: who expected it to stop there?
Was there a boundary that both teams assumed the other one was handling? How long was it in that state before someone noticed?
Who walked to another team's table today without being asked, and what were they going there to do?
About the reliability trade off:
At what point did your team stop making the segment better and start making it safer? What triggered the switch?
Did anyone remove an element they liked because it was not reliable enough? How did that decision get made, and who made it?
Knowing that eight segments at ninety per cent completes 43 per cent of the time, what would you have built differently at minute twenty?
About behaviour after the first attempt:
When the first run failed, what did the teams whose segments had already worked do in the next sixty seconds?
Did anyone go and help the team that failed? If nobody did, what stopped you?
The transfer questions, which are what the exercise is actually for:
Where in our real work is there a join that two teams both assume the other one owns?
Which of our handovers has never been tested end to end, only at each end?
Our own process has stages. If each stage is ninety per cent reliable, what is our end to end number, and who is accountable for it?
What would our version of the written interface standard be, and who would have to agree it?
Question fifteen is the one to end on, and it is worth leaving a long silence after it. A group that names a real join in their own organisation has converted an afternoon of dominoes into something with a follow up action. Write the answer on the flipchart, photograph it, and send it out the next morning.
Alternative names for this build, and the neighbouring formats it is not
The format trades under several generic names in this market. Chain reaction, chain reaction challenge, domino effect, domino challenge, Rube Goldberg machine and Rube Goldberg challenge all describe the same underlying mechanic and are used more or less interchangeably. As with most of the corporate catalogue, individual operators layer their own invented product names on top of these, so the same activity can appear under a name you will not find anywhere else. Judge the mechanic, not the label.
There is one genuine distinction hiding among the names, and it is worth knowing. A pure domino version uses only dominoes and is essentially a large scale toppling display, sometimes with each team building a panel that forms part of a company logo when photographed from above. A full Rube Goldberg version uses mixed materials, changes of energy type and changes of direction. The domino version is faster to build, easier to make reliable and far more photogenic. The Rube Goldberg version is a much better exercise, because a domino run hands over in one way only and mixed materials force a real interface conversation. If a listing shows a photograph of a corporate logo made of coloured dominoes, you are probably looking at the first one.
What it is not:
It is not a station rotation format. In those, teams move between simultaneous scored challenges and never touch each other's work. The design problem there is choosing and weighting stations. Here nobody rotates and the design problem is the boundary between two builds.
It is not a route based race. There is no travel, no clue sequence and no order of visits. Everyone stands at the same table run for three hours.
It is not an elimination format. Nobody is out, no one is removed from play, and the point is that everyone remains in the machine to the end.
It is not a rapid challenge format built from short timed rounds with simple props. That family is about pace and turnover. This one is about a single slow build and one moment.
It is not a construction challenge in the marshmallow and spaghetti sense, even though the kit looks similar. Those score each team's tower independently, so teams never depend on each other. Take the dependency away and you have removed the only thing that makes this format worth its three hours.
Questions to ask a supplier that cut through any product name:
How many segments, and how many people per segment?
Are all segments joined into one machine at the end, or is each team's build judged on its own? If the answer is the second one, this is a different and much easier activity.
How many minutes are scheduled for the joins, as distinct from the build?
Who sets the interface standard, the facilitator or the teams?
May adjacent teams test their join before the final run?
How many attempts are planned, and is there a repair window between them?
How is it scored, and what percentage of the score depends on the whole machine completing?
How much continuous table do you require, and are you bringing tables or using ours?
What happens to the debrief if the run fails at segment two?
Questions four, five and seven are the ones that separate a supplier who understands this format from one who has added it to a catalogue.
PLAYON and this activity, in one line
PLAYON does not run chain reaction builds, and there is no version of this format that fits an indoor attraction floor. If your shortlist also includes a scored, station based competitive afternoon with no setup and no props to buy, PLAYON is a ready made venue for that kind of format, but for this one you want a long table, a quiet room and a supplier who can talk about joins.
Chain reaction build questions that come up before booking
What is a chain reaction build team building activity? It is a build challenge where each team constructs one segment of a single Rube Goldberg style machine, all segments are joined at the end, and one trigger runs the whole line. Every team depends on every other team's segment working.
How many people do you need for a chain reaction build? Twenty to sixty people works best, split into five to ten teams of four to six. Eight teams of five is the ideal shape. Published Singapore listings run from six participants up to a hundred and fifty at the top end.
How long does a chain reaction build take? Three and a half hours is the realistic minimum for a full session. That covers a brief, a timed interface negotiation, a ninety minute build, a join window, two attempts and a debrief. Listings quoting one hour describe the build phase only.
What materials does a chain reaction build need? Dominoes, marbles, ramps made from split foam pipe insulation, paper cups, string, masking tape, small weights and books for height. A realistic new kit costs $45 to $90 per team at local retail, and almost all of it is reusable afterwards.
What is the handover interface, and why does it matter so much? It is the agreed standard for how one segment triggers the next, covering the handover point, the carrier, the state at the boundary and the receiving obligation. Failures almost always happen at joins rather than inside segments, because nobody tests them.
Should teams be allowed to test their join with their neighbour beforehand? Yes for most corporate groups, because it shifts the lesson from never testing a handover to organising the testing of one. Allowing exactly one rehearsal per join produces the sharpest conversations. Banning rehearsal entirely almost guarantees a failed run.
Why does a chain of eight segments fail so often? Because segments are in series, so probabilities multiply. Eight segments at ninety per cent reliability each gives 0.9 to the power of 8, which is 43 per cent. To reach a nine in ten chance overall, every segment must be 98.7 per cent reliable.
How do you score it so a fragile but spectacular build cannot win? Weight reliability at around eighty per cent of the score and creativity at fifteen. Award forty points for your own segment running, twenty for each join shared with a neighbour, twenty for the whole machine completing, and fifteen for design.
Should you run more than one attempt? Yes, two minimum and three if time allows. At 43 per cent per attempt, three attempts gives an 81 per cent chance of at least one complete run. Score the best attempt, and use the repair window between runs as observation material.
What kind of room and tables does it need? Twelve to twenty metres of continuous, level, stable table for eight segments, on a solid floor, with one and a half metres of clear space each side. Flexing trestle tables, suspended floors and air conditioning vents overhead all ruin runs.
Why is this format used for merged teams and reorganisations? Because it makes teams compete during the build and then depend on each other completely at the final run. A segment that fails ends the run for everyone downstream, which mirrors exactly what a broken handover does inside an organisation.
What is the difference between a domino challenge and a Rube Goldberg build? A domino version uses only dominoes and is faster, more reliable and more photogenic. A Rube Goldberg version mixes materials and energy types, which forces a genuine interface conversation between teams and makes it a substantially better exercise.
What does a chain reaction build cost in Singapore? Published general team building bands here run $25 to $40 per person in office, $45 to $90 for a standard half day at an external venue and $100 to $180 for a premium full day. Weekend loading of fifteen to twenty five per cent applies.
What goes wrong most often on the day? The join nobody owns. Two teams each assume the other is building into the shared boundary, and it is discovered with twenty minutes left. Name a join owner in every team at the start, with a nominated side, to prevent it.