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, now with “2.0” tacked onto the title.

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 gambling. You’re betting on where information needs to flow, which problems matter most right now, and whether proximity beats perspective. Like any gambler on a losing streak, we keep doubling down, convinced the next hand will be different. Embed deeper. 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. Sit too long with Sales, and every problem looks like a pipeline problem. Sit with Product, and everything needs a technical solution. 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 global system quietly fails. But altitude brings its own blindness. Dashboards glow green while the business burns. 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 is a reset on trust, on who you call when something breaks. After the second or third reshuffle, people hedge. They keep old relationships warm, just in case. They build shadow processes that can survive either model. One ops manager told me she kept two versions of her toolkits: one for centralized eras, heavy on systems thinking, and one for the embedded era, all business metrics and speed. “I just check the org chart and know which deck to use,” she said.

That kind of adaptation looks clever, but it 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 is naive. They become organizational nihilists, going through the motions of whatever model is current while knowing it’s temporary. “What’s our operating model?” becomes a joke told over drinks, answered with a shrug and “Check back next quarter.”

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 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 the collective reorganizes around the gap.

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

Over time, the pattern becomes obvious: start with embedded because it feels responsive, watch it fragment, overcorrect to centralized because it feels controlled, watch it ossify, 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 companies don’t “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. But that’s culture, not a reorg. And culture can’t be fixed with a PowerPoint.

Last month, I heard about yet another reorganization. A new template, a new slogan, probably the same arrows pointing a new direction. Someone 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.

That’s not a bug in the system. That is the system.

Like this? Subscribe via email here.