Aug 4, 2026

Scaling an engineering team isn't about hiring more engineers

Growing an engineering organization from around 20 to 65+ taught me that headcount is only one part of scaling.

• #engineering-leadership
• #scaling
• #teams

Going from around 20 engineers to 65+ sounds like a hiring problem.

It isn’t.

Hiring is certainly part of it — I ended up writing most of the roles myself and running a good chunk of the interview loops for that stretch.

But the interesting problems start after the people arrive.

At 20 people, you can still know most of what’s happening.

You probably know who owns what.

You know which projects are in trouble.

You can ask someone directly when something doesn’t make sense.

That stops being true surprisingly quickly.

Communication starts becoming expensive

At some point, adding another engineer doesn’t simply add another engineer’s worth of capacity.

It also adds another set of relationships.

Another person who needs context.

Another person who can be blocked.

Another person who might need to coordinate with someone else.

The organization becomes a graph.

And the graph gets complicated.

This is where structure starts helping

We introduced clearer ownership and a pod-based delivery model as the organization grew — each pod owning a product area end to end, rather than routing every cross-team question through a lead.

Not because hierarchy was the goal.

Because people needed to know what they owned, what their team owned, who made a given call, and who they actually depended on.

That clarity became more valuable as the team grew.

The manager becomes a different kind of bottleneck

When you’re managing a small team, it’s easy to become the person who knows everything.

That feels useful.

It’s also dangerous.

At larger scale, if every decision comes through you, you’ve built a queue.

The answer isn’t working harder.

It’s creating more people who can make good decisions without you.

That means delegation, but not delegation as “here, you take this task.”

It’s giving someone enough context and ownership to actually own an outcome.

Growth changes the job

The biggest lesson I took from scaling the organization was that the techniques that work at 20 people don’t necessarily work at 65.

You need different communication patterns.

Different ownership models.

Different leadership layers.

Different expectations.

The onboarding process changed the most, honestly — new hires needed a real path to being productive without me personally walking them through the system, which is its own kind of scaling problem separate from the org chart.

Scaling isn’t just adding people. It’s redesigning the system around the people you’ve added — and admitting that the system that got you to 20 wasn’t built for 65.