Sphere Partners
From Twin to Decision: Simulating a Reorg Before You Run It

From Twin to Decision: Simulating a Reorg Before You Run It

The most valuable thing a model of your organization can do is let you ask 'what if' before you commit. A twin lets you simulate a reorg, a system retirement, or a key departure against how work actually flows — and see what breaks.

4 min read
In this article

Big organizational decisions — a reorg, retiring a legacy system, losing a critical person — are usually made on intuition and discovered to be wrong in hindsight. A model of how your organization actually works changes that. You can run the change against the twin first and see what breaks, where the load lands, and what depends on the thing you're about to remove — before you commit anyone to it.

Why big decisions are made half-blind

When a leadership team decides to reorganize or decommission a system, they're reasoning about a system too complex to hold in one head. The second-order effects — the process that quietly depended on the team you're splitting, the integration that dies with the app you're retiring — are exactly the ones that don't surface in the meeting. So the decision gets made on a simplified mental model, and the surprises arrive during execution, when they're expensive to fix.

A model you can ask "what if"

Because the twin represents the organization as a graph of real dependencies, you can pose a change to it and trace the consequences. Remove a node — a person, a system, a team — and the model shows what loses its connection. Reroute a process and the model shows where the load moves. It's not a crystal ball, but it's a way to make the second-order effects visible before they're consequential, which is most of what 'due diligence' on an org change should mean.

What actually matters

The question isn't 'what do we want to change' — it's 'what breaks when we do.' A twin lets you ask that before you find out the hard way.

Three decisions the twin de-risks

  • A reorg — see which processes cross the boundaries you're about to draw, so you don't sever a dependency the chart never showed.

  • A system retirement — see everything that depends on the application before you turn it off, including the integrations and processes nobody remembers built on it.

  • A key departure — see what a high-centrality person's exit would disconnect, so you can shore it up in advance rather than scramble after.

From insight to a defensible decision

Simulating against the twin doesn't make the decision for you — judgment still belongs to leadership. What it does is make the decision defensible: you can show what you checked, what the model predicted, and what you did to mitigate the risks it surfaced. That's a stronger position than 'we thought it would be fine,' both for making the call well and for explaining it afterward if it's questioned.

The honest limit of simulation

A twin simulates what it can model — the dependencies that flow through your systems and processes. It won't predict how people will feel about a reorg or how a market will react, and it shouldn't pretend to. Its contribution is bounded and real: the structural consequences of a structural change, made visible in advance. That's a genuinely valuable slice of the decision, not the whole of it, and treating it as the whole would be its own mistake.

Frequently asked questions

No — it's a way to see the structural consequences of a structural change before you make it. It shows what depends on what, so removing or rerouting something reveals what loses its connection. It won't predict human reactions or market effects; it makes the second-order dependency effects visible, which is the part intuition usually misses.

Structural ones the twin can model: a reorg (which processes cross new boundaries), a system retirement (what depends on the app), or a key departure (what a high-centrality exit would disconnect). The common thread is tracing dependencies through the organization graph.

No — judgment stays with leadership. It makes the decision better-informed and more defensible by showing what you checked and what the model predicted, so you can mitigate surfaced risks in advance and explain the call if it's later questioned.

Anything outside the structural dependencies it models — how people will react, how a market will move, or effects that flow entirely off-system. It de-risks the structural side of a decision, which is a real and valuable slice, not the entire decision.

Run the change before you run it. See how simulating a reorg, a system retirement, or a key departure against the Enterprise Twin reveals what breaks — before anyone's committed to it. Book a walkthrough.

We'd love to hear from you!

Please provide your contact details, and our team will get back to you promptly.