How to plan a reorg with an org chart
A reorg is a chart before it is anything else, and the version you sketch first is the version people remember. So draw it properly, on a chart nobody else can see, test it, and announce it with a picture that is already right. The sequence below, with a worked example: the same eighteen people, before and after.
Today
Proposed
The sequence
Six steps, in this order, because each one is cheaper before the next.
-
Start from a chart that is true
The first draft of the future is an accurate picture of the present. Export the people from the HR system, import it, and fix what it gets wrong — there are always three people whose manager in the system is not their manager in life. Date the result. If the current chart is disputed, every conversation about the new one begins with an argument about the old one.
-
Draft on a second chart
Leave the current chart alone and make the draft a separate one: import the same export again and rename it. The baseline stays true and the draft is a document you can throw away. Do not share it. When two or three people need to see it, send them a view link rather than an export — an exported picture is the version that gets forwarded, and a draft that has been forwarded is no longer a draft.
-
Test the draft
Against the six checks below. This is the step that gets skipped, and it is the reason most reorgs get reorganised again within a year.
-
Draw the transition, not only the destination
For a quarter or so, some people will have two managers: the new one, and the old one they still finish things for. Draw that as a dotted line and give it an end date in the note under the chart. A transition that is not drawn is a transition that is negotiated in corridors.
-
Announce with one chart
The leadership team sees the final chart two days before everyone else, so nobody learns their own change in a room of two hundred. Then one export, the same file in every deck. Then the share link becomes the live chart. Then HR updates the system from the chart, not the chart from the system.
-
Expect it to be wrong for six weeks
The chart changes daily after an announcement as titles settle and people move. Give it one owner, keep editing the live chart rather than the deck, and when the dust settles re-import from HR to catch what everyone forgot to mention.
What to test on the draft
Six checks. A draft that passes all of them is not necessarily right, but a draft that fails one is not ready.
Spans of control
Nobody over about eight direct reports unless the work is standardised, and nobody with one. A manager of one is a title, not a team.
Layers
Count them before and after. A layer added costs a salary and a day of latency on every decision; a layer removed costs someone their reports. Both need a sentence of justification.
Every dotted line, explained
If you cannot say in one sentence why a dotted line exists and when it ends, it is a solid line you have not admitted to.
Every open role, costed
An open card on the draft is a hire. Give it a title, a start month and a number, or take it off.
Who loses a title
The chart will be read by the people on it first. Find everyone whose title, reports or manager changes, and decide who tells them and when — before the chart tells them.
The two people it is really about
Most reorgs are a chart-shaped way of resolving one or two situations. Name them privately, and check the rest of the structure is not collateral.
Keeping the draft private
The single most common reorg failure is the draft that got out. It rarely leaks on purpose: a screenshot in a message, an export in a deck, a chart left open on a shared screen. The defences are simple and mostly about format. Keep the draft as a chart, not a picture, until it is final. Share it with named people through a link you can revoke, and revoke it when the review is done. Don't export until the version being exported is the version being announced.
And keep the number of people who see the draft honest. Every reorg has a small group who genuinely need to shape it and a much larger group who would like to. The chart's audience is the first group; the second gets the announcement.
Questions people ask
- Should the announcement show the old structure next to the new one?
- Internally, no. People look for themselves in the old one, find the change, and stop reading. Show the new structure and, separately, a short written list of what changes for whom. The before-and-after pair is for the people designing the reorg, not for the people receiving it.
- How do I show someone whose role is changing but is not yet decided?
- Leave them where they are today and draw an open role where they might go. Moving a person on a draft that anyone else can see is a decision, whether or not you meant it as one — and it is the kind that travels.
- How many layers is too many?
- For a company under about a hundred people, three below the chief executive is plenty, and a fourth deserves a written reason. Removing a layer is usually the more painful change: it is not abstract to the person who no longer has reports.
- When does the chart go to HR?
- After the leadership team has seen it and before the all-hands. HR needs the chart to update the system, prepare the letters and answer the questions; none of that can be done from a rumour, and all of it takes longer than the announcement.
- What about the people who do not move?
- Most of them. Their chart does not change, and the announcement should say so in as many words. Silence about a team reads as "not yet", and the team will spend a fortnight waiting for the other shoe.
Draw it before you say it
Import the current structure from a spreadsheet, keep it as the baseline, and draft the new one beside it. Building is free at any size; the export is the only thing you pay for, and it is the last thing you will need.