submove / behavioral simulation / reaction to a reorg
How will your team react to a reorg or manager change? Rehearse it first
Last updated: June 2026
To see how your team is likely to react to a reorganization or a new manager, you rehearse the change before you make it: model the team as pseudonymized, role-coded profiles inside its real reporting network, then play the specific change forward. The model projects banded shifts in engagement, trust, load, and delivery for that scenario, and where in the structure they concentrate.
Most organizations learn the human cost of a reorg afterward, from attrition, missed delivery, and the quiet things people stop saying. A behavioral simulation lets you rehearse the change while the decision is still on the table. This is the people-change version of the broader category explained in what is a behavioral simulation engine.
Why reorgs and manager changes are hard to read in advance
A reorg does not land on a list of names. It lands on a network. When reporting lines move, the load shows up not only on the roles that moved but on every role that depended on them, and a new manager resets trust that took years to build, so delivery can dip even when the change is objectively reasonable.
That is why intuition and headcount math misjudge the reaction. They count who is affected; they do not trace how the effect spreads. The positions that carry the most load are often one step removed from the change itself, and they are exactly the ones a flat plan misses.
How to see the likely reaction before you commit
The method is to rehearse the specific change against a model of your actual team, the same way a pilot rehearses a storm in a simulator before flying through it. With submove that runs as a focused engagement in four steps.
- Frame the change precisely. Name exactly what moves, which teams merge, who the new manager is over, what the new reporting lines are, so the simulation aims at a real decision.
- Build the model. Represent the affected team as pseudonymized, governed, role-coded profiles inside your real reporting and collaboration network. Names and direct identifiers are masked before anything reaches the engine, and the profiles are handled as personal data under our privacy notice.
- Run the change forward. Play the reorg or manager change through the network many times, producing banded trajectories — ranges, not point estimates — for engagement, trust, load, and delivery under that scenario.
- Read the cockpit together. Interpret where the load concentrates and how it ripples, then translate that into how you might sequence, soften, or rethink the change.
A worked example: a new manager over an existing team
Suppose you are moving a high-performing team under a new manager as part of a restructure. On paper it is clean: same people, same work, one new leader. The question that decides whether it works is not on paper.
Played forward, a manager change typically projects a trust reset in the first weeks, not a collapse, but a dip that has to be rebuilt deliberately. The model tends to surface that the load lands hardest not on the most visible roles but on the positions that quietly held the most dependencies under the old manager, because informal authority does not transfer automatically. It also shows where a second, simultaneous change, say a tooling or process shift, would compound the dip rather than add to it linearly.
None of that names an individual or makes a claim about a single person's future. It is a structured read of where the plan places the most load, early enough to do something about it: stagger the changes, brief the new manager on where dependencies actually sit, and move load off the positions the model projects as quietly carrying the most.
Seeing the likely trajectory while a decision is still reversible changes what you can do about it.
What you can do with the read
- Sequence the rollout. Order the moves so the load does not all land in the same week or on the same roles.
- Soften the hard parts. Add support exactly where the model projects the load peaking first, instead of spreading effort evenly.
- Brief the new manager. Show where the real dependencies sit, so trust is rebuilt where it actually matters.
- Rethink the change. Sometimes the most valuable outcome is deciding to do it differently, or not yet.
Simulation or a survey?
A survey measures how the team feels now and cannot tell you how they will respond to a change you have not made, and asking can itself signal the change too early. A simulation rehearses the response privately, before anything is announced. They answer different questions and are strongest together.
For the full comparison, see behavioral simulation vs surveys vs change-management tools.
Frequently asked questions
Can you really know in advance how employees will react to a reorg?
Not person by person — no tool can tell you what one individual will do, and submove does not try. A behavioral simulation plays the specific reorg forward across a model of your team at role resolution and projects banded shifts in engagement, trust, load, and delivery, and where in the structure they concentrate, bounded to that scenario and window. It is calibrated, not validated, so it describes likelihoods rather than certainties.
How do you rehearse a manager change?
Model the team as pseudonymized, role-coded profiles inside its real reporting network, then introduce the manager change and play it forward. The model typically projects a trust reset that rebuilds gradually, and shows where that reset is likely to slow delivery and which roles carry the most of the load — as banded ranges for that scenario, not verdicts about people.
Should you run it before or after the announcement?
Before. The value is that the change is still reversible. Running it before the announcement lets you sequence the rollout, soften the parts likely to land hardest, or rethink the change, rather than reading the damage afterward.
Does submove name or score individuals?
No. submove never names, scores, or ranks a real individual. It uses pseudonymized, governed, role-coded profiles to show where a change places load across the team, and its recommendations attach to the plan, never to a person.
How is this different from just asking the team in a survey?
A survey tells you how the team feels now. It cannot tell you how they will respond to a change you have not made yet, and asking can itself signal the change prematurely. A behavioral simulation rehearses the response in private, before anything is announced.
Rehearse your reorg before you commit
If you are weighing a reorganization or a manager change and want to see how it is likely to land first, you can request a simulation and tell us the situation. Engagements are invitation-only, so we will talk first about whether submove is the right fit.