Vertical or Horizontal Orgs

I've lost count of the reorgs I've lived through. Most announced themselves as something profound — a new leader, a new strategy, new priorities painted on the wall. But strip away the slideware and the same lever keeps getting pulled back and forth. We go vertical. A few years later, horizontal. Then someone arrives and we go vertical again. After enough cycles you stop seeing chaos and start seeing a pendulum — and the question isn't which end is right, but when each one is.

A vertical org is built around outcomes. You take a product, a customer, a mission, and you give one team everything it needs to ship it — its own engineers, its own designers, its own slice of the roadmap. Nothing waits on anyone else. The team owns the result end to end, and ownership is a powerful drug. Decisions get made in a hallway instead of a steering committee. Things ship.

A horizontal org is built around capability. Instead of every team building its own auth, its own data pipeline, its own deployment story, you carve those into platforms everyone shares. One team does the hard thing once and the whole company borrows it. The promise is leverage: stop paying for the same wheel ten times.

And the choice outlives the org chart, because the org chart becomes the architecture. Conway's Law — systems come to mirror the teams that build them — means vertical orgs grow tall, self-contained stacks that duplicate each other, while horizontal orgs grow shared layers everyone plugs into. You aren't just choosing who reports to whom; you're choosing the shape of the software.

Said that way, horizontal sounds like it simply wins — but a platform is a bet on a future you can't yet see, and when you don't know what you're building, the wheel you generalized is the wrong one. Early on, the duplication a horizontal org exists to kill isn't waste; it's how you learn what's worth sharing. Premature platformization is just speculative work with a nicer name. So early products want to be vertical: speed and ownership beat efficiency when what you're optimizing is product-market fit, found by shipping again, not by building for a scale you haven't reached. Let teams sprint, let them duplicate, let three solve the same problem three ways; two answers were wrong anyway.

The horizontal moment comes later, and it announces itself: the fifth team building the same service, a migration dragging across a dozen codebases because nobody owns the shared layer. The duplication that was cheap discovery has become an expensive tax, and now doing it once is real leverage — you finally know what "it" is. The temptation is to skip the wait and do both, but a matrix collects the costs of each without the benefits: the dependencies of horizontal, the duplication of vertical. A company large enough does run both — vertical at its frontier, horizontal at its core — but more often the matrix just avoids admitting which stage you're in.

And every swing costs something the slide never counts. A reorg resets ownership, scrambles the relationships that get work done, and asks good people to re-earn trust they'd already banked. Do it for a real change of stage and they'll forgive the disruption. Do it for a new leader's taste and they learn to keep their heads down until the next one arrives.

So read the stage honestly. If you're still hunting for fit, go vertical and let teams own their outcomes. Once the duplication starts to ache, go horizontal and build the platform you finally understand. Don't reorg for the slide. Reorg for the stage you're actually in.