Centralize. Embed. Repeat.

Every Operations function has an argument that keeps snapping back, depending on what's happening in the company around them: should the people doing the work sit together, or should they sit with the people they're doing it for?

Centralize or embed. The terminology changes a bit depending on whether you're in Operations, Business Operations, Finance, or some other corporate-consigliere job, but the question refuses to stay dead. The question of "where does it all sit?" rises again, usually right after your team's previous and you-thought-definitive answer has had enough time to percolate through your org and create a few new problems.

The team has gotten way too far away from the actual work. That's the centralize problem. Okay, fine: embed Ops. Uh oh, now you look up from your desk and see three teams building similar but different dashboards, four different enough definitions of the same metric, and nobody owning anything end to end. So what about a hybrid? Hybrids split the difference, which leaves basically no one truly happy.

I used to find the repetition of the question itself uncomfortable, or even embarrassing. Surely we had learned something from the last version? But I've come to believe the repetition is the thing to pay attention to, like breathing. The problems created by one structure can gradually morph into the current, best argument to try the other (again).

The most persuasive case for centralization usually has familiar ingredients: similar-but-different-enough versions of the same key thing, way too many local exceptions (are they even exceptions anymore?), different teams solving identical problems with unique tools and their own overlapping definitions. There's no one at altitude long enough to notice that the company is solving the same problem three times.

And for a while, centralization feels like a revelation, feels good. You have standardized things and can finally see across functions. The problem creeps in later.

The central team starts asking for things to make their way to the center: requests, meetings, dashboards, tickets. Reality becomes a bit filtered.

The local weirdness becomes harder to see and hear, but it's still out there.

Which is usually right around when embedding starts to sound like common sense. Put people back in the room and make sure they hear the complaints and problems and almost-tickets firsthand.

Proximity is incredibly useful this way. You learn the official way and the shadowy ways. You notice everyone discusses with great seriousness a metric that has a shifting definition depending on which meeting you're in. And now you have stuff to go look at and work on before it ever even has to become an official project with a steering committee.

For a while, that proximity feels like just the aspirin you've needed. That partner team feels a bit more heard, and their trust builds. Nobody has to spend the first twenty minutes explaining why their request exists. Decisions are just made.

And the residue of those decisions starts to accumulate.

Embedded employees get good at solving problems for the people directly around them. Getting good at solving those problems is precisely what they were sent there to do, so this initially seems... exactly what was asked for. The impact is felt later, when someone points out another embedded team has built something remarkably similar.

Nobody did anything particularly wrong either. But as humans, it always feels like there's at least a small trail of wrong behind every prior decision that led to this point.

Six months later, the results of a local decision are still there, yet the reason those results exist is nowhere to be found.

There might be a very good reason one team needed their slightly different definition. Pick your poison: some constraint everyone understood at the time to be really constraining, or one large customer, or one system or integration that couldn't do something essential at that time.

Except now, today, there are three competing definitions confusing most everyone and the original constraint has faded away into hallway rumors. From far enough away, this looks like bad to poor coordination. Sometimes it probably was somewhere on that coordination spectrum (not poor, and not bad either, but definitely not good). But you're usually looking at decisions that made some kind of sense at the time, when the context was front and center.

Context has a half-life. So somebody gets asked to clean up what remains: tools, definitions, ownership. And centralization, which not long ago was at best only helping to cause your headache, starts looking like aspirin again.

For a long time, I sort of knew something in my bones but couldn't put my finger on it perfectly, and I think the distillation is just something like: each structure is really good at generating enough evidence that the opposite is needed. This is pretty true of a lot of things in life. Some questions are context dependent, sometimes you need one and then later the other.

Annoyingly, complaints from either side of the argument can often be right. It's just that, at different points in a given cycle, one is usually more right. Which means doing it a different way now isn't necessarily evidence that how it was done before was wrong, or that that way failed. Sometimes it worked long enough to create a new problem.

Once I started thinking this way, I became less interested in the question as a matter of philosophy. There is no mythical, mathematically provable answer on whether to centralize-or-embed.

Once I could set philosophy aside, I became more interested in what does persist. The answer changes, but some things don't reset with it.

Relationships are one of those things. If I've worked with someone closely enough that they know what I probably mean when I send them an unhelpful message like “this is weird,” that trust doesn't disappear because one of our boxes moved somewhere else on an org chart. That trust is portable, a credibility balance you can transfer to the new world, even as the structure changes. ^[1]

The other thing that travels reasonably well in the chaos of doing things another way: whatever somebody bothered to write down. I mean the truly useful stuff: portable context, a decent explanation. Pretty good shelf life on that.

So when somebody draws some new org chart with every bit of responsibility cleanly delineated, everyone spends a few weeks learning exactly where they sit, and for a while this question goes very quiet. Answered for now. Until...

We’re too centralized. No, we're too embedded.

Ah. There you are.