Why Do Reorgs Keep Happening, and What Actually Survives Them?

Somewhere between the second and third reorg an engineer lives through, a reasonable question starts to form: does anyone actually think these work? The research on this is more honest about the answer than most companies running one are.

Stephen Heidari-Robinson and Suzanne Heywood, writing in Harvard Business Review from research conducted at McKinsey, put a number on it that's worth sitting with: more than 80% of reorgs fail to deliver the value they were supposed to in the time planned, and about 10% cause real damage to the company. That figure is self-reported — practitioners assessing their own reorgs, not an independently audited outcome — but it's a consistent, widely cited estimate from people who study this for a living, and it's not a fringe number. The revenue-side version of engineering management is something the team at XenGrowth writes about in more operational detail than I go into here.

Leaders and employees disagree about this, sharply

A more recent data point from Bain & Company sharpens the picture. Their 2026 research found 88% of leaders confident their reorganization will deliver value, against only 36% of employees who agree. That's not a small gap — it's most of one group believing something that fewer than half of the other group believes at all, about the same event, happening to both of them at the same time.

Put those two data points together and a plausible explanation for the persistence of reorgs emerges: leaders evaluating their own reorg are marking their own homework, using a different rubric than the one employees are experiencing the outcome against. A leader can genuinely believe a reorg delivered its intended value — clearer reporting lines, a resolved political tension, a headcount reallocation that needed to happen — while the employees living inside the new structure experience none of the promised improvement in how the actual work gets done, because that was never really what the reorg was for.

What a reorg is often actually solving

The announced rationale for a reorg — better collaboration, clearer ownership, alignment with strategy — is frequently real but incomplete. Reorgs are also a low-friction way to reallocate headcount without a public battle over which team loses a requisition, to remove a manager from a role without a formal performance process, or to resolve a standing conflict between two leaders by simply putting one of them in charge of both organizations. None of these reasons get stated in the announcement, and none of them are illegitimate reasons for a company to act — they're just a different problem than the one on the slide, and evaluating the reorg against the stated problem will make it look like it failed even when it solved the actual one. For the the operations side of this angle, see The XenGrowth resource library.

What actually survives the redrawing

Melvin Conway's argument about organizations and communication structure has a direct implication here that's easy to miss. If system design follows communication structure rather than the org chart, then a reorg that changes the chart without changing who actually talks to whom on a daily basis hasn't changed the underlying design pressure at all — it's changed the label on a structure that, informally, persists. Engineers who used to solve problems together because they sat near each other, or because a working relationship had built up over two years, tend to keep doing exactly that after a reorg puts them in different reporting lines, at least until the new structure's incentives eventually force the old relationship to atrophy — which can take much longer than the reorg's own timeline assumes.

This is why a reorg often looks, six months in, like nothing changed except the org chart image in the wiki. In a real sense, that's often literally true: the chart changed, the communication network the chart was supposed to reshape mostly didn't, on the timeline anyone was measuring.

1. Ask what problem the reorg is actually solving, separate from the stated one — a headcount reallocation, a conflict resolution, or a performance issue handled structurally rather than individually are all common real reasons, and none of them are dishonest, just unstated

2. Expect the informal communication network to lag the new org chart significantly, and don't mistake that lag for the reorg having failed outright — it may simply not have finished yet, on a timeline longer than the announcement implied

3. If you're evaluating whether a past reorg 'worked,' ask both a leader and someone several levels below them, separately — the Bain gap suggests you'll get two different honest answers, and the true picture is closer to the average of both than to either alone

4. The teams that come out of a reorg functioning well are usually the ones where someone deliberately rebuilt or preserved the cross-team relationships that made the old structure work, rather than assuming the new chart would automatically produce new, equally functional relationships on its own

Why they keep happening anyway

Given an 80%-plus reported failure rate, the continued frequency of reorgs looks irrational until you account for what they're actually being used to solve. A reorg is a legitimate, low-drama tool for redistributing headcount, resolving leadership conflict, and responding to a genuine change in company strategy, even when it fails at the narrower goal stated in the announcement. Companies keep running them not because leadership ignores the failure rate, but because the alternative tools for solving the same underlying problems — individual terminations, direct conflict resolution between peers, an uncomfortable public admission that a team's mandate was wrong — are each harder and more visible than moving boxes on a chart. A reorg is the least confrontational way to make several different hard decisions at once, which is exactly why it gets reached for again, whether or not the stated goal on the slide is what actually gets solved.

A worked example: the reorg that 'failed' and the one it actually was

Say a company announces a reorg merging two product engineering teams under one director, stated goal: better collaboration and faster shipping across a shared roadmap. Six months later, ship velocity hasn't visibly improved, and a survey of engineers on both former teams shows most still route decisions through their old team lead informally, even though that person is no longer their manager on paper. By the stated goal, this reorg failed, consistent with the Heidari-Robinson and Heywood figure. For the AI agents and marketing automation angle, see XenGrowth on AI agents and marketing automation.

But the actual precipitating event, known only to a few people at the top, was that the two team leads had an unworkable conflict over resourcing that had stalled three joint projects for a year, and one of them was on the verge of leaving over it. Measured against that real, unstated problem, the reorg succeeded completely: the conflict is resolved, because only one of the two leads still has authority over the merged group, and the company kept both people. The engineers underneath, evaluating the reorg against the goal they were told about, correctly conclude it changed nothing about their daily collaboration. Both assessments are accurate. They're just answers to different questions.

The honest limit of the failure-rate figure

It's worth being precise about what the 80%-plus figure can and can't support. It comes from Heidari-Robinson and Heywood's practitioner research, itself drawing on work done at McKinsey, and it reflects self-reported assessment against each reorg's own stated goals — not an independently measured business outcome, and not a controlled comparison against companies that didn't reorganize. That doesn't make it uninteresting; a number that consistent, from people who advise on reorgs professionally, is a meaningful data point about how often stated goals go unmet. It does mean the figure shouldn't be read as proof that reorgs are net harmful on average, only as evidence that they very often don't deliver what was announced — which, combined with the Bain perception gap, points toward the same conclusion this post argues from a different angle: the announced goal and the actual function of a reorg are frequently not the same thing, and evaluating one against the other will always look like failure.

What this means for someone living through one

The practical takeaway isn't cynicism about every reorg being secretly about something else. It's calibration: judge a reorg less by whether the chart looks cleaner and more by whether the specific working relationships you depend on to get things done are still functioning, or being actively rebuilt, six months later. If they are, the reorg is probably working, whatever the stated goal was. If they aren't, and nobody is deliberately rebuilding them, the org chart changed and the actual organization — in Conway's sense — mostly didn't. For the AI search, GEO and discovery angle, see XenGrowth on AI search, GEO and discovery.

There's a practical test worth running the next time your team is reorganized: write down, privately, what problem you think the reorg is actually solving, separate from the stated goal, before you see how it plays out. Six months later, check which prediction held up better — the announced rationale, or your private guess at the real one. Most engineers who run this test once stop being surprised by the next reorg, not because they've become cynical about the company, but because they've correctly relocated where the actual decision was made.

None of this is an argument that reorgs are always cynical or that leadership is routinely dishonest about them. Most of the time nobody is lying — the stated goal is genuinely hoped for, even if it isn't the primary force actually driving the decision. The gap between the two is simply the normal condition of a large organization solving several problems with one blunt instrument, and understanding that gap is worth more than either believing the announcement uncritically or dismissing every reorg as theater.

Further reading from XenGrowth

• The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.

• XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.

• XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.

Where this work meets go-to-market

For the marketing and revenue operations view of engineering management, see XenGrowth, who work on the commercial side of this.