Stop Redrawing the Org Chart Before You Diagnose the Work

The org chart is visible. The work is not.

When an organization feels slow, expensive, or difficult to manage, the org chart becomes an attractive target. It is concrete. It shows layers, spans, boxes, reporting lines, and obvious opportunities to combine or remove roles.

But the chart is only a representation of formal structure. It does not show the full system of work.

It does not reveal where decisions are waiting, which teams depend on one another, where informal coordination actually happens, which approvals exist because trust is low, which roles carry hidden specialist knowledge, or where a process crosses five functions before reaching a customer.

Start with a work chart

Deloitte’s 2026 work on organizational delayering makes the case for looking at a “work chart” alongside the org chart: map tasks and processes to understand how work actually gets done before deciding how roles should change.

That distinction is especially important as AI changes the amount of coordination, synthesis, and managerial work required. Some layers may no longer add the same value. Some roles may fuse. Some decision rights may need to move. But none of those conclusions should be automatic.

Benchmarks are evidence, not prescriptions

Span-of-control and layer benchmarks can be useful. They can show where a structure is unusual and where further diagnosis is warranted. They cannot tell you, by themselves, what the right design is.

A wide span can signal empowered teams and simple work. It can also signal an overloaded manager responsible for highly differentiated work. A narrow span can signal unnecessary hierarchy. It can also reflect complex judgment, regulated work, coaching intensity, or a deliberate capability-building model.

The benchmark tells you where to look. The work tells you what to do.

Five things to diagnose before moving boxes

1. Work flow. How does value move from request to outcome? Where does it wait, loop, or return for correction?
2. Decision flow. Which decisions matter most, who makes them today, and where are decisions routinely escalated or duplicated?
3. Coordination load. Which roles exist primarily to connect functions that the operating model has separated?
4. Capability. Which expertise is scarce, where does it sit, and what would be lost if roles were combined or layers removed?
5. Management purpose. What are managers actually doing: approving, coordinating, coaching, allocating resources, resolving exceptions, building capability, or simply transmitting information?

Structure should follow the operating problem

McKinsey has documented organizations where execution slowed because decisions were unnecessarily escalated and accountability was diffuse. Clarifying decision rights reduced friction without lowering performance expectations. That is an operating-model intervention, not simply an org-chart exercise.

The same principle applies more broadly. If the real problem is duplicate approval, fix the decision architecture. If the problem is fragmented end-to-end ownership, redesign around the work. If the problem is a capability gap, removing layers may make it worse. If the problem is managerial overhead, clarify which management work is still necessary before eliminating the people who currently perform it.

Redesign the system, then draw the picture

A reorganization can be necessary. Sometimes it is overdue. But the sequence matters.

Diagnose the work. Clarify decisions. Understand dependencies. Identify the capabilities the future model requires. Decide what management must accomplish. Then design the structure that best supports those conditions.

Otherwise, the organization may spend months moving boxes only to discover that the same decisions, handoffs, and bottlenecks survived the reorganization.

The org chart should be the output of the diagnosis, not the starting point.