Writing
Scaling Engineering Teams: Lessons from Tech Giants
I've now seen engineering organizations at most of the sizes that matter — startups of a few hundred people, Uber during hypergrowth, Google at full scale, and a few stops in between. The same paradox shows up everywhere. Teams need more structure to coordinate as they grow, but structure is exactly what kills the judgment and speed that made the early team good. No company gets to skip this tradeoff. You only get to manage it well or badly.
An operating system, not rules
The framing that has held up best for me: as you scale, you're adding an operating system, not adding rules. An operating system tells a process where it can run freely and where it has to go through a syscall. The organizational equivalent is everyone knowing where their team can move independently and where coordination is mandatory. Bureaucracy is what you get when nobody made that distinction, so everything requires a meeting.
The mechanism, concretely, is local autonomy paired with shared contracts. The contracts are the boring stuff: ownership maps, service interfaces, SLOs, review standards, incident process, planning cadence. Every one of them sounds like overhead until you've watched a 2 a.m. incident where nobody can name the owning team. Without the contracts, autonomy becomes fragmentation. With too many of them, coordination becomes the job itself.
Standardize the interfaces
The discipline that keeps the balance is standardizing the interfaces, not the implementations. Teams should be free to make local design choices wherever the blast radius is local. What the organization actually needs to be consistent is behavior at the boundaries: what a service promises, who is on call for it, what a launch has to pass, who owns the data, how things get deprecated. Most scaling failures I've watched got this backwards — heavy standardization of implementation details that didn't matter, and total ambiguity at the boundaries that did.
A few questions I use to check whether an org's operating system is actually working. Can every production service name its owning team and escalation path without anyone opening a spreadsheet? Do cross-team dependencies surface before planning commitments are made, or after? Do architecture reviews remove ambiguity, or just add ceremony? Are platform teams measured by whether anyone adopts what they build, or only by whether they shipped it?
One more thing that quietly goes wrong as orgs grow: the senior technical people drift out of the architecture and into pure coordination, until the people setting direction can no longer evaluate it. The org's operating system needs maintainers the same way its software does, and the maintainers have to still be able to read the code.
The point of all this structure is mundane: make coordination predictable so engineering judgment has room to operate. When process starts existing for its own sake — when the review is theater and the doc exists for the doc's sake — that isn't scaling. That's scar tissue.