Engineering Manager Span of Control Jumped from 10.9 to 12.1—Are We Scaling Leadership or Breaking It?

diana_data · April 5, 2026, 9:03pm

I’ve been reflecting on something that’s been bothering me as we scale our engineering org from 25 to 80+ engineers over the past 18 months. Our average manager span of control has quietly increased from 8 direct reports to 11.5, and I’m seeing cracks in the foundation.

The industry data confirms we’re not alone. According to recent research, the average engineering manager now handles 12.1 direct reports, up from 10.9 in 2024. The narrative is that this is “efficient scaling”—we’re leveraging our best leaders more effectively, reducing organizational layers, enabling faster decision-making.

But here’s what the efficiency narrative doesn’t capture: three of my strongest engineering managers are quietly burning out.

The Hidden Cost of “Efficient” Scaling

One of my EMs confided in me last week: “I used to have time for 1:1s that went deep—career planning, technical mentorship, helping people work through interpersonal challenges. Now my 1:1s are task updates because I’m running between meetings all day.”

Another manager said something that hit hard: “I know two of my direct reports are struggling. I can see it in their PRs and their energy in standups. But I don’t have time to truly support them right now.”

This is the organizational debt we’re creating. When span of control increases from the research-backed optimal range of 5-10 direct reports to 12+, managers shift from developing people to managing throughput.

What We’re Optimizing For Matters

The research is clear on what happens at these wider spans:

Manager burnout increases significantly
Employee support quality degrades
Retention of high performers suffers
Career development conversations become transactional
Early-warning signs of team issues get missed

Yet we keep pushing spans wider because hiring managers is expensive and adds “organizational layers.” The financial logic is sound until you calculate the cost of losing senior engineers who leave because they’re not getting the mentorship and support they need.

The Questions I’m Wrestling With

Are we treating managers as a cost center or a capability multiplier? If it’s the latter, then under-investing in management capacity is strategic malpractice.
What invisible work are we losing? The coaching conversations, the early interventions, the career development—all the things that don’t show up in JIRA but determine whether people thrive or leave.
Is there a different organizational model? Maybe the answer isn’t just “hire more managers.” Internal developer platforms reduce cognitive load by 40-50%, which could allow wider spans without the same burnout. Or maybe we need to rethink the manager role entirely.
What’s the right span for different manager capabilities? Not all managers can effectively handle 8 direct reports, and some exceptional leaders might handle 10-12 without breaking. Are we differentiating, or are we applying a one-size-fits-all approach?

What I’m Considering

I’m proposing to our exec team that we:

Cap span of control at 9 for the next 12 months
Hire 2 additional engineering managers in Q2
Measure manager effectiveness, not just efficiency (1:1 quality scores, career development outcomes, early-warning issue detection)
Build better operational leverage through platform investments before expanding spans further

The CFO’s first question will be: “Can’t we just hire one manager instead of two?” And the honest answer is: maybe, but we’ll be choosing efficiency over effectiveness, and 83% of developers already report burnout.

My Question to This Community

For those of you leading engineering orgs: what’s your current average span of control, and what have you learned about the real limits?

Are you seeing the same patterns I am—managers stretched so thin they can’t truly develop their people? Or have you found ways to scale spans without sacrificing management quality?

I want to believe there’s a path to efficient scaling that doesn’t break our managers or erode the support that makes people want to stay. But I’m not sure what that path looks like yet.

eng_director_luis · April 5, 2026, 9:03pm

This hits close to home. We’re at 40+ engineers, and our average span is 10.2 right now. I pushed back hard when leadership wanted to go to 12-13, and here’s why:

We tried wider spans during a 2024 growth phase, and the damage took 8 months to repair.

Our spans hit 13-14 for about six months. On paper, everything looked fine—velocity was up, tickets were closing, OKRs were green. But beneath the surface:

Manager burnout was invisible until it wasn’t. One of our best EMs gave two weeks notice without any prior warning. Exit interview revealed they’d been struggling for 4 months but had no time to even job search deliberately—they just snapped one weekend and accepted the first offer they got.
Early-career engineers stalled. Our promotion rate for engineers with 2-4 years experience dropped by 40%. Why? Because managers didn’t have time for the coaching conversations and skill development that turn promising juniors into solid mids.
Small problems became big problems. We had a team dynamics issue that should have been caught in week 2. The manager knew something was off but didn’t have capacity to dig in. By month 3, it had become a full HR situation with two engineers on PIPs.

What We Changed

After that EM quit, I did a hard analysis and took this to the CFO:

The cost of one burned-out manager leaving:

Recruiting cost: ~$20K
3-4 months to backfill (hiring managers takes forever)
Lost institutional knowledge: immeasurable
Team disruption during transition: 2-3 months of reduced effectiveness
Risk of additional attrition from their reports: we lost 1 of their 13 directs within 60 days

The cost of hiring one additional manager proactively: ~$180K loaded

The ROI math is brutal—one manager burning out and leaving costs us more than just hiring the additional capacity upfront, and that’s before calculating the downstream costs of degraded team performance.

Where We Landed

Span target: 8-10 (we treat 10 as the ceiling, not the target)
Manager capacity reserved for non-1:1 work: 30% minimum (strategic planning, process improvement, professional development)
We track “manager load” not just span: number of directs × complexity factor (early-career engineers = 1.5x, cross-timezone = 1.2x, new to team = 1.3x)

The last point matters. A manager with 8 experienced engineers is in a very different position than a manager with 8 new grads. We had been treating all “8 directs” situations as equivalent.

My Controversial Take

Wider spans don’t fail immediately—they fail slowly, invisibly, and expensively.

You won’t see it in your quarterly metrics. You’ll see it in attrition trends 9-12 months later. You’ll see it in promotion rates dropping. You’ll see it in culture survey scores declining. By the time it’s visible, you’ve accumulated organizational debt that takes years to pay down.

@vp_eng_keisha I’d be really interested in your experience scaling from 25 to 80+. What’s your manager hiring ratio looking like? Are you adding managers proportionally or trying to leverage wider spans?

cto_michelle · April 5, 2026, 9:03pm

This is one of the most important conversations in engineering leadership right now, and I appreciate how honestly you’re both framing it.

I’ll share our experience at 120 engineers, because I think the pattern repeats at every scale, and the intervention points matter.

The Pressure Pattern

Every growth stage brings the same pressure:

Series A → Series B: “We can’t afford manager overhead, push spans to 12”
Series B → Series C: “We need to prove unit economics, flatten the org”
Post-IPO: “Wall Street wants better efficiency metrics, reduce management layers”

The financial incentive to minimize management investment is constant. But here’s what I’ve learned after doing this three times:

Organizations don’t fail from too many managers. They fail from too few managers hired too late.

What Actually Happened When We Scaled

Phase 1 (30 → 60 engineers): Kept manager spans at 6-7. Everyone thought we were “over-managed.” Board member literally said “you have too many chiefs, not enough Indians” (yes, really—2026 and we’re still hearing this).

Result: Smoothest scaling phase I’ve ever experienced. Retention stayed at 92%. Promotion rate actually increased. Culture scores held steady.

Phase 2 (60 → 120 engineers): New CFO pushed for “operational efficiency.” Spans drifted to 10-11. We froze manager hiring for 9 months.

Result: Everything @eng_director_luis described. Plus:

Technical quality declined (managers had no time for code review standards enforcement)
Cross-team coordination broke down (managers too busy to show up for architecture discussions)
Innovation slowed (no manager bandwidth for exploratory projects)
Our eNPS dropped 18 points in 6 months

The Framework I Use Now

I present this to the board as a management capacity investment thesis, not a headcount request:

Management capacity determines organizational learning rate.

Narrow spans (5-7): High learning rate, expensive per engineer, appropriate for early-stage or transformational periods
Medium spans (8-10): Sustainable learning rate, balanced economics, appropriate for steady growth
Wide spans (11+): Learning rate collapse, efficiency gains are illusory, organizational debt accumulates

When you frame it as learning rate, suddenly the CFO gets it. Because they understand that in a fast-moving market, the org that learns fastest wins, and you can’t learn if your managers are in back-to-back meetings managing throughput instead of developing people.

The Question I Ask Skeptics

"Would you rather have:

Option A: 100 engineers with 10 great managers (spans of 10), or
Option B: 110 engineers with 8 overwhelmed managers (spans of 13.75)?"

Option B saves maybe $360K in loaded manager costs. But the productivity loss from burned-out managers and under-supported engineers easily costs 15-20% of engineering capacity—which at 110 engineers is worth $3M+ annually.

The math isn’t close.

My Answer to Your Question

@vp_eng_keisha Your proposal to cap at 9 and hire 2 managers is the right call. I’d add one more thing:

Make management quality measurable and visible.

We track:

1:1 frequency and duration (target: 45+ min biweekly)
Career development plan completion (every direct has one, reviewed quarterly)
Early intervention rate (manager spots and addresses issues within 2 weeks)
Manager support for skip-level relationships (I should know all managers’ directs)

When you make management quality measurable, it becomes something you can manage. When it’s invisible, it becomes the first thing that gets sacrificed under pressure.

The brutal truth: scaling engineering leadership is expensive, and the only thing more expensive is scaling without it.

product_david · April 5, 2026, 9:03pm

Coming at this from the product side, and I think there’s a dimension here that’s not getting enough attention:

Wide manager spans don’t just hurt engineering—they destroy product-engineering collaboration.

Here’s what I’m seeing in my org (and heard from PM friends at other companies):

The Product-Engineering Coordination Tax

When engineering managers are stretched thin:

1. Strategic alignment breaks down
Our eng managers used to join product reviews, roadmap planning sessions, and customer discovery calls. Now? They’re “too busy” and send their tech leads instead.

Problem: Tech leads don’t have the full context on team capacity, upcoming people changes, or technical debt priorities. So we end up with commitments that engineering leadership can’t actually deliver on.

2. Scope negotiation becomes a transaction
It used to be: “Here’s the business problem. Let’s figure out the right solution together.”

Now it’s: “Here’s the feature spec. Can you build it by Q2?” Engineering says yes because the manager doesn’t have time to push back thoughtfully, then we get to Q2 and it’s half-done.

3. The feedback loop gets longer
When an EM has 7 directs, they know what’s happening on the ground. When they have 12, they’re hearing everything second-hand through stand-ups and status updates.

So when we need to pivot based on user feedback, the EM can’t tell us what’s realistic because they don’t know what’s actually happening in the codebase. The feedback loop goes from 1 week to 3-4 weeks.

The Hidden Product Velocity Cost

You’d think wider eng manager spans would mean more engineering capacity → faster shipping. But what actually happens:

Rework increases: Features get built without proper product input because EMs don’t have time to collaborate upfront
Technical debt accelerates: Managers don’t catch architectural problems early, so we end up rebuilding things 6 months later
Cross-team dependencies explode: Without managers coordinating, teams build conflicting solutions to similar problems

At my previous company, we actually tracked this. When EM spans went from 8 → 12:

Feature cycle time went UP by 22% (not down)
Customer satisfaction with new features dropped 15 points
Technical debt backlog grew 40%

What I’d Add to Your Proposal

@vp_eng_keisha when you pitch this to your CFO, I’d recommend adding a product angle:

Wider manager spans slow down product velocity and increase the cost of shipping value.

The CFO might not care about “manager burnout” in isolation, but they definitely care about:

Time-to-market for revenue-generating features
Customer satisfaction metrics
Rework costs (building features twice because we didn’t get it right the first time)

The Question That Changes the Conversation

Instead of: “Should we hire more managers?”

Ask: “What is the optimal product-engineering collaboration model, and what management capacity does that require?”

When you frame it as enabling product-engineering effectiveness—not just “supporting engineers”—suddenly it becomes a strategic investment, not a cost center.

Also, @cto_michelle I love your management quality metrics. From a product perspective, I’d add one more:

Product-engineering alignment score: Measured through joint retrospectives, commitment accuracy, and feedback loop speed

Because if your eng managers don’t have time to collaborate with product, you’re not just hurting engineering—you’re hurting the entire company’s ability to ship the right things.