Reorgs Are Cheap. Everything Else Isn't.

A reporting structure describes more than who reports to whom. It shapes how decisions get made, how work gets measured, and how information moves between teams — and, underneath all of it, the technical architecture the product runs on. All of it gets shaped by whoever happens to be in those roles when it's built, whether or not anyone designs it that way, and the boundary between two teams becomes the boundary in the systems and processes between them. This is the mechanism behind Conway's Law.

None of it changes at the pace a reorg does. Strategy shifts, a new leader comes in with a different read on how the company should be organized, and team boundaries get redrawn — usually for a legitimate reason, so the move looks right at the time. But the decision-making frameworks, the metrics, the handoffs, the architecture that ossified around the old boundaries don't adapt in real time the way the org chart does. Every few years a company reorganizes, and a few years later someone looks at the dotted lines, the unclear ownership, the processes still built for a structure that no longer exists, and decides the fix is being intentional enough up front to design something resilient enough that the next reorg won't touch. It's a good instinct, but it quietly assumes something bigger: that the answer to "what should this org optimize around" will hold long enough to justify designing anything permanent around it. That assumption is usually the first thing to break.

At more than one company, like clockwork, the whole org went through a real restructuring every few years — vertically integrated around business lines for a while, then flipped horizontal around shared platforms, then back again. In some ways it was a useful shock to the system: it forced everyone to re-examine assumptions nobody had questioned in years. But every single time, it left the same debris behind — orphaned services, ownership and decision rights nobody had reassigned, metrics that no longer cleanly tied to any team's actual boundary, and approval chains that had landed by default on roles that didn't even exist anymore.

The instinct to fix this by finding the one true resilient design doesn't hold up either, because nobody can define "stable enough" before the fact — you only find out whether something was stable enough once the next reorg has already tested it, which makes durability something you back into by luck, not something you build toward on purpose. You could try anchoring to something that feels more durable than a specific structure — ownership clarity, reduced dependency, more autonomy for teams. Those aren't fixed targets either. They're what every reorg claims to be optimizing for, right up until a new executive walks in with a different idea of what ownership or autonomy should actually mean.

Ultimately this boils down to a mismatch in speed. Reorgs are cheap — redraw the lines, announce the new leads, done inside a quarter. Rebuilding the systems and processes to match is the opposite of cheap. Decision-making frameworks have to be renegotiated with whoever now holds them. Cross-team workflows have to be relearned by everyone operating inside them. Code, data, and ownership boundaries have to be redrawn without breaking what's running and without losing the institutional knowledge holding it together. That takes months or years, all while the business keeps operating around it. None of this gets solved with more planning. It's the permanent cost of one side of the equation moving faster than the other, and no amount of upfront design eliminates it, because the next reorg will always outrun whatever you built to survive the last one.

So a better question than "what's the right design?" is "how expensive is it to be wrong about this?" That turns the exercise from prediction into cost management, and it gives you something concrete to interrogate across any of these systems, technical or not. Start with whether something is anchored to what doesn't move when the org chart does — a regulatory requirement, how customers actually behave, a real physical or legal constraint — or if it's anchored to this year's strategic framing, which moves the moment the framing does. Then ask what it costs to be wrong: reporting lines are nearly free to redraw, but a data schema, a decision-approval chain, or a metric everyone downstream has built plans around is expensive to unwind, and that asymmetry is exactly where the scrutiny belongs. A third test, one of the more useful ones I've found: if every person moved to a different reporting line tomorrow, would this thing still make sense exactly as it is? A regulatory workflow typically survives that test. The reason product marketing reviews every customer-facing email before it ships usually doesn't — not because they own the message, but because four years ago, product marketing and support briefly reported to the same VP, and the review step never went away. And when you're genuinely unsure, look backward before you guess forward: audit where ownership or accountability has actually broken down before, in any function. It won't predict the next gap, but it's the closest thing you have to evidence of where one is likely to open again.

This is close to what Domain-Driven Design calls a bounded context: anchoring technical boundaries to a durable model of the domain instead of whoever's running it this year. Valuable prior art, but DDD is different because it manages complexity inside the architecture. What I'm describing sits a level higher by describing and attempting to manage how fast every system an organization runs on, technical or otherwise, can keep pace with how fast the organization itself is allowed to change.

None of this is a panacea, and it shouldn't be treated like one. Every one of these questions assumes you can tell, in the moment, what's actually durable from what just looks that way, and often you can't. A new executive's mental model doesn't arrive with a label reading "volatile internal preference." It looks exactly like the new strategy, because to the person holding it, it is. The actual discipline is asking these question before you're forced to react to the change, on a schedule you control instead of one an org chart imposes on you.

And if you set out to design things purely so they'll survive the next reorg, you're optimizing for the wrong thing... that's the same resilient-boundary trap from the other direction. The habit worth building is asking, intentionally and ahead of time, what should survive it. The ambiguity was always going to surface eventually. The only real choice is whether you're the one who surfaces it, or whether you get caught by it.