Organizational Design: Why Most Redesigns Fail (And What to Do Instead)

A senior leader pulled me aside three months into a merger: “We’ve been talking about the org structure for twelve weeks. Everyone has opinions. Nothing is decided. People are starting to leave.”

I’ve seen this movie before. It ends badly. Prolonged ambiguity is more damaging than an imperfect decision. The best people—the ones with options—don’t wait around while executives debate reporting lines. They find clarity somewhere else.

McKinsey’s research says less than 25% of organizational redesigns meet their objectives. Almost half run out of steam before completion. Those numbers track with what I’ve seen in the field. Most org design efforts fail not because the target structure is wrong, but because the process of getting there destroys value faster than the new structure can create it.

Here’s how we approach it differently.

Design decisions, not boxes

The instinct is to start with structure: who reports to whom, how many layers, what goes in which function. Org charts are concrete. They feel like progress.

But structure is the easy part. The hard part is designing how decisions get made.

Before drawing any boxes, we map the 20-30 most important decisions the organization makes. Who sets pricing? Who approves capital expenditure over $X? Who decides which features make the roadmap? Who resolves conflicts between sales and operations? For each decision: who has input, who decides, who needs to be informed, how quickly must it happen.

This exercise almost always surfaces problems that a structure change won’t fix. Decisions are slow because of culture, not reporting lines. Accountability is unclear because leadership hasn’t made hard choices, not because the org chart is wrong. Information doesn’t flow because systems are broken, not because boxes are in the wrong places.

Sometimes the answer is: structure isn’t actually the problem. The presenting complaint is “our org doesn’t work,” but the root cause is executive dysfunction, or process gaps, or technical debt. A new structure just rearranges the dysfunction.

When structure genuinely is the constraint, the decision map tells you what the structure needs to enable. You design for the work, not for political accommodation.

Stop benchmarking

Clients often ask what best-in-class companies do. What’s the right span of control? How many layers should we have? Should we centralize or decentralize this function?

There’s no right answer. Optimal structure depends entirely on strategy, competitive dynamics, talent, and culture. A centralized model that works beautifully for one company would destroy another.

Fortune’s Most Admired Companies have nothing in common structurally except flexible operating models. The implication is that you need to design for your specific context, not copy someone else’s homework.

I use a simple heuristic: optimize for your bottleneck. If speed is the constraint, flatten the structure and push decisions down. If consistency is the problem, centralize and standardize. If innovation is lagging, create cross-functional teams with dedicated resources. If accountability is unclear, simplify reporting lines and eliminate matrix overlaps.

The question isn’t “what’s the best structure?” It’s “what’s constraining us and what structure alleviates that constraint?”

Move fast on leadership

Every week without an org decision costs you someone you wanted to keep.

Week one, they’re patient. Week four, they’re updating LinkedIn. Week eight, they’re gone.

This isn’t just anecdote. A UCL study found that uncertainty is more stressful than guaranteed bad news. People waiting for a 50% chance of an electric shock showed higher stress than people who knew they’d definitely get shocked.

Certainty, even painful certainty, is easier to process than limbo.

Your best people aren’t afraid of a tough new structure. They’re afraid of twelve weeks of “we’re still working through it.”

Our rule: L1 decisions within 4 weeks. CEO directs named and in place. L2 follows shortly after. Not twelve weeks of debate. Never twelve.

Separate structure from people

One of the most common failure modes: designing the structure around the people you have rather than the work you need done.

It’s understandable. You know Sarah is great and you want to keep her, so you create a role that fits her skills. You know Tom is difficult but connected, so you design around him rather than through him. Before long, the org chart is a political accommodation rather than a functional design.

Better approach: design the structure first, then assess people against roles. This is harder politically but produces better outcomes. It also surfaces talent gaps honestly rather than papering over them with creative titles.

The conversation with Sarah becomes: “Here’s the role we need. Here’s what it requires. Do you want it? Can you grow into it?” That’s a respectful conversation. It treats her as an adult. The alternative—creating a role that doesn’t quite fit because you’re afraid to have the hard conversation—serves no one.

Don’t reorganize your way out of a performance problem

If someone isn’t working out, the restructure won’t fix it. Deal with performance directly.

I’ve seen organizations use reorgs as a way to move problem performers around rather than address them. The hope is that a new structure, new boss, new team will somehow solve the issue. It won’t. The problem follows the person.

The restructure should be about structure. Performance management should be about performance. Conflating them makes both worse.

The meta-question

Before launching any organizational redesign, answer this: “Is structure actually our problem?”

Often, the symptoms that trigger redesigns—slow decision-making, poor collaboration, unclear accountability—have root causes that structure won’t fix. Leadership behavior. Talent gaps. Misaligned incentives. Cultural dysfunction. Addressing those issues is harder than drawing new boxes, which is exactly why organizations reach for structural solutions.

Sometimes structure really is the constraint. But verify before assuming.