McKinsey found that 80% of reorgs fail to deliver their intended value. 60% actually reduce productivity during the transition.
That is not a rounding error. That is most reorgs, most of the time, making things worse.
The question is: why? And more importantly, is there a signal you can read before you shuffle 200 people into new reporting lines and hope for the best?
There is. It is called span of control.
One number, enormous leverage
Span of control is the number of direct reports a manager has. That is the entire definition.
Manager has 4 direct reports? Span of 4. Has 14? Span of 14. Simple math, massive implications.
Here is why it matters: span of control is the single best proxy for how information flows through your company. Too narrow and you have created a bureaucratic layer cake where every decision climbs six levels before someone can say yes. Too wide and your managers are drowning -- skipping 1:1s, missing performance issues, making slow decisions because they physically cannot give 15 people adequate attention.
Neither failure mode announces itself. They creep in gradually. Then one day your best engineer quits because she has not had a meaningful conversation with her manager in three months, and your CEO is shocked.
What the benchmarks actually say
The typical healthy span of control falls between 5 and 8 direct reports. But "typical" hides important nuance.
Creative and knowledge work teams tend to function well at the wider end -- 7 to 10. These are senior people who need autonomy more than direction. A design lead managing 8 experienced designers can work.
Engineering teams tend to perform better at the tighter end -- 4 to 7. Code review, architecture decisions, and technical mentorship demand more hands-on management time. A VP of Engineering with 12 direct reports is not leading. They are triaging.
Operations and frontline teams can sometimes stretch to 15-20, particularly when work is standardized and repeatable. A call center supervisor managing 18 agents following scripts is a different animal than a product director managing 18 PMs each running different product lines.
The number alone does not tell you if something is broken. The number relative to the type of work does.
The hidden costs of ignoring it
When you do not track span of control, problems compound silently.
OneDirectory identifies two of the most expensive: "hidden vacant roles and overlapping duties" and "resource planning failures (over/under-staffing teams)."
Translate that into dollars. A team with 3 managers each supervising 2 people is burning 3 management salaries to oversee 6 ICs. That is a manager-to-IC ratio of 1:2. You are paying for hierarchy, not output.
Flip it. A team with 1 manager supervising 14 people looks lean on paper. But that manager has not done a single 1:1 in six weeks. Two people are doing duplicate work because nobody is coordinating. One person quietly stopped contributing three months ago and nobody noticed.
Both scenarios bleed money. Neither shows up in a P&L.
How to calculate it (the right way)
The basic formula is straightforward:
Average Span of Control = Total Direct Reports / Total Managers
If you have 500 employees and 80 managers, your average span is 6.25. Healthy range. You are probably fine.
Except averages lie.
The useful version is calculating span of control per manager and looking at the distribution. You want to know that your average is 6.25 but also that Sarah in engineering has 3 reports and Marcus in sales has 16. That variance is where the problems live.
You also want to track it over time. A manager whose span went from 6 to 12 in three months did not get promoted -- they inherited two departures and a hiring freeze. That is a burnout trajectory with a six-month fuse.
What this looks like before a reorg
Here is where this gets tactical.
Before any reorg, run a span of control analysis across every manager. You will find one of four patterns:
Pattern 1: Top-heavy. Most managers have 2-4 reports. You have too many layers. Information is slow. Decisions bounce up and down the chain. Cut a management layer and redistribute.
Pattern 2: Bottom-heavy. Most managers have 10+ reports. Burnout is coming. Attrition will spike in 6-12 months. You need to either hire managers or restructure teams.
Pattern 3: Bimodal. Some managers have 3, others have 14. You do not have an org design -- you have historical accidents. This is the most common and the most fixable.
Pattern 4: Uniform. Most managers sit between 5 and 8. Do not reorg. Seriously. If this is your distribution and performance is fine, the problem is not your structure.
Pattern 4 is rare. That is why most reorgs happen. The tragedy is that patterns 1 through 3 are diagnosable before you blow up the org chart, not after.
Running this analysis without losing a week
Here is the practical problem: calculating span of control across a real organization is tedious.
You need an accurate, current list of every employee and their reporting relationships. Then you need to count direct reports per manager, compute averages and distributions, identify outliers, and compare against benchmarks for each function.
If your org chart lives in a spreadsheet, that is a half-day project that is stale by the time you finish. If it lives in someone's head, good luck.
ChartPull computes span of control automatically from your live Google Workspace data. Every manager's span is calculated in real-time. Outliers -- anyone above or below the healthy range for their function -- get flagged automatically.
No exporting. No manual counting. No spreadsheet that was accurate two reorgs ago.
The reorg survival metric
Here is the uncomfortable truth that McKinsey's 80% failure rate implies: most companies reorg based on vibes.
Someone feels like the product team is too siloed. Someone else thinks engineering needs a platform team. The CEO saw a competitor's org chart on LinkedIn and wants to copy it.
None of those are data.
Span of control is data. Layer count is data. Manager-to-IC ratio is data. If you are going to move hundreds of people around -- disrupting their work, their relationships, their commutes -- the least you can do is measure the thing you are trying to fix.
Measure it before. Measure it during. Measure it after. If the numbers do not improve, the reorg did not work, no matter how good the new boxes look on the slide deck.
The 80% who fail are not unlucky. They just never measured.