Systems thinking: what Dependency Network teaches about dependencies between teams

Why "optimizing your team" doesn't always optimize the company

It's tempting to measure a team's success by its own numbers: Marketing by leads generated, Sales by contracts closed, Operations by tickets resolved. The problem is that none of these teams operates in a vacuum. A spike in leads that Sales doesn't have the capacity to handle isn't a win — it's a bottleneck that just moved somewhere else. That's the essence of systems thinking: understanding that an organization is a network of dependencies, not a collection of independent departments.

Most people get this in the abstract. Very few feel it in their gut, because in day-to-day work everyone is mostly watching their own dashboard. Dependency Network is built specifically to make it felt.

How the game works, specifically

Five interdependent areas are split among the teams playing. Each team sees its own areas in detail, and only a summary of the others — just like in a real company, where you have full visibility into your own team and a rough sense of everyone else's. Each round brings an event (a seasonal demand spike, say), and teams have to allocate a shared pool of people and budget, choose a priority for each area, and lock in a plan.

Once the plan is confirmed, a deterministic simulation — no dice, no arbitrary randomness; the same decisions always produce the same outcome — resolves the flow through the network and updates seven shared variables. The goal is to keep those variables in a healthy range across several consecutive rounds.

The design hinges on one thing: a bottleneck in one area directly slows down the next one. A team that speeds up its own area without coordinating with the teams downstream can win one round and lose the next three, because it created a backlog that takes time to work through.

Asymmetric information within the team itself

Dependency Network adds one more layer: within each team, the Analyst role sees the forecast of future load, while the Area Lead holds the controls to decide where people and budget go — but doesn't see that forecast. That forces a second layer of communication, on top of the one that already exists between teams: the Analyst has to convince the Lead to act ahead of something that isn't visible in the current numbers yet.

It's a fairly faithful replica of a real tension: the person with the forecast isn't always the one who decides, and the person who decides doesn't always trust a projection that "hasn't happened yet."

What a team learns without anyone explaining it

After two or three rounds, almost every group reaches the same conclusion on its own: giving a heads-up before acting is faster than cleaning up afterward. A team that announces "we're about to speed up this area, expect a spike next round" gives the downstream teams time to prepare. A team that speeds up quietly creates surprises that cost more time to fix than the time it saved by moving fast.

That lesson, learned inside the game, carries straight over to how a real team coordinates launches, campaigns, or process changes that touch other departments.

Why systems thinking is hard to teach with a slide deck

You can draw a flowchart of cross-team dependencies in a presentation and have the audience nod politely without anything changing in how they work. Systems thinking is best learned by feeling the delayed consequence of a decision: you make a call in round 2, and the impact doesn't show up until round 4. That lag is exactly what makes systems thinking hard in real work — the cost of this week's decision sometimes only shows up next month — and it's exactly what Dependency Network compresses into a 40-minute session, so it can be seen and discussed right away.

Who gets the most value from it

• Companies where different teams share limited resources (budget, people, infrastructure) and quietly compete for them.
• Leadership teams that make cross-team prioritization calls and want a neutral way to discuss trade-offs.
• Growing organizations, where dependencies between areas aren't well mapped yet and surprises are frequent.

With groups of 4 to 20 people split into 2 to 5 teams, it works equally well for a small leadership group or a cross-departmental training session running several teams in parallel.

Pair it with Crisis Room

If your organization has already identified that decisions made under pressure are a weak spot in addition to cross-team coordination, Crisis Room works that other dimension specifically. Many teams play Dependency Network first to understand the structural dependencies, then move to Crisis Room to practice deciding when time is running out.

A bottleneck in action: an example

Say the team running Marketing decides, without warning anyone, to launch an aggressive campaign to catch a seasonal spike. The demand it generates reaches Sales faster than expected, and Sales doesn't have enough people to handle it in time. Leads that don't get followed up in time go cold, and several rounds later the network's overall conversion metric drops — without any single team having "done something wrong." Nobody coordinated the pace between the team generating demand and the team that has to absorb it. That's essentially the kind of situation Dependency Network makes visible in real time, instead of letting it surface only at quarter close.

How to get started

You can add Dependency Network to your team's next session from the platform. If you'd rather understand the mechanics first without coordinating the whole team, try it solo with bots covering the Lead and Analyst roles with the same level of challenge.