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 up with new language, but the underlying choice rarely changes. In my corner of the world, Ops is where that argument always lands first. And every company cycles through the same debate: embed Ops for speed, centralize for alignment, try a hybrid that satisfies no one, repeat.

Both approaches can work. Embedded teams really do catch problems earlier. I once sat in a sales standup where a rep mentioned, almost as an aside, that she'd started copying her quotes into a personal spreadsheet because the approval workflow "felt broken." Nothing official, no ticket filed. Just an offhand comment. The embedded ops person in the room caught it, traced the issue to a permissions change from three weeks prior, and fixed it before anyone escalated. That's proximity doing what proximity does.

But I've also watched embedded teams drift. After eighteen months inside a product org, one ops lead had absorbed so much of the team's worldview that every problem looked like a tooling problem. When sales complained about forecast accuracy, she proposed a dashboard overhaul. When finance flagged inconsistent deal terms, she suggested a new approval workflow. The actual issue, that the team had stopped following the existing process because it was too slow, never surfaced. She'd lost the altitude to see it.

Centralized teams have the opposite problem. They can spot patterns that local teams miss: three departments building the same dashboard, four different definitions of "qualified lead," everyone optimizing for their own corner while the larger machine grinds. But altitude brings its own blindness. I remember a central team that spent two months aligning on a company-wide metric definition, only to discover that no one used the metric they'd so carefully defined. The dashboards glowed green. The processes looked elegant in the documentation. Meanwhile, the organization had built workarounds for the workarounds.

Every reorg promises to fix this. None of them do, at least not permanently.

The real cost is exhaustion. Every restructure resets trust, forcing people to hedge. They keep old relationships warm, build shadow processes that survive either model, maintain 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 with new stakeholders who'll be gone in two years anyway. 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 won't last. They keep their heads down, nod through the slide deck, and treat every new structure as theater. The joke over drinks about "seeing this movie before" isn't pure cynicism. It's a survival tactic.

The smartest ops leader I ever worked with didn't bother fighting the loop. Her name was Dana, and she ran ops for a mid-sized product org that had been through three restructures in four years. When I asked how her team stayed effective through all of it, she looked almost amused.

"We stopped organizing around the org chart," she said. "We organize around the work."

What that meant, in practice: her team maintained a single shared doc that mapped every recurring ops process to a person, regardless of where that person technically reported. When the company centralized, the doc stayed the same. When they re-embedded eighteen months later, the doc stayed the same. The reporting lines moved. The work didn't.

She was fanatical about what she called "portable trust." Her team built relationships with finance, sales, product, and engineering that existed independent of structure. Monthly coffee chats, not because they were required, but because when the next reorg hit (and it always hit), those relationships would be the only thing that transferred cleanly. "Org charts are temporary," she told me once. "Relationships compound."

Her documentation philosophy was equally deliberate. Nothing longer than a page. No process doc that couldn't be understood by someone outside the team. "If it requires institutional knowledge to read, it dies when I leave," she said. Everything was written for the next person, the one who'd inherit the role after the next restructure scrambled the deck.

The last time I talked to her, another reorg was brewing. Someone asked what she thought about it.

She shrugged. "We'll keep doing the work."

That's the real truth about the centralized-versus-embedded debate. The best teams don't solve it. They make it irrelevant. They build relationships strong enough that information flows regardless of reporting lines. They create documentation clear enough that alignment doesn't require another meeting. They cultivate trust deep enough that proximity and perspective balance naturally. But that's culture, not a reorg. And culture can't be shipped in 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. He 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 then move on. It's a condition you manage, like weather. Some seasons you need more centralization. Some seasons you need more autonomy. The skill isn't picking the right structure forever. The skill is knowing when the current structure has stopped serving the work, and having enough trust banked that the transition doesn't break everything.

The org chart is just a map. 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 together. Every reorg promises to eliminate those gaps.

But those gaps are where the real organization lives.

Like this? Subscribe via email here.