There's a genre of writing about organisational design — I keep running into a version of it from the Stay SaaSy corner of the internet — that treats team structure as something you get right once, the way you get an architecture diagram right once. Draw the boxes, assign the owners, ship the reorg memo, move on to the actual work.
I don't think that's how it works in practice, and I think the mismatch is expensive. Structure isn't a diagram you finalise. It's a bet about what will be hard next quarter, and most reorgs are placing that bet against last quarter's evidence.
The reorg that fixes the last fire
Here is the pattern I've watched play out more than once, at more than one company. Something breaks at a boundary — two teams both think they own a piece of the checkout flow, or nobody owns the retry behaviour between two services, or a release gets held up because three teams have to sign off and none of them feel accountable for the delay. The org responds, reasonably, by redrawing the lines so that exact seam doesn't happen again. New team, clearer ownership, a RACI chart nobody will read past week two.
Six months later a different seam causes a different fire, usually in a place the previous reorg didn't anticipate because it was optimised against last quarter's constraint, not next quarter's. The org redraws the lines again. Everyone involved did something locally sensible — you fix the thing that just hurt you — and the aggregate effect is a structure permanently one incident behind the shape the business actually needs.
A reorg that answers "what just went wrong" is a postmortem wearing an org chart. It's rarely a strategy.
Betting on the next constraint instead of the last one
The alternative isn't "reorg less" — reorg fatigue is real but it's a symptom, not the disease. The alternative is choosing structure against what you expect to be hard next, which requires actually having a view on that, stated out loud, that the structure is a bet on.
If the next six months are about scaling a system that currently handles one region to handle five, the org should be drawn around the axis that will bend under that load — probably data residency and latency, probably not the axis the last incident happened to expose. If the next six months are about shipping three adjacent products fast with a small team, the org should optimise for low coordination overhead between people who already trust each other, even if that means temporarily fuzzy ownership somewhere that isn't under near-term pressure.
This only works if the bet is explicit. "We are structuring around X because we believe Y will be the constraint" is a sentence a leadership team can write down, disagree with, and revisit when Y turns out to be wrong. "We are structuring this way because it's how it's always been" or "because that's what fixed the last incident" isn't a bet at all — it's inertia with a chart attached, and inertia can't be argued with because it was never a claim in the first place.
Conway's Law is a description, not a strategy
Everyone in this conversation eventually cites Conway's Law — systems end up mirroring the communication structure of the organisations that build them — as though naming the phenomenon were the same as using it well. It's a description of what happens by default, not a design principle. Using it well means asking which communication structure you want your system to mirror in a year, then building the org toward that shape deliberately, rather than discovering after the fact that your service boundaries perfectly replicate whichever team happened to exist when the API was first sketched on a whiteboard.
That's the actual discipline: state the bet, draw the org against it, and revisit the bet on a cadence — not "whenever something breaks badly enough that leadership notices." Teams that ship consistently aren't the ones with the best org chart. They're the ones willing to say out loud what they think is coming, and structure themselves for that instead of for what already happened.