Scaling from 8 to 20 Engineers: What Actually Changes

There's a moment when your team crosses about 12 people where everything you relied on stops working. I hit that wall this year scaling from 8 to 20+ engineers, and the lessons were expensive.

Communication breaks first

With 8 engineers, a daily standup actually works. Everyone knows what everyone else is doing. Context travels through osmosis. At 20, standup becomes a 40-minute status report nobody listens to. I had to kill the all-hands standup and move to team-level syncs with cross-team liaisons.

The real issue isn't information flow — it's trust. When I knew every engineer personally, I could sense when someone was stuck. At scale, I had to build systems that surfaced blockers without requiring me to be in every conversation.

What I actually changed

Delegation became non-negotiable. I promoted two senior engineers to tech lead roles and gave them actual authority — not just responsibility without power. That meant letting them make decisions I disagreed with sometimes.

Documentation replaced tribal knowledge. We went from "ask Karthik" to proper ADRs, runbooks, and onboarding guides. This was painful but necessary. If your process lives in one person's head, you don't have a process.

Metrics replaced gut feel. I started tracking cycle time and PR review turnaround religiously. Not to micromanage, but because I literally could not observe the work anymore. More on engineering metrics in a future post.

The hardest part

Letting go. My instinct was to stay involved in every technical decision. But a PM who's in every Slack thread is a bottleneck, not a leader. I had to get comfortable with engineers making choices I wouldn't have made — and being right about half the time.

The team didn't need a better PM. They needed a PM who knew when to disappear.