The real cost of a reorg

The bar for a reorg is one sentence you have to be able to say without flinching.

The current structure is the thing preventing us from doing the work.

Not that it's awkward. Not that two teams don't get on. Not that the org chart looks untidy next to the architecture diagram.

That the structure itself is the binding constraint, and that with it changed the work would actually move.

Most proposed reorgs fail that test.

They fail it because a reorg is one of the very few interventions a senior leader can perform unilaterally, which makes it disproportionately attractive at exactly the moments when you feel you ought to be doing something.

What it actually costs

Roughly a quarter of throughput.

That's the number I'd put in front of anybody proposing one, and it's made of specific things rather than vibes.

Relationships reset.

A team that had worked out how to work together, who to ask, who's good at what, starts that process again. Two to three months, and none of it is visible in any system you have.

Context is lost.

Whoever owned that service now doesn't, and what they knew about it doesn't transfer in a handover document. The first incident after a reorg takes noticeably longer, every time, and the reason is always the same: the person who would have known is on a different team now and didn't get paged.

Everything in flight slows or stops.

Work spanning the old boundaries gets reassigned mid-flight, and some of it quietly dies. Including things that were nearly finished.

And people spend a month working out where they stand.

Every reorg gets read for status information. Who gained. Who lost. Whether my manager still likes me. Whether this is the beginning of something.

That reading happens whether or not there's anything to read, and it consumes real attention from exactly the senior people you most need thinking about something else.

The cost is lumpy in a way that matters, too.

It lands almost entirely on the people who are best connected and most senior, because they're the ones whose informal network you just rewired.

Cheaper things that fix the same symptom

Three interventions solve most of what reorgs get proposed for, at a fraction of the cost.

Try these first.

Change ownership without moving people.

Most "our structure is wrong" complaints are actually "nobody owns this" or "two teams own this." Reassigning a system, updating the map and being explicit about who holds the pager fixes an enormous share of structural pain, and it takes a week.

Change scope.

An overloaded team doesn't need splitting, it needs to own less. Hand something off. Delete something. Stop accepting new surface for a quarter.

Change cadence and interfaces.

Two teams blocking each other constantly might need a shared planning slot and a clear contract rather than a merger. Two teams that never talk and should might need one person to move desks, or a standing review.

Run all three before restructuring, and say out loud that's what you're doing, because it builds the evidence at the same time.

If ownership, scope and cadence changes have all been tried and the pain persists in the same place, you have a genuine structural case. And everybody watched you build it.

When it really is the structure

There are real cases. Three I'd act on.

The architecture you need cannot be produced by the org you have, and the mismatch is in something that changes constantly rather than something stable.

Every meaningful piece of work crosses three teams, consistently.

And you can demonstrate that by tracing recent work items rather than by asserting it.

Or the company's strategy has genuinely changed and the teams are aligned to the old one.

Most legitimate reason on the list. Least often used, because it requires the strategy to have actually changed rather than merely been restated.

Notice that all three are demonstrable with evidence somebody else can check.

If your case rests on your own read of the situation, do the cheaper interventions first and gather the evidence while you're there.

Announcing it

Once, completely, with the reasoning attached, and to everyone at the same time.

The staged rollout is standard advice, and below a few hundred people I think it's usually wrong. Leaders on Monday, managers on Tuesday, everyone on Thursday.

It leaks. Always. And the gap between the leak and the announcement is where the worst version of the story gets established.

Two days of rumour costs more than the tidiness of a cascade buys.

Include the reasoning in full. Including the uncomfortable part.

If it costs a quarter of throughput, say so. If two teams are merging because one was too small to sustain a rotation, say that rather than describing a synergy.

People are extremely good at detecting the gap between a stated reason and the real one, and every unexplained decision gets an explanation invented for it. Usually a worse one than the truth.

Answer the three questions everybody actually has, immediately and in writing.

Who do I report to. What do I own. Does my pay or level change.

Until those are answered, nobody is listening to anything else you say.

And say what isn't changing. In a reorg announcement, people assume everything is in play. A short list of things that are staying the same does more to keep the quarter functional than any amount of vision.

The first thirty days

This is where most of the damage actually happens, and it's the part that gets no plan.

Ownership has to be re-established immediately, not left to settle. Every system needs a named owning team on day one, including the ones that fell between the new boundaries. Those are the ones that will be discovered in an incident three weeks later.

New managers need to meet everyone individually inside the first two weeks. Not to plan anything. To make it clear that they know who these people are, because the reorg has just told everyone they're a resource that can be moved.

Expect the quarter to be worse and say so in advance, to your own leadership and to the board if there is one. A reorg followed by a surprised conversation about missed delivery is a self-inflicted wound. Predicting the dip makes it a cost you chose; discovering it makes it a failure you're explaining.

And set a date, six months out, to check whether it worked, with the criteria written down now. Almost nobody does this, which is why reorgs are so rarely evaluated and so frequently repeated. If the thing you said would improve hasn't, that's information, and the answer is not another reorg.

The pattern to watch in yourself

If you've reorganised twice in eighteen months, the structure isn't the problem.

Something else is unresolved (a strategy that keeps moving, a leadership team that doesn't agree, a product that hasn't found its footing) and the restructuring is displacement activity. It feels like decisive action, it's fully within your authority, and it's the wrong lever pulled hard.