A Reorg Is the Most Expensive Way to Avoid the Real Problem

Something isn't working. Deadlines are slipping, two teams keep colliding over the same piece of work, a product line is underperforming, and the pressure to do something visible about it is building by the week. So leadership reaches for the tool that always looks like action: a reorganization. New reporting lines, a couple of functions combined, a fresh layer of leadership, a company-wide announcement about a more agile, more aligned, more customer-focused structure.

It feels decisive and looks great on paper. And a striking amount of the time, it changes almost nothing about the problem it was meant to solve.

Six months later the deadlines are still slipping, the same two teams are still colliding, and a new set of issues have been identified. Everyone is a little more tired, a little more uncertain about who does what, and no closer to the outcome that triggered the exercise.

Structure Is Rarely the Thing That's Broken

A reorg can only fix a small category of problems: the ones caused by structure. Two functions that genuinely need to merge. A reporting line so tangled that accountability is impossible. A span of control so wide a manager can't manage. Real structural problems exist, and for those, restructuring is the right move.

But most of what gets blamed on structure isn't structure at all. Deadlines slip because priorities were never sequenced, and everything is labeled urgent. Teams collide because a handoff between them is undefined, not because they report to the wrong person. A product underperforms because the strategy is unclear, not because it needs a new home on the chart. None of that gets fixed by redrawing boxes, because the box was never the problem.

Reorganizing around a non-structural problem is like rearranging furniture to fix a leak. The room looks different. The water keeps coming.

Why the Reorg Reflex Is So Strong

Reorgs are appealing precisely because they let you avoid the harder conversation. Fixing an undefined handoff means admitting nobody agreed on who owns it and negotiating that in the room. Fixing scattered priorities means leadership picking what matters and telling people what to stop doing. Fixing an unclear strategy means saying out loud that the strategy isn't clear.

Those conversations are uncomfortable and slow, and they put the people calling for change on the hook for the answer. A reorg sidesteps all of it. It's a large, visible move that signals seriousness while quietly punting every hard decision to the new structure, as if the boxes will sort it out on their own. They won't. The ambiguity just moves into the new arrangement and sits there, waiting to resurface under a different name.

There's also a real cost to the motion itself. Every reorg spends months of attention, resets working relationships, restarts the clock on trust, and quietly tells everyone that the way to look responsive is to change the chart again next year. That's a lot to pay for avoiding a conversation you could have had directly.

Diagnose Before You Restructure

Before moving a single box, get specific about the problem in terms that have nothing to do with the org chart. What exactly is failing? When did it start? What has to be true for it to stop? Trace one recent instance all the way through until you find where it actually broke.

Usually, the breakdown has a name that isn't "the structure." An owner was never assigned. Two teams were measured on goals that quietly contradict each other. A decision needs three approvals and nobody will give the first. Information a team needs sits behind a request that takes a week. These are real, fixable problems, and none of them requires a reorganization. Several of them survived completely untouched, because the reorg never looked at them.

If, after that diagnosis, the problem genuinely turns out to be structural, restructure with confidence. You'll know what you're fixing and how you'll recognize success. More often, though, you'll find something you can address in a matter of weeks without moving anyone's reporting line, and you'll have spared the organization a disruption that was never going to solve the actual problem anyway.

Change the Chart Last, Not First

Treating a reorg as the default response to any serious problem gets the sequence backwards. Structure might be the last thing you should change, not the first, precisely because it's the most disruptive move available and the least likely to be the actual cause. Reach for it first, and you get motion that looks like progress while the real issue keeps running underneath - now buried one layer deeper and harder to see than before.

The unglamorous work of naming the real problem has to come before the far more satisfying work of drawing a new chart. Skip that step, and the reorg ends up being exactly what it looked like from the outside all along: an expensive, well-attended way of not dealing with what's actually wrong.