Most reorgs at small companies are planned the same way: someone senior opens a copy of the org chart late in the evening, drags names around until the shape looks better, and keeps the file somewhere nobody will stumble on it. The plan lives in secret for three weeks. Then it's announced in a single meeting, and half the questions in the room are ones nobody thought to ask on paper.

The problem isn't secrecy. Some discretion is appropriate when roles are changing. The problem is that the plan usually skips the checks that would have caught its weak spots while they were still cheap to fix. This is a better way to plan a reorg, written for companies in the 20-200 range, where the decision is made by two or three people and lands on everyone.

Write the problem down before you touch a single box

A reorg that starts with the boxes is a reorg that starts with someone's preferred answer. Start with the sentence instead: what is breaking, for whom, and how do we know?

"Support tickets sit for two days because the team reports into sales and gets deprioritized every quarter-end." "One manager has eleven direct reports and interviews are slipping." "Two teams both think they own onboarding." Those are problems a structure can address. "The org feels flat" and "we need to look more grown-up for investors" are not. They're aesthetics, and reorganizing for aesthetics is how you end up doing this again in nine months.

Write the problem in one or two sentences at the top of the plan. Every move you sketch afterward either serves that sentence or it doesn't belong in this reorg. The discipline sounds obvious. It's also the step most often skipped, because the boxes are more fun than the sentence.

Draw the target on a copy, never on the live chart

Wherever your org chart lives, do not plan the future on the version people rely on today. The moment a "what if" edit lands on the live chart, one of two things happens: someone sees it early and the rumor mill starts, or you forget which changes were real and which were experiments.

Work on a private copy. That can be as basic as a duplicated slide, or, if you keep your chart in OrgPlease, a scenario: a sandbox copy of the live chart you can rearrange freely, which tracks every move against reality and totals the compensation change as you go. (Scenario planning is our feature, so weigh the recommendation accordingly. A duplicated slide works; it just makes you do the bookkeeping by hand.)

However you do it, the copy needs to record three things per change: who moves, from whom, to whom. That list, not the pretty chart, is what you'll actually use in every conversation that follows.

Sanity-check the shape with three numbers

A proposed structure can look elegant and still be unworkable. Before showing it to anyone, check three numbers.

Span of control. Count each manager's direct reports in the target structure. The healthy range for most teams is 3 to 7. It's the range we bake into OrgPlease's org health report, and it holds up in practice. A span of 10 or more means that manager does status collection, not management. A span of 1 means you've built a corridor: a manager whose whole job is relaying one person's work upward. Both are structure smells worth fixing on paper.

Manager ratio. If more than about 40% of the company manages people, the org is top-heavy: you've created coordination work faster than you've created output. Small companies drift here reorg by reorg, one "they deserve a title" decision at a time, and each individual decision feels reasonable.

The compensation delta. Total what the target structure costs against what today costs: new roles, backfills, and any adjustments the moves imply. Reorgs are rarely free, and finance finding that out after the announcement is a bad sequence. If your planning copy tracks the delta automatically, this takes a glance; if it's a slide, it's twenty minutes in a spreadsheet you should spend.

None of these numbers makes the decision for you. A span of 9 might be fine for a team of senior people running independent accounts. The point is to see the exceptions and choose them deliberately, instead of discovering them in month two.

Make the two lists

Here's the pressure test that catches most reorg mistakes, and it takes ten minutes. From your change list, write out:

  1. Everyone whose manager changes. These people are inheriting a new relationship they didn't ask for. For each: does the new manager have context on their work? Is there a live project that the move disrupts mid-flight? Is this their second new manager this year? (If yes, that's a flag: people forgive one reshuffle and resent a pattern.)
  2. Every manager who loses a report or a team. This list is shorter and more dangerous. On paper it's a box moving left. In the room it's someone hearing their scope shrank, often in front of colleagues. Nobody on this list should learn about it in the all-hands. That's the single most reliable way a reorg turns one departure into three.

The two lists are your risk register and your communication plan in one. If a name shows up on both lists, that conversation happens first and in person.

Sequence the announcement like you sequenced the plan

The order of conversations matters more than the deck. The sequence that works:

  1. Affected managers first, individually. Anyone losing or gaining scope hears it privately, with room to react, ideally days before anything is public. You want their real objections now, while the plan can still absorb them.
  2. Then everyone whose manager changes, one on one. Ideally the outgoing manager makes the introduction rather than the new one claiming them. Short, direct, "here's why," "here's what doesn't change."
  3. Then everyone else, all at once, with the new chart in hand. The announcement meeting should end with the actual updated org chart available to everyone, not a promise that "the new structure will be reflected soon." An announced reorg with a stale chart is a rumor with a slide deck. The chart is the announcement artifact: when people can open it, click around, and see where they and their colleagues landed, the speculation stops.

The day after

Two small things separate a clean reorg from a lingering one.

Keep a record of the before. Snapshot the pre-reorg structure (export it, save it, whatever your tool supports), because "what exactly did we change?" keeps coming up for months, usually in comp reviews, and occasionally in a dispute about what someone's team used to be. (In OrgPlease this happens automatically: promoting a scenario snapshots the prior state, and version history keeps the timeline.)

And kill the planning copy. Once the target is live, archive or delete the drafts: the slide with three abandoned options, the "v2-final" file, all of it. Leftover phantom charts are where next quarter's confusion comes from.

The short version

Write the problem before you draw. Plan on a copy, not the live chart. Check spans, the manager ratio, and the cost delta. Make the two lists and honor them in the order of conversations. Announce with the updated chart in hand, snapshot the before, and delete the drafts.

None of this requires special software. A disciplined slide and a spreadsheet can do it. A purpose-built tool mostly compresses the bookkeeping: the copy, the change list, the totals, the snapshot. That's the part we built OrgPlease's scenario planning for, and it starts on the $19/month plan if the reorg on your desk is bigger than a slide wants to be.


Planning a restructure right now? Model it on a private copy first, promote it when it's ready, and keep the before on file. Start your free org chart, free up to 25 people, no credit card.

Related reading: Org chart scenario planning · How to make an org chart from a CSV · Org chart version history