Most engineering leaders think scaling is about hiring.

And honestly, that instinct makes sense — more work, more people, problem solved. But in practice, scaling engineering is mostly about scaling ownership. The teams that succeed aren’t necessarily the ones with the most engineers, the most process, or the fanciest org charts. They’re the ones that can keep ownership close to the work as the organization grows.
That sounds simple until you’ve experienced the moment it breaks down at 2 AM.

I’ve had the chance to see engineering organizations at very different scales — from early startup environments to larger companies like Google, Netflix, Meta, and JFrog.
Every company is unique, but the patterns are surprisingly consistent.

The biggest takeaway is this: every growth stage introduces a new coordination tax.
The challenge isn’t eliminating that tax.
The challenge is preventing coordination overhead from growing faster than the company does.

The First 20 Engineers: Optimize for Builders

At around 20 engineers, speed is your biggest advantage, and process is often your biggest enemy.
Everyone sits close to the product. Engineers talk directly to customers.
The person writing the code can usually explain exactly why it exists and what it connects to. It’s a genuinely magical phase — and it’s also temporary, so it’s worth enjoying while it lasts.

At this stage, ownership should be brutally simple: teams own services end-to-end, carry their own on-call rotation, deploy their own code, and fix their own incidents.
No exceptions.
One of the strongest signals of a healthy engineering culture is whether the people building the software also feel the consequences when it breaks. If your team gets paged because their service is down, reliability becomes surprisingly important. Funny how that works.

The Platform Team Trap

One mistake I see repeatedly at this stage is creating a platform team too early.
The logic is completely understandable — someone notices that everybody is independently building CI pipelines, setting up monitoring, and solving the same deployment problems.

The natural reaction is, “we need a platform team.” And you know what?
That instinct isn’t wrong.
It’s just early.

At 20 engineers, the cost of coordination is often higher than the cost of duplication.
A few redundant solutions are cheaper than introducing another organizational boundary and the meetings, hand-offs, and dependency management that come with it. This tradeoff becomes even more relevant in the AI era.

Generating code is now cheap.
Creating clear ownership is still expensive. The bottleneck is no longer writing software — it’s understanding who should maintain it six months from now. That’s a human problem, not a tooling problem.

Around 50 Engineers: The Coordination Tax Arrives