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

Something shifts around 50 engineers, and it catches a lot of leaders off guard. It’s not that the engineers got worse or that the codebase got fundamentally harder. It’s that communication, which used to happen naturally and invisibly, now requires real effort. At 20 engineers, information spreads through the room. At 50, different groups start optimizing for different things, and you’ll start hearing “wait, I didn’t know they were doing that” on a weekly basis.

Planning gets harder — not because anyone became less capable, but because dependencies became real. This is usually where leaders start introducing process, and here’s the honest truth: some of that process is genuinely necessary, and some of it is organizational theater that makes people feel in control without actually solving anything. Learning the difference is one of the most important leadership skills you can develop at this stage.

Process Is Usually a Symptom

A useful question to ask whenever someone proposes a new process: “What problem are we actually trying to solve?”
Many organizations add process because communication is failing, ownership is unclear, or priorities keep shifting.

The process becomes a band-aid.
Sometimes that’s appropriate — a well-designed band-aid can help while you heal the real wound. But sometimes it’s like adding more dashboard alerts to fix a broken engine. You’re treating the symptom, not the cause.

The best leaders I’ve worked with treat process as a tool rather than a belief system.

At Netflix, there’s historically been a strong emphasis on aligning people around context rather than controlling them through process.
At Google, many systems evolved because scale genuinely demanded consistency.
These aren’t contradictory philosophies — they’re different tradeoffs for different environments.
The key insight is that process should emerge from a real problem, not from an aspiration to look like a mature company.

Code Review Becomes the New Bottleneck

Here’s a shift that a lot of organizations haven’t fully reckoned with yet: a decade ago, writing code was the expensive part. Today, AI can generate large portions of code in seconds. That changes the economics of software development in a pretty fundamental way, but many teams are still optimizing for code production rather than code confidence.

The real bottleneck is increasingly about reviewing code, understanding changes, maintaining systems, and preserving architectural integrity over time.

I’ve started seeing teams where pull requests pile up faster than reviewers can handle them. The result is predictable — longer queues, slower releases, reviewer burnout, and quietly declining quality.
The new challenge isn’t “how do we write more code?” It’s “how do we maintain confidence in the code being written?” That’s a genuinely different problem, and it requires a different answer than just hiring more engineers.

Around 200 Engineers: Scaling Ownership Becomes the Job

At roughly 200 engineers, something fundamental changes in what leadership actually means. You’re no longer primarily managing software development — you’re managing systems of teams.
Organizational design starts mattering as much as technical architecture, which can feel disorienting if you came up as an engineer or even an early engineering manager. A poorly designed organization can make excellent engineers ineffective. A well-designed one can make average teams surprisingly productive.

The Real Cost of Coordination

One of the most underappreciated challenges at this scale is the cost of coordination, especially across locations and time zones. Globally distributed teams offer real advantages — access to talent, around-the-clock development velocity, local customer support. But coordination has a cost that compounds in ways that aren’t obvious until you’re living it. Every cross-team dependency introduces friction. Every shared responsibility creates ambiguity.
Every unclear ownership boundary slows decisions.

At smaller scales, people solve coordination problems through quick conversations. At 200 engineers, conversations stop scaling. Leaders often discover this the hard way, when they realize that every meeting is a tax, every dependency is a tax, and every unclear interface between teams is a tax. The goal becomes minimizing organizational drag while preserving alignment — and getting that balance right is genuinely hard. It’s not a problem you solve once; it’s one you manage continuously.

This Is When Platform Teams Actually Make Sense

I want to be clear: platform teams aren’t bad. They’re incredibly valuable.
They’re just often created too early, before the organization has accumulated enough duplicated pain to justify the coordination cost. Around 80–100 engineers and beyond, the calculus starts to shift. Infrastructure duplication increases meaningfully. Reliability expectations go up. Security requirements tighten. Developer productivity becomes something you can actually measure and optimize.

At this point, a strong platform organization can create real leverage — if it’s built with the right mindset. The key distinction is that a platform team should exist to accelerate product teams, not to become a gatekeeper or a bottleneck. The best platform teams I’ve seen behave like product teams: they have customers (who happen to be engineers), they talk to those customers regularly, and they measure success by whether those customers are moving faster and sleeping better.

Oncall Tells You the Truth

If you want to understand how mature an engineering organization really is, skip the dashboards and architecture diagrams and just look at oncall.

Specifically: Are alerts actionable, or are engineers drowning in noise?
Do teams genuinely own their incidents, or does everything escalate to the same three people?
Are postmortems resulting in actual improvements, or are they just documentation exercises?
Does reliability get better over time, or does the team keep fixing the same classes of problems?

Healthy organizations treat oncall as a learning mechanism — a feedback loop that makes the system better. Unhealthy ones treat it as punishment, something to be survived rather than learned from. The difference becomes obvious quickly, and it tells you a lot about whether ownership is real or just nominal.

The Public Company Shift

One of the biggest transitions I observed at JFrog compared to earlier-stage environments is what happens when growth introduces external accountability. Public companies can’t optimize exclusively for speed.
They have to optimize for speed and predictability simultaneously, which is a much harder problem. Customers expect reliability. Investors expect consistency. Security and compliance requirements expand in ways that feel bureaucratic but are genuinely necessary.

The challenge is preserving startup energy without creating startup chaos — and honestly, this is where a lot of companies overcorrect. They become process-heavy, decision-heavy, meeting-heavy, and the organization slows to a crawl right at the moment when it should be capitalizing on its momentum. The best leaders resist this instinct. They introduce just enough structure to maintain quality and predictability while preserving the ownership culture that made the company successful in the first place. That balance is difficult to strike and even harder to maintain, but it’s where most of the real leverage lives.

What AI Changes — and What It Doesn’t

Every few years, the industry finds a new reason to believe that organizational fundamentals no longer apply.

A few quick examples:
1. Cloud computing was going to eliminate ops teams.
2. Microservices were going to make coordination effortless.
3. Containers were going to solve deployment.
4. DevOps was going to dissolve the wall between building and running software.

Now it’s AI. And to be fair, AI is changing software development in meaningful ways — faster than most of the previous waves.

But it isn’t changing the importance of ownership. For now.
If anything, it’s increasing it.
When code generation becomes nearly free, you need stronger ownership models, not weaker ones, because the volume of code requiring review, maintenance, and architectural coherence goes up dramatically.
Someone still needs to understand the system, make good architectural decisions, review changes with genuine judgment, handle incidents, and own outcomes.
It might be that in the (near) future – we can forget all that, as the LLMs will be so strong that we could ‘give’ them a free hand to do everything… Maybe.

Final Thoughts

The common thread I’ve seen across startups, large tech companies, and public companies isn’t technology.
It’s clarity — clarity of goals, clarity of priorities, and clarity of ownership.
As organizations grow from 20 to 50 to 200 engineers, the technology changes, the org charts change, and the processes change. Ownership remains the constant.

The tradeoffs along the way are real and genuinely hard.
Moving faster means accepting some duplication. Creating platform leverage means accepting some coordination cost. Scaling globally means accepting some communication friction. There’s no version of growth that’s free. The goal isn’t to avoid these tradeoffs — it’s to make them consciously, with your eyes open, rather than stumbling into them.

If there’s one thing I’d want every engineering leader to take away from this, it’s simple: scaling engineering is not primarily about adding engineers. It’s about ensuring that every engineer knows exactly what they own, why they own it, and what happens when it breaks.
Everything else — the org charts, the processes, the tooling — is in service of that.
Get ownership right, and a lot of the other hard things get easier.