We felt the shift at exactly 23 engineers. What's your inflection point?

General
1

Everyone talks about the mythical “20-engineer threshold” where things start to break. I used to think it was just another consulting firm framework—until we hit 23 engineers last spring.

What actually broke:

Our Friday sprint planning used to take 45 minutes with 12 engineers. By the time we hit 23, it was regularly running 3+ hours. Not because the work got more complex—because coordination did.

The Slack channels that used to feel like a cozy coffee shop turned into a crowded conference hall. You couldn’t just @ someone and expect context anymore. Information got lost. Decisions happened in side threads. New hires spent their first month just figuring out who to ask.

The manager crisis:

I looked at our org chart in May. Some of my engineering managers were carrying 12-14 direct reports. The optimal range is supposed to be 5-10, and we were way over. They were drowning in 1:1s and couldn’t see who was stuck until it was too late.

What we learned the hard way:

At 12 engineers, informal communication works. At 23, you need structure or you pay for it in:

  • Sprint planning that consumes half a day
  • Context switching that kills flow
  • Manager burnout (we lost two great EMs in Q3)
  • New hire ramp-up time that went from 4 weeks to 10+ weeks

The research backs this up. At 20 engineers, you have 19x more coordination overhead than at 5. The average engineering manager now handles 12.1 reports, but optimal is 5-10.

Questions for the community:

  1. What number did you feel it? Was it 15? 25? 40?
  2. What broke first for you? Sprint planning? Communication? Deploy process? Hiring/onboarding?
  3. What systems actually scale? Not just what you should do, but what actually worked when you crossed 20 → 50 → 100 engineers?

I’m curious whether this inflection point is universal or if it depends on your domain, team structure, or culture. Our fintech context (heavy compliance, distributed team) might have made it worse.

What’s your story?

2

15 people for design. :artist_palette:

We hit our scaling wall earlier than engineering. At 15 designers, our informal design review process completely fell apart.

What broke:

Before 15, we’d just drop designs in Slack, people would react with :+1: or thoughtful comments, and we’d iterate. Felt collaborative and fast.

After 15? Design reviews became a free-for-all. 12 people would weigh in on a button color. Feedback contradicted itself. Junior designers didn’t know whose opinion to prioritize. Decision-making ground to a halt.

Tool fragmentation killed us:

This is the part that hurt: we were losing 8+ hours per week just rebuilding context.

Designer A uses Figma. Designer B references old work in Sketch. Designer C has tribal knowledge in their head. New designer joins and has to ask 6 different people to understand how we got here.

Sound familiar? Research shows 54% of devs use 6+ tools and lose 8+ hours/week to context rebuilding.

What we did:

  1. Design system became mandatory, not optional. Component library in Figma. If it’s not in the system, you can’t ship it. Painful transition, but it saved us.

  2. Structured design critiques. Every Tuesday and Thursday, 30 minutes, specific format. No more drive-by Slack feedback for major decisions.

  3. Tool consolidation. Everything in Figma or it doesn’t exist. Killed off 4 tools in 3 months.

The question I’m sitting with:

Do different functions hit inflection points at different sizes? Engineering felt it at 20-23. Design felt it at 15. Product might be different again.

Is it because design work is more collaborative by nature? Or because we were less structured to begin with?

3

The 12.1 average is real—and it’s crushing our managers. :bar_chart:

@eng_director_luis I’m living this exact pain point right now at our EdTech startup. We’re scaling from 25 to 80+ engineers, and the manager span-of-control crisis hit us like a truck.

The data is stark:

Gallup’s latest research shows the average manager now handles 12.1 direct reports, up from 10.9 in 2024. But for engineering specifically? The optimal range is 5-10.

We were at 11-13 reports per EM by the time we hit 35 engineers. Know what happened?

Manager burnout became the crisis:

  • Our best engineering managers were spending 70% of their time in 1:1s and performance reviews
  • They couldn’t see who was stuck until sprint retros (too late)
  • Technical mentorship disappeared—no bandwidth for it
  • We lost 2 senior EMs in Q4. Exit interviews? “I became an admin, not a leader.”

This tracks with broader trends: 22% of engineering leaders report critical burnout. Top cause? High workloads at 47%.

What we did (and it hurt):

At 35 engineers, we made the hard call to add a middle management layer:

  • Capped all manager spans at 8 reports (ideally 6-7)
  • Promoted 2 ICs to engineering manager roles
  • Hired 3 external EMs with scaling experience
  • Created clear EM → Senior EM → Director progression

It was expensive. Finance pushed back hard. But the alternative was watching our best people burn out and quit.

The question that keeps me up:

How do you know when to add management versus improve processes?

Sometimes span-of-control problems are really process problems in disguise. If your managers are drowning in status updates, maybe you need better tooling, not more managers.

But sometimes you just need more leadership capacity. Where’s the line?

4

Most companies scale too fast—then pay for it in tech debt and burnout.

I’ve seen this pattern across three companies now. Leadership gets excited about growth. Investors demand headcount expansion. Everyone starts throwing bodies at the problem.

Here’s what actually happens:

Adding people to a broken system just creates a bigger, more expensive broken system.

At my last company, we went from 35 to 85 engineers in 14 months. Felt like success. The board loved it. Engineering velocity charts went up and to the right.

Then reality hit:

  • Developers were spending 35-40% of their time navigating technical debt instead of building features
  • Deploy frequency dropped (more people = more conflicts)
  • Incident rate increased 2.3x
  • Onboarding time ballooned from 3 weeks to 12+ weeks

The research backs this: developers spend 30-40% of time on tech debt, and engineering leaders should allocate 15-20% of sprint capacity to debt reduction.

The hard decision:

At 50 engineers, I made a call that nearly got me fired: we froze hiring for 6 months and fixed the architecture.

  • Rebuilt CI/CD pipeline (it was taking 45 minutes to deploy)
  • Paid down the gnarliest tech debt (authentication, data layer, API contracts)
  • Created a platform team (5 engineers) focused on developer productivity
  • Shipped internal tooling so teams could self-serve infrastructure

Finance hated it. “We’re paying 50 engineers to not ship features.”

But 6 months later? Velocity was 2x what it had been. Incident rate dropped by 60%. New hires ramped in 4 weeks instead of 12.

Platform teams matter:

At 20+ engineers, the overhead of each developer managing their own infrastructure becomes a drag. You need a platform team.

Not at 5 engineers. Not at 10. But at 20-25? It becomes the highest-ROI investment you can make.

My controversial take:

If you’re scaling engineering headcount faster than 50% year-over-year, you’re probably moving too fast. The systems can’t keep up. Culture gets diluted. Tech debt compounds.

Better to grow at 30-40% and build the scaffolding as you go.

5

Product scaling has different dynamics, but hits similar walls.

Really interesting to see the engineering, design, and leadership perspectives here. Product team scaling follows a different pattern, but we hit coordination walls just the same.

PM-to-engineer ratio matters:

When we had 15 engineers, we had 2 PMs (1:7.5 ratio). Felt sustainable.

At 30 engineers, we had 3 PMs (1:10 ratio). Starting to strain.

At 45 engineers, we had 4 PMs (1:11.25 ratio). Completely unsustainable.

The coordination overhead between product and engineering increased dramatically after 30 engineers. PMs were spending more time aligning with each other than actually talking to customers or making product decisions.

What broke:

  1. Roadmap fragmentation. Each PM had their own priorities. No clear company-level narrative. Sales didn’t know what to sell. Engineering didn’t know what mattered most.

  2. Feature bloat. Everyone building their own version of shared components. Authentication implemented 3 different ways across the product.

  3. Customer insight dilution. PMs stopped talking to customers because they were too busy in coordination meetings.

The squad model saved us:

We reorganized around squads at 40 engineers:

  • 6-8 engineers per squad
  • 1 dedicated PM embedded full-time
  • 1 designer (shared across 2 squads)
  • Clear domain ownership (checkout, search, billing, etc.)

Reduced cross-squad dependencies by 60%. PMs could actually focus on their domain instead of endless alignment meetings.

But here’s the thing @cto_michelle mentioned:

Adding people to a broken system just creates a bigger, more expensive broken system.

This is so true for product teams too. We tried to solve coordination problems by hiring more PMs. Made it worse. Had to step back and fix the operating model first.

My question for the group:

What’s the right PM-to-engineer ratio as you scale? I’ve heard everything from 1:5 to 1:15. Does it depend on product complexity, customer type, or stage of company?