Centralize. Embed. Repeat.

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 slides with practiced confidence, 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. Squint at the new structure long enough and you can usually find the old one underneath, rebranded, with “2.0” appended to the title.

Most reorgs circle the same fault line: how much control lives at 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 lands first. Every company cycles through the same debate: embed teams for speed, centralize for alignment, try a hybrid that satisfies no one, and then do it again.

Embedded teams catch problems centralized ones miss. 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. 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. No escalation. No committee. Just someone close enough to notice.

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 spot what local teams miss: three departments building the same dashboard, four definitions of “qualified lead,” everyone optimizing their own corner while the larger machine grinds. But 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 documentation was immaculate. Meanwhile, the organization had built workarounds for the workarounds, and the people who built them had stopped mentioning it in meetings where the central team might hear.

What accumulates is a kind of unnamable tiredness.

I’ve done some version of this myself. Kept a parallel set of notes because I didn’t trust the system to remember what mattered. Stayed in touch with people I technically no longer worked with because the work still seemed to run through them anyway. Sent certain things sideways instead of up, because “up” had stopped being a reliable path for anything that required judgment.

You can call that foresight if you want. It rarely feels like that from the inside. It feels like noticing where things are likely to break and trying not to be standing there when they do.

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 stakeholders who’ll be gone in two years anyway. The rest learn a different lesson. They stay competent, stay present, but operate at a careful distance from whatever structure is current. Engagement becomes conditional. Commitment narrows to the work, not the architecture around it.

You can spot them in the All Hands: nodding at exactly the right moments, asking a question that signals engagement without signaling commitment. The moment the meeting ends, they text the same three people they always texted, route work through the same informal channels, maintain the same relationships the new org chart technically dissolved. The joke over drinks about “seeing this movie before” isn’t pure cynicism. It’s a survival tactic that hardened into a worldview.

The smartest ops leader I ever worked with didn’t bother fighting the loop. Dana 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.”

In practice, her team maintained a single shared doc mapping 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 later, the doc stayed the same. 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, those relationships would be the only thing that transferred cleanly. “Org charts change all the time. My relationships don't.^[1]

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 would 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.”

The best teams don’t resolve the structure debate. They make sure the work still moves when the structure changes. Information keeps flowing because people know who to call. Process holds because someone wrote it down in a way that survives handoffs. When the org chart shifts, they don’t start over.

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

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

Organizational design is a condition you manage, like weather. Some seasons demand more centralization. Some demand more autonomy. The skill isn’t picking the right structure forever. The skill is knowing when the current one 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 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.

Those gaps are where the organization actually runs.