Ripple Effect
A business simulation for cross-functional trust and systems thinking.
Ripple Effect is a business simulation where participants manage companies at separate tables, each with distinct goals and resources. Success requires negotiating with other groups whose objectives don't perfectly align — creating realistic pressure around collaboration.
How It Works
Each table runs its own company with different assets and objectives. Success becomes mathematically impossible without negotiating mutually beneficial arrangements with groups whose goals don't perfectly align with your own.
What Happens in the Room
Tables start confidently. Each group has resources, a brief, and clear goals — for the first 20 minutes, it feels manageable. Then the wall hits. The maths stops working. Local resources can't solve the problem in front of them, and that's the moment the game actually begins.
Someone gets up and walks to another table. That first cross-table contact sets the tone for the whole room. If they go with an open offer, others follow. If they go extracting information without sharing anything, other tables notice and close down. By the midpoint, every table has developed a read on every other table — who can be trusted, who's been evasive, who made a deal and didn't deliver.
Late in the game, alliances get tested. Resource pressure increases, and partnerships that felt solid start bending. Some hold. Some don't. The facilitator watches who breaks agreements quietly and who does it openly, and whether the room catches it in real time.
What It Reveals
The game exposes how people navigate tensions between local team success and broader organisational goals. Specifically:
- Who initiates cross-table contact first — and whether they frame it as an offer or a request. Groups that wait to be approached rarely secure the best deals.
- The negotiator who treats every exchange as win-lose, pushing for maximum advantage on each trade, and then wonders why no one wants to deal with them in round 3.
- Teams that use information as leverage — drip-feeding data to maintain advantage — versus teams that share openly and build faster trust.
- The leader who defaults to internal optimisation: "let's fix our own house first" — while other tables are already trading and pulling ahead.
- Whether groups see other tables as competitors or trading partners, even when stated objectives require cooperation. This maps directly to how business units actually behave in organisations.
- Who adapts when an alliance breaks, and who gets stuck relitigating the betrayal instead of finding a new path.
When to Bring This In
- Post-merger or acquisition, when newly combined teams are formally integrated but haven't built working trust yet — especially when they were previously competing for the same resources or customers.
- Breaking silos between functions that are supposed to be interdependent but operate independently — sales and delivery, product and engineering, operations and commercial.
- Large leadership cohorts drawn from different business units who need to develop a shared operating model and will actually work together after the programme ends.
- Organisations where collaboration is the stated value but the incentive structure rewards individual or team-level numbers — the game makes that contradiction visible without anyone having to say it out loud.
When This Isn't the Right Fit
- Groups smaller than 12. You need at least three functional tables for the cross-group dynamics to develop properly. Fewer than that and it becomes a small-group exercise, not a systems experience.
- When the real problem is one damaged relationship between two specific people or teams. This game surfaces systemic patterns — it won't repair a targeted interpersonal conflict and trying to use it that way can make things worse.
- Senior leaders who are already genuine cross-functional collaborators. The game will confirm what they already know and practise. Better to bring it to cohorts who haven't yet had to depend on peers outside their function.
Who It's For
Organisations where cross-functional collaboration is genuinely challenging. Works particularly well for:
- Leadership teams from different functions
- Enterprise leadership programmes
- Groups needing to break down silos
Especially effective when paired with organisational data about collaboration breakdowns.
What Happens in the Room
Tables start confidently. Each group manages their company, allocates resources, and builds an internal plan. Within 30 minutes they hit a wall — their resources can't solve their problem alone. The first cross-table approach is always awkward. Some groups wait to be approached. Some initiate immediately and set the tone for the room.
By the midpoint, alliances are forming. Some openly, some quietly. The groups that made early, generous proposals are trading from a position of strength. The groups that played defensively are scrambling. In the final phase, alliances either hold or fracture under resource pressure — and the difference is almost always traceable to decisions made in round one.
Specific Patterns That Surface
- The team that builds a detailed internal plan while other tables have already started negotiating — arrives at the table late and from a weaker position
- The negotiator who frames every proposal as win-win in language but structures the deal as win-lose in terms — visible only in hindsight
- The leader who controls all outbound communication from their table — information bottleneck that slows the whole group
- The group that treats other tables as competitors even when the game mechanics require cooperation — and pays for it in the final round
- The individual who initiates the first cross-table contact and reframes the whole room's strategy within 20 minutes
When to Bring This In
- Post-merger or post-restructure — two teams now interdependent but without established working patterns
- Functions that formally collaborate but operationally operate as silos (sales and operations, product and engineering, corporate and regional)
- Large leadership cohorts where the goal is building cross-BU relationships alongside the development programme
- Organisations where "we need better collaboration" keeps appearing in engagement surveys but no one can name the specific behaviour to change
When This Isn't the Right Fit
- Groups smaller than 12 — not enough table dynamics to generate meaningful patterns
- When the real problem is one specific toxic relationship rather than a systemic cross-functional issue — the game will surface patterns, not resolve a targeted conflict
- Senior teams that are already strong collaborators — the game confirms what they know rather than revealing anything new
The Debrief
Every session ends with an EPPA debrief: Experience, Patterns, Principles, Application. Participants don't leave with general reflections — they leave with a named behaviour to change and a specific situation to apply it in. The debrief is facilitated by the same person who ran the game. That continuity is what makes the insight land.