How to plan a reorg without breaking your team

A reorganization is a set of changes to who reports to whom, which teams exist, and what all of that costs. Planning one well means being able to answer three questions before anyone hears a rumour: what exactly changes, what it costs, and when each part happens. Here is a sequence that keeps those answers honest from the first sketch to the day it goes live.

Start from the structure you actually have

Every reorg plan is a diff against today, so the first job is a faithful picture of today: every team, every position (filled or open), every reporting line, and who sits where. Pull it from the HR system or a CSV rather than from memory, and check it with the managers who own each branch. Then freeze it. In Resorcerer that means protecting the model of your real organization: nobody can edit it by accident, and the only way it changes is by a reviewed merge. Make it live and it stays current as well: joiners, leavers and manager changes in your people directory arrive as proposals to review. If that picture is wrong, every comparison you make later inherits the error.

Write down what the reorg is for

"Flatten the org" is a slogan; "no manager with fewer than four direct reports, and engineering under one leader by Q2" is a goal you can test a plan against. Pick the two or three measures that define success (spans of control, cost per team, one accountable owner per product, time to fill the open roles) and write them at the top of the plan. Every option you draft gets judged against the same list, which is what stops the loudest option from winning by default.

Draft the alternatives as scenarios, not slides

There is always more than one way to reach the goal, and the way to find out which is best is to build each one properly. Copy the real organization once per option: "Platform team", "Two divisions", "Hiring freeze". Copy it with everyone assigned when the question is next quarter starting from today, or without assignments when the shape is the question and the names aren't yet. Each copy is a full organization you can rearrange freely without touching the real one, which is the whole point of org scenario planning. Keep the drafts private while they name people; a restructure that isn't approved shouldn't be readable by everyone it affects.

Compare them on the numbers that matter

Slides hide the cost of a reorg because nobody adds it up. Compare each scenario against the real organization and read the totals first: positions, filled positions, and cost, with the delta. Then the detail: which positions were added, removed or changed, and for each change the before and after of role, level, location and reporting line. Two things fall out of this quickly. Options that looked similar on a slide turn out to differ by a dozen hires, and options that looked bold turn out to move three people. Costing every position by rule, with a cost profile per role and level, means the totals stay right as you keep editing, and a problems report tells you when a position is priced by nothing.

Sequence the cutover

Few reorgs happen on one day. A new team forms in March, its manager is hired in May, a contractor rolls off in August. Put the plan on a calendar: give each position a start and end date, and if the reorg lands in phases, hold each phase as its own dated snapshot on a timeline. Headcount and cost then read as a trend across the year rather than a single number, and each position carries its own history, so "when does this role open?" has an answer that everyone can see.

Communicate with the diff, not the deck

People don't fear reorgs; they fear not knowing what a reorg means for them. The comparison you used to choose the option is also the clearest thing you can show a manager: exactly which positions in their branch change, what they change to, and what stays. Walk each leader through their part of the diff before the announcement, correct what they catch, and let the same view be the source for the all-hands. A plan that lives in the structure has one version; a plan that lives in slides has one per meeting.

Merge in stages, and keep the plan alive

When the option is approved, don't retype it. Merge the scenario into the real organization's model and review each change on its way in: accept the new team, reject the hire that isn't funded yet, resolve anything both models changed. Because that model is protected, the merge is the only route, so what went live is exactly what was reviewed. Keep working in the scenario afterwards and the next merge brings only what changed since, so phase two lands the same way phase one did. The full workflow is in Compare and merge.

A reorg planned this way is still hard. The judgment about who leads what doesn't get easier. But the mechanics stop getting in the way: every option is fully worked out, every number is real, and the day it goes live nothing is a surprise.