I have lived through six reorgs as either the person drawing the boxes or the person being drawn into one. Exactly one of them worked. The other five were expensive, morale-draining exercises that mostly moved the same problems into different rooms and then declared victory before anyone checked whether the problems had actually left.
That ratio is not unusual. Reorgs are the single most overused tool in a leader's kit, reached for whenever the real problem is too uncomfortable to name. They feel like decisive action. They are visible, they are dramatic, and they let you announce that things are changing without you having to admit what was actually broken. Here is why so many of them fail, and what the rare good one does differently.
The Reorg Is Usually Avoidance in a Costume
Most reorgs are not solving a structural problem. They are dodging a people problem or a strategy problem that nobody wants to say out loud. You have two directors who cannot stand each other, so you split their teams onto separate branches of the tree rather than dealing with the fact that one of them is the issue. You have no coherent product strategy, so you rearrange the engineering org and hope that a new shape will conjure the clarity that leadership never provided.
I did this myself once. We had a payments team that was missing deadline after deadline, and instead of confronting the truth, which was that we had a lead who could not prioritize and a roadmap with eleven number-one priorities, I reorganized. I split the team in two, gave each half a crisper mandate, and felt very clever for about a month. Then both halves started missing deadlines, because the problem had never been the shape. The problem was that we were saying yes to everything, and no box on an org chart says no for you.
If you cannot write down, in one plain sentence, the specific problem the reorg solves that could not be solved any other way, you are not reorganizing. You are redecorating, and it will cost you six months.
You Are Fighting Conway's Law Whether You Know It or Not
Systems come to mirror the communication structure of the organizations that build them. This is not a cute observation; it is the single most reliable thing I know about software. If you have three teams, you will get three services, and the seams between them will land exactly where the teams do not talk. Reorganize the teams and you have just signed up to reorganize the software, whether or not you meant to.
This is where most reorgs quietly detonate. Leadership moves the boxes to optimize for some reporting-line elegance, gives no thought to the systems those teams own, and six weeks later the on-call rotations are a mess because the service someone built no longer maps to any single team. I inherited a ledger service once that had been owned, over eighteen months, by four different teams thanks to two reorgs. Nobody understood the whole thing. The knowledge had evaporated with each handoff. Every change to it took three times as long as it should have, and we were terrified to touch the parts that handled interest accrual.
If your reorg does not start from the systems and the domains they serve, and only then draw the team boundaries to match, you are going to spend the next year paying down a debt you created on purpose.
Nobody Wrote Down What Success Looks Like
Ask the person driving a reorg how they will know in six months whether it worked, and watch them reach for something vague about agility or alignment. That is a tell. A reorg without a measurable hypothesis is unfalsifiable, which means it can never be judged a failure, which means the person who ordered it never has to answer for it. Very convenient.
The one reorg I ran that actually worked started with a number. Our lead time from a merchant requesting a feature to that feature shipping was averaging around fourteen weeks, and most of that was handoff latency between a platform team and three product teams who all queued behind the platform team's backlog. The hypothesis was specific: embed a platform engineer in each product team, dissolve the central queue, and cut lead time to under six weeks. We measured it before, we measured it after, and it worked. It landed at just under five. That only happened because we had a target to steer toward and the honesty to have failed publicly if we missed it.
The Productivity Crater Is Real and Nobody Budgets for It
Every reorg has a cost that shows up nowhere in the announcement email. For roughly a quarter, output drops. People do not know who to ask. Relationships that took years to build get severed. The informal knowledge of who actually understands the reconciliation edge cases walks across the building or out the door. New managers spend weeks learning people they have never worked with. This is not pessimism; it is arithmetic, and I have watched it play out every single time.
What separates a competent leader from a careless one is whether they price this in. If your reorg's expected benefit is smaller than a full quarter of degraded output across every affected team, you should not do it. Too many leaders treat the disruption as free because it does not appear on any invoice. It appears everywhere else: in the release that slips, the incident that takes longer to resolve because the person who knew the system now reports three levels away, and the quiet resentment of engineers on their third manager in two years.
Sometimes It Is Just Theater for the People Above You
Let me say the thing that leadership writing usually leaves out. A meaningful share of reorgs happen because a new executive needs to look like they are doing something. A VP arrives, and within ninety days there is a reorg, because the reorg is proof of impact you can put in a board deck. It does not matter much whether it helps. It matters that it is legible as action.
I have been in the room where this was almost explicit. A new head of product wanted to "put his stamp on the org," his words, and the stamp was a reorganization that shuffled reporting lines for about forty engineers to no discernible benefit. I pushed back, lost, and watched us lose two senior engineers who were tired of the churn. If you find yourself reorganizing to demonstrate that you exist, stop. There are cheaper ways to prove you are working, and most of them do not cost you your best people.
Treating People as Fungible Boxes
Org charts encourage a specific kind of dehumanizing thinking. You start seeing engineers as interchangeable units of capacity that can be picked up and dropped into a new team like resource tokens in a strategy game. They are not. A team is a web of trust and shared context that took real time to grow, and you can shred it in an afternoon with a slide.
The good reorg respects the ties that matter. When we embedded platform engineers into product teams, I spent more time on who went where than on the structure itself. I moved people in pairs where I could, so nobody landed alone in a group of strangers. I asked people where they wanted to go and honored it more often than not. A few things I have learned to hold onto when the boxes move:
- Keep the people who share deep system knowledge together, or you will watch that knowledge evaporate within two quarters.
- Never split a team the week before a major deadline; the disruption tax and the deadline pressure will compound into a disaster.
- Tell people the real reason, because they can smell a sanitized one, and a sanitized reason costs you trust you will need later.
- Give the new managers time with their new reports before any big decisions land, not after.
The Perpetual Reorg Teaches People to Stop Caring
The worst damage is not any single bad reorg. It is the pattern. When an organization reorganizes every nine months, people learn a corrosive lesson: do not invest in your team, your systems, or your relationships, because all of it will be swept away soon anyway. Why fix the flaky test suite for a service you will not own by spring? Why mentor the junior who will report to someone else by summer?
I watched a company reorganize four times in three years, and by the end the engineers had gone functionally mercenary. Not lazy, just self-protective. They stopped forming attachments to anything because attachment had become a way to get hurt. Output was fine on paper and dead underneath. Stability is not the enemy of progress; it is very often the precondition for it. A team that trusts it will still exist next year will build things worth keeping.
What the Rare Good Reorg Actually Does
The one that worked shared a few honest traits. It had a specific, measurable problem it was solving. It started from the systems and domains, not from reporting-line aesthetics. It priced in the disruption and judged the benefit worth it anyway. It treated the people as people, not capacity. And critically, it was rare, so it carried weight instead of noise.
Good reorgs are also usually smaller than the ones that fail. The instinct to redraw everything at once is almost always wrong. The best structural change I ever made touched one seam, the platform-to-product handoff, and left everything else alone. Surgical beats sweeping nearly every time, because a small change is one you can actually reason about, measure, and reverse if you were wrong. The grand reorganization that touches every team simultaneously is impossible to evaluate, because you can never isolate what helped from what hurt.
Write the Post-Mortem First
The next time someone proposes a reorg, including when that someone is you, try a small act of discipline first: write the failure post-mortem in advance. Assume it is six months later and the reorg flopped. What went wrong? If you can write that document easily and it rings true, you have just found the reasons not to do it. If you genuinely cannot, if the only honest ending is that it worked because you had a real problem, a measurable target, and a plan for the human cost, then maybe you have one of the rare good ones. Most of the time, though, the exercise ends the reorg before it starts, and that is the exercise doing its job. The org chart is the cheapest thing to change and almost never the thing that is actually broken.