Reorg Planning Guide

The Reorg That Shouldn't Be A Reorg

Before planning a restructure, ask whether the problem actually requires moving reporting lines. Leaders reach for a reorg when they feel friction, but many common frustrations have simpler fixes.

A reorg is warranted when the problem is genuinely structural: the grouping of teams doesn't match the work, spans are unmanageable, layers slow information flow, or the org was built for a strategy the company has moved away from. If you can solve the problem by changing one role, one process, or one decision right, do that instead. It is faster, less disruptive, and easier to reverse.

Start With The Design Problem

A reorg is often proposed when leaders feel friction: slow decisions, duplicated work, missed handoffs, weak accountability, overloaded managers, or a new strategy that the old structure cannot support. The mistake is jumping straight to a new chart.

Write the design problem in plain operating language before touching the structure. If you cannot state the problem in one or two sentences, you are not ready to restructure.

The Reorg Workflow

A well-run reorg follows a predictable sequence. Skip a step and you'll pay for it later, usually in confused managers, political resistance, or a structure that doesn't actually fix the problem.

Step 1: Map current state

Create the real chart, not the idealized one from the last board deck. Include filled positions, open positions, interim ownership, contractors who do critical work, and dotted-line relationships where they carry real accountability. If a team exists in practice but not on any official chart, add it.

The current-state chart is your shared reference. Every conversation about what should change starts here. Without it, people argue from different mental models of the organization.

Step 2: Name the design constraint

Be specific about whether the problem is speed, accountability, cost, capability, management capacity, customer focus, or strategic direction. "We need to be more agile" is not a constraint. "Product teams cannot ship without three approval layers" is.

The constraint is what you're optimizing the new structure for. Everything else is secondary. If you try to fix five problems at once, you'll solve none of them cleanly.

Step 3: Shape one future option first

Do not generate five org charts because the tool makes it easy. Start with one coherent option that solves the named constraint. Model it completely: every person placed, every manager assigned, every open role accounted for.

Once you have one complete option, you can create a second to compare tradeoffs. But starting with multiple options before any single one is complete leads to shallow comparison and decision paralysis.

Step 4: Test the tradeoffs

No structure is free. Use the review checklist in the next section to pressure-test your proposal before anyone else sees it.

Step 5: Socialize before announcing

The communication plan matters as much as the structure. See the communication section below.

What A Well-Run Reorg Looks Like, Week By Week

Most reorgs of meaningful scope (affecting 20+ people) take 4-8 weeks from problem definition to announcement. Rushing compresses the socialization phase, which is where most failures happen.

How To Compare Structural Options

When you have two possible structures, comparing them side by side forces explicit tradeoff conversations that vague debate cannot. Score each dimension for each option, then discuss the gaps.

Neither option is universally better. Option A is the stronger structural fix but carries more risk and disruption. Option B is safer but may not solve the problem if the pod doesn't have real decision authority. The right choice depends on how severe the handoff problem is and whether the company has a viable CCO candidate.

This is the conversation the comparison forces. Without it, the debate stays at "should we merge or not?" instead of "what specifically are we trading?"

The Review Checklist

Run through these questions before presenting a future-state chart to anyone. If you can't answer them clearly, the design isn't ready.

Structure

• What specific problem does this structure solve that the current structure does not?
• Which decisions become faster or clearer?
• Where did handoffs move? Are the new handoffs actually better?
• What would make this design fail after 90 days?

Manager load

• Which manager spans become healthier? Which become more difficult?
• Are any managers getting a fundamentally different kind of team than they managed before?
• Does any manager's span exceed 10-12 without clear justification (experienced team, stable work)?

Roles and people

• Which roles need rewritten accountabilities?
• Which individuals are significantly affected (new manager, new scope, loss of reports)?
• Which teams will experience the change as a loss of autonomy, access, or status?
• Is anyone being set up to fail: given more scope without more capacity, or reduced in responsibility without a clear path forward?

Practical

• Does the new structure require a hire that hasn't been made yet? If yes, what happens until that person starts?
• Are there compensation, title, or legal implications (role elimination, geographic considerations)?
• Can you implement this in one move, or does it require phasing?

The Communication Plan

Communication is where most reorgs fail. The structure can be well-designed, but if people learn about it in the wrong order, through the wrong channel, or without understanding the reasoning, the reorg creates more problems than it solves.

The order matters

People who are losing reports, changing scope, or getting a new manager should never learn about it in an all-hands. The sequence:

1. Affected leaders first. Anyone whose role, scope, or reporting changes significantly hears it from the exec sponsor in a 1:1, ideally 2-5 days before the broader announcement. They need time to process before they have to lead their teams through it.
2. All affected managers. Brief every manager who will need to talk to their team. Give them talking points, an FAQ, and the timeline. A manager who learns about the reorg 30 minutes before their team does cannot lead the conversation well.
3. Broader announcement. The exec sponsor communicates the change to the full affected group. Keep it short: what is changing, why, what is not changing, what happens next, and who to ask questions.
4. 1:1 follow-ups. Within 48 hours, every person whose manager, team, or role changes has a 1:1 with their new manager or their current manager (whoever is better positioned to answer their questions).

What to say

What people actually want to know

Regardless of what you present, most people will immediately think about these questions. If your communication doesn't answer them, people will fill in the gaps with assumptions:

• "Who is my manager now?" Be explicit. Do not leave this ambiguous for even one day.
• "Is my job safe?" If roles are being eliminated, say so directly. If roles are safe, say that too. Silence is interpreted as threat.
• "Why was this done to me?" People personalize structural changes. Frame the change in terms of the work and the problem, not in terms of individual performance.
• "Did I lose status?" If someone's scope, title, or number of reports changes, acknowledge it. Do not pretend a lateral move is a promotion.
• "When does this actually happen?" Set a clear effective date. Ambiguity about timing creates weeks of organizational anxiety.

The First 90 Days After The Reorg

Announcing the reorg is the halfway point, not the finish line. The structure doesn't become real until new reporting lines carry real decisions, new meeting cadences replace old ones, and people stop defaulting to the old relationships.

Days 1-30: Stabilize

• Update the org chart, HRIS, and access permissions on day one. If the official systems still show the old structure, people will treat the reorg as optional.
• New managers hold introductory 1:1s with every new report within the first week.
• Establish new team meetings and operating cadences. Don't wait for people to figure it out organically.
• Kill the old meetings and Slack channels that belonged to the previous structure. Leaving them active sends mixed signals about whether the change is real.

Days 30-60: Watch for signals

• Are decisions actually flowing through the new structure, or are people still going to their old manager?
• Are the handoffs that the reorg was supposed to fix actually working better?
• Are any managers clearly struggling with their new scope or team composition?
• Are people raising the same complaints that the reorg was supposed to solve?

Days 60-90: Adjust

• Have a structured review with the exec sponsor and People/HR partner. Compare the current state against the design problem statement: is the problem actually improving?
• Make small adjustments: a role that needs clearer scope, a manager who needs one report moved, a coordination mechanism that was missed.
• Resist the urge to do another reorg if things aren't perfect. Most structures need 2-3 months to settle. The goal at 90 days is directional progress, not perfection.

Worked Example: A 130-Person Company Restructure

Common Mistakes