It never happens all at once. First a rumor in a hallway. Then a calendar invite labeled “All Hands.” Weeks later, the slide deck arrives with new boxes and arrows. By then, most people already know what’s coming: another reorganization, another attempt to redraw the map so the territory finally makes sense.

The presenter moves through the slides with practiced enthusiasm, but halfway through, someone in the back mutters, “Didn’t we try this two years ago?” A nervous laugh ripples through the room. Smiles tighten. “This time is different,” the presenter insists, clicking faster. But squint hard enough and you can see the same structure abandoned eighteen to twenty-four months ago, with “2.0” now tacked onto the title.

What most reorgs circle around is the same recurring fault line: how much control lives in the center versus at the edges. Strategy decks dress it all up with new terms, but the underlying choice rarely changes. In my corner of the world, Ops is where that argument always lands first.

Every company cycles through the same debate: embed Ops for speed, centralize for alignment, try a hybrid that satisfies no one, repeat. Each move feels justified in the moment, and each collapse feels predictable in hindsight. You don’t notice the loop until you’ve lived through it a few times.

What makes it all tricky is that both bets can work. Embedded teams really do catch problems earlier. Central teams do clean up the mess of competing definitions. Each approach solves something real, just not everything. Which is why companies keep swinging back and forth, convinced the next structure will finally hold.

We pretend organizational design is architecture, permanent structures on solid foundations. It isn’t. It’s more like an informed roll of the dice. You’re betting on where information needs to flow, which problems matter most right now, and whether proximity beats perspective. Like any gambler, we double down, convinced the next hand will be different. Embed deeper. Or we walk away from the table: centralize harder. Split the difference. Each bet feels right until it doesn’t, but by then we’re already shuffling for the next deal.

Embedded teams bet on proximity. Plant Sales Ops in the weekly pipeline review and they’ll catch the offhand mutter about “the quote approval process taking too long.” Put Product Ops in sprint planning and they’ll see technical debt pile up in real time. Context flows sideways, through overheard comments and evasive phrasing. I once sat through a sales standup where nothing official was announced, but everyone somehow knew quotas were about to reset, signaled in the VP’s refusal to give numbers.

But proximity warps perspective. In Sales, every problem starts to look like a pipeline problem. With Product, every answer turns into a technical fix. Without some gravitational center, embedded teams drift until they become indistinguishable from their hosts, just with better spreadsheets.

Centralized teams bet on altitude. From above you can see patterns: three teams building the same dashboard, four different definitions of a “qualified lead,” everyone optimizing for their own local maximum while the bigger machine grinds. But altitude brings its own kind of blindness. Dashboards glow green but hide building issues. Processes look elegant but no one follows them. Central teams spend months aligning on definitions while the organization builds workarounds for the workarounds.

The real cost is exhaustion. Every reorg resets trust, forcing people to hedge. They keep old relationships warm, build shadow processes that can survive either model, even keep parallel toolkits depending on the era.

That kind of adaptation looks clever, but it eventually corrodes belief. The people who care most burn out first, tired of re-explaining the same value, re-learning the same lessons, re-building the same relationships. The rest learn a different lesson: that caring too much about any structure leaves you exposed. They become organizational nihilists, going through the motions of whatever model is current while knowing it is temporary. They keep their heads down, nod through the slide deck, and treat every new structure as theater. The joke over drinks is not pure cynicism; it's a survival tactic.

Reorgs are rarely about learning anyway. The deck always includes a “lessons learned” section, as if we’d been running controlled experiments. But I’ve been in the rooms. The reasons are usually much messier. Embedded feels chaotic, so someone senior wants more control. Centralized feels slow, so someone else wants more autonomy. A new exec arrives with their playbook. A key person leaves and everyone shuffles to cover the hole.

It ultimately isn’t science, but hope. If we just arrange the boxes differently, information will flow differently, decisions will be faster, problems will be clearer.

Over time, the patterns become obvious: start with embedded because it feels responsive, watch it fragment, overcorrect to centralized because it feels controlled, watch it calcify, try a hybrid that gets the worst of both, return to embedded “but smarter this time.” No move feels wrong while you’re making it. Only afterward does the pattern become embarrassingly obvious.

The smartest ops leader I knew didn’t bother fighting the loop. She made her team restructure-proof. Light documentation that could travel. Relationships across functions. Tools that worked in any configuration. When I asked what she thought about a latest shift, she just shrugged: “We’ll keep doing the work.”

That’s the real truth. The best teams don’t even try to “solve” centralized versus embedded. They make the structure irrelevant. They build relationships strong enough that information flows regardless of reporting lines. Metrics clear enough that alignment doesn’t require another meeting. Trust deep enough that proximity and perspective balance naturally. Over time, they stop tripping over the same fault line that keeps reappearing in every reorg. But that’s culture, not a reorg. And culture can’t be fixed with a PowerPoint.

Last month, I heard about yet another reorganization at a friend's company. A new template, a new slogan, probably the same arrows pointing a new direction. I was asked if I thought it would work.

“It’ll work until it doesn’t,” I said.

Because organizational design isn’t a problem you solve once and for all. It’s a condition you manage, like weather. The org chart is just a bet on where the work happens. The work itself keeps happening anyway: in the gaps, in the overlaps, in the undefined spaces where people who care about outcomes figure it out. Every reorg promises to eliminate those gaps.

But those gaps are where the real organization lives.

Like this? Subscribe via email here.