We're Measuring Growth by Headcount Instead of Leadership Capacity—And It's Killing Our Teams

[vp_eng_keisha]

I need to talk about something that’s been keeping me up at night.

We just finished our Q1 planning, and I’m looking at our org chart: 80+ engineers, 7 engineering managers. That’s 11.4 direct reports per manager on average. One of my managers has 15 direct reports. And here’s the kicker—the data says optimal span of control for engineering managers is 5-10 people. We’re not even close.

The Pattern We Keep Repeating

Six months ago, we had 25 engineers. Velocity was good. Team morale was solid. Then we raised our Series B. The board wanted aggressive growth. “Double the engineering team by Q2,” they said. “We need to move faster.”

So we hired. And hired. And hired some more.

Guess what happened to our velocity? It didn’t double. It dropped.

The Data We’re Ignoring

Research shows the average engineering manager now handles 12.1 direct reports—up from 10.9 in 2024. But the sweet spot for experienced managers is 6-9 direct reports. Why? Because beyond that, managers can’t provide quality 1:1s, meaningful mentorship, or technical guidance.

The numbers tell a brutal story:

• 83% of engineers report burnout in high-growth environments
• 22% of engineering leaders report critical burnout
• Managers with 7 or fewer direct reports score 20% higher on team engagement
• A 15-person team has over 100 communication channels—each a potential source of delay or misunderstanding

What Actually Breaks

When I inherited my current role, one of my directors was managing 15 people. Here’s what was happening:

1:1s became status updates. No coaching. No career development. Just “what are you working on?”

Code reviews stalled. Junior engineers waited days for feedback. Senior engineers burned out from constant context-switching.

Architectural decisions happened in Slack. No time for thoughtful design reviews. Technical debt piled up.

High performers left. The people who could get another job did. The ones who stayed were either too junior to know better or too exhausted to interview.

The Root Problem

We’re measuring the wrong thing. We track:

• Total headcount
• Hire velocity
• Engineering headcount per product team

We don’t track:

• Manager capacity utilization
• Span of control by role level
• Leadership bench strength
• Time to promote new managers

We’re solving for team size instead of leadership capacity.

What I’m Doing About It

I went to our CEO with data. I showed her:

• Manager calendar analysis: 70% of time in 1:1s and overhead, only 30% for strategy
• Attrition analysis: managers with 12+ reports had 2.3x higher team turnover
• Velocity per manager (not per engineer): down 31% despite 40% headcount growth

Then I asked for something controversial: Pause hiring for two months.

Use that time to:

1. Promote three senior engineers to engineering managers
2. Implement manager training and support systems
3. Rebalance teams to target 8 direct reports per manager
4. Build a leadership capacity model for future planning

She said yes. We’re two weeks in.

The Question I’m Asking

How many of you are in growth mode right now? Are you tracking manager capacity the same way you track engineering capacity?

When your board pushes for aggressive hiring, how do you make the case that leadership infrastructure matters?

Because here’s what I’m learning: A team that scales leadership first scales engineering second—and actually ships faster.

---

Sources: 10 Leadership Strategies to Scale Engineering Teams in 2026, Scaling Engineering Team Strategies For Growth 2026, The Optimal Span of Control for Engineering Managers, How Many Direct Reports? Amazon, Google & Spotify Data Revealed

[eng_director_luis]

Keisha, this hits so close to home.

We went through almost the exact same pattern at our financial services company. 18 months ago, our engineering-to-manager ratio was 1:8. Manageable. Then we got acquisition funding for a digital transformation push. Leadership said “we need 60% more engineers by end of year.”

We hit that target. Our ratio went to 1:14. And just like you described, velocity didn’t increase—it collapsed.

What Actually Happened

Code review bottleneck. Our SDLC requires two approvals for production deployments (regulatory compliance). Reviews that took 4-6 hours suddenly took 3-4 days. We had PRs sitting for a week.

Architectural drift. With managers spending 80% of their time on people issues, nobody was maintaining technical vision. Three teams built three different authentication systems because nobody had time to align.

Attrition spiral. Our best senior engineers left for “architect” roles at other companies because they were drowning in code reviews and couldn’t do strategic work. We lost institutional knowledge faster than we could document it.

The Fix That Worked

I did something similar to what you’re doing now, but I wish I’d done it sooner. We didn’t pause hiring completely, but we slowed it to 50% of planned velocity for Q1. Then:

1. Promoted 3 senior engineers to engineering manager roles (with proper training, not “congrats you’re a manager now go figure it out”)

2. Rebalanced teams from 1:14 to 1:9 average (not perfect, but a huge improvement)

3. Created a “management capacity” metric that we now review quarterly alongside headcount

The Data That Convinced Leadership

Our CFO is very numbers-driven. Here’s what got his attention:

• Manager calendar audit: Showed managers spending 75% of time in reactive 1:1s, only 25% on strategic work
• Attrition cost analysis: Lost 4 senior engineers in 6 months = $280K in recruiting + $800K in lost productivity during ramp-up
• Time-to-production regression: Average feature delivery time increased 47% despite 60% more engineers

The turning point was when I showed him: “We’re paying for 60% more engineering capacity but getting 30% less output.”

That’s when the conversation shifted from “why aren’t we hiring?” to “how fast can we fix the manager ratio?”

The Lesson

You said it perfectly: temporary hiring pause beats permanent velocity loss.

We’re now 9 months into the rebalancing. Our manager ratio is 1:8 (targeting 1:7). Velocity is back to previous levels and climbing. Most importantly, our engineering leaders aren’t burning out.

The hard part was saying “no” to stakeholders who wanted more engineers. But showing them the data—that more engineers without leadership infrastructure makes everything slower—made the case.

Curious: are you seeing the same resistance I did when suggesting the hiring pause? How did you frame it to your CEO?

[cto_michelle]

This conversation is critical. As a CTO, I see this pattern across the industry, and it’s a systemic failure of how we think about growth.

The Board Pressure Problem

Here’s what happens in board meetings:

Board member: “Your burn rate suggests you need to grow engineering headcount 40% to hit the product roadmap.”

CTO: “Actually, we need to grow engineering leadership first, then scale headcount.”

Board member: “How long will that take?”

CTO: “6-9 months to develop managers internally, or 3-6 months to hire externally.”

Board member: “We don’t have that time. The market window is closing.”

And suddenly you’re hiring 30 engineers with 3 managers, each with 10+ direct reports, and wondering why OKRs are slipping.

The Real Cost Nobody Tracks

What Luis described—attrition, architectural drift, code review bottlenecks—these are symptoms. The disease is treating managers as an operational afterthought instead of a strategic constraint.

When I joined my current company as CTO, here’s what the numbers looked like:

• Engineering headcount: 52 people
• Engineering managers: 4 (average 13 direct reports)
• Manager attrition rate: 75% annual (3 of 4 managers left within 12 months)
• Engineering attrition: 38% annual
• Velocity trend: declining 5% quarter-over-quarter

Investors were pushing for 100 engineers by end of year. I said no.

The Counterintuitive Metric

I introduced a metric that changed the conversation: Velocity Per Manager (VPM).

Instead of measuring:

• Stories per engineer per sprint
• Features shipped per quarter

We started tracking:

• Stories per manager per sprint
• Features per manager team per quarter

The insight: Adding engineers to an overloaded manager doesn’t increase velocity—it decreases it.

When a manager goes from 8 to 12 reports:

• Time spent on people management: +50%
• Time available for technical leadership: -60%
• Team velocity: -15% to -25%
• Attrition risk: +35%

What I Told the Board

“We can hire 100 engineers this year and ship 20% less, or we can hire 70 engineers with the right management infrastructure and ship 40% more. Which outcome do you want?”

I showed them:

1. Current state: 52 engineers, 4 managers, 120 story points/sprint (30 per manager)
2. Bad scaling: 100 engineers, 8 managers, 180 story points/sprint (22.5 per manager) ← velocity per manager drops
3. Good scaling: 70 engineers, 10 managers, 240 story points/sprint (24 per manager) ← velocity per manager increases

They chose option 3.

The Framework We Built

Leadership capacity became a constraint in our growth model, not an afterthought:

Before any hiring plan:

1. Audit current manager capacity (span of control, calendar time, direct report growth rate)
2. Identify future managers (promotion pipeline + external hiring)
3. Build manager training and support systems
4. Then model engineering headcount growth

Quarterly leadership reviews track:

• Span of control by manager level
• Manager calendar time allocation (strategic vs. reactive)
• Manager bench strength (how many senior ICs are manager-ready?)
• Time-to-manager promotion (IC → EM transition time)

The Uncomfortable Truth

Keisha, you asked how to make the case to leadership that infrastructure matters. Here’s what I’ve learned:

Boards understand two things: revenue and cost.

When you frame manager capacity as:

• “We need to invest in leadership development” → sounds like an HR initiative
• “Current manager overload is costing us $1.2M annually in attrition and 25% in lost velocity” → sounds like a business problem

The math that works:

• Average cost to replace a senior engineer: $150K (recruiting + ramp time)
• Managers with 12+ reports: 2.3x higher team attrition
• Our 4 managers with 13 reports each: expect 6 extra departures/year = $900K
• Velocity loss from overloaded managers: 20-25% = equivalent to 10 engineers = $2M in salary that produces nothing

Total cost of manager overload: $2.9M annually.

Hiring 3 additional managers at $180K each = $540K.

ROI: 5.4x in year one.

That’s the conversation that changes minds.

To Your Question

When your board pushes for aggressive hiring, how do you make the case that leadership infrastructure matters?

Show them the cost. Not the soft costs (“burnout,” “morale”). The hard costs: attrition dollars, velocity loss translated to missed revenue, opportunity cost of shipping slower.

Then show them the ROI of investing in management infrastructure first.

It’s not a values conversation. It’s a business case.

[maya_builds]

Reading this thread as a designer has been… eye-opening

I see these problems from the other side of the collaboration—and honestly, it explains so much of the friction I’ve been experiencing lately.

What It Looks Like From Design’s Perspective

Our design team partners with 4 engineering teams. Over the past 6 months:

Engineering contact changed 3 times for one product stream. Each time we’d finally build rapport with an EM, they’d either leave or get reassigned because of “reorg for scale.”

Design reviews became a black box. We used to have standing design review sessions with engineering leads. Now? Crickets. Or they show up for 10 minutes, clearly overwhelmed, and say “yeah looks good just ship it.”

Cross-functional alignment disappeared. Used to have regular product-design-eng syncs where we’d align on technical constraints before investing weeks in design work. Now those meetings get cancelled because “EMs are underwater.”

The Human Cost I’m Seeing

One of the EMs I worked closely with—let’s call her Sarah—went from being this energetic, thoughtful partner to… burned out. She told me over coffee:

“Maya, I have 14 direct reports. I spend my entire day in 1:1s and firefighting production issues. I don’t have time to think about the big picture anymore. I don’t even know what the design team is working on.”

That broke my heart. She used to be the person who connected our work to user impact. Now she’s just surviving.

The Ripple Effect Nobody Talks About

When engineering managers are spread too thin, it’s not just an engineering problem. It cascades:

Product velocity suffers. PMs can’t get alignment on priorities because EMs don’t have capacity for strategic conversations.

Design quality suffers. We ship designs without proper technical review because EMs don’t have time to engage deeply. Then we discover technical constraints during implementation. Rework everywhere.

Innovation dies. The stuff that doesn’t fit neatly into a sprint? The creative experiments? Forget it. No bandwidth.

My Question for This Community

Michelle, your “Velocity Per Manager” metric is brilliant. But here’s what I’m struggling with:

How do we make this visible to executive teams before the breaking point?

From where I sit in design, I can feel when engineering leadership is overloaded—our collaboration degrades, decisions take longer, context gets lost. But I don’t have the data to make it legible to leadership.

Is there a way to measure cross-functional effectiveness that would show up in your quarterly leadership reviews? Something like:

• Design-to-engineering alignment time?
• Number of design reworks due to missed technical constraints?
• Stakeholder sync meeting attendance/effectiveness?

Because by the time engineering velocity is measurably down, we’ve already lost months of momentum.

---

Also: watching talented people like Sarah lose their spark because they’re managing too many reports is heartbreaking. This isn’t just about productivity metrics. It’s about people.

I’m glad you all are having this conversation. Please keep fighting for your teams’ capacity. Those of us outside engineering need you to have space to lead well.

[eng_director_luis]

Maya, this is such an important question—and you’re absolutely right that cross-functional friction is an early warning signal.

Metrics That Show Manager Overload Early

We actually started tracking some of what you mentioned after our design team raised similar concerns. Here’s what worked:

1. Cross-functional meeting effectiveness score
After every product-design-eng sync, participants rate (1-5):

• Was the right technical leadership present?
• Did we resolve blockers or just surface them?
• Do we have clear next steps?

When this score drops below 3.5 consistently, it’s a leading indicator that EMs don’t have bandwidth for strategic alignment.

2. Rework rate due to missed requirements
We started tagging stories that required rework after implementation. Categories:

• Missed technical constraints
• Design changes due to technical feasibility
• Late-discovered dependencies

When rework rate went from 8% to 23%, it correlated directly with our span of control increasing from 1:8 to 1:14.

3. EM calendar analysis (the one that convinced our CFO)
Every quarter, we audit manager calendars:

• % time in 1:1s and reactive meetings
• % time in strategic/cross-functional work
• % time cancelled or rescheduled

When strategic time dropped below 20%, cross-functional alignment collapsed.

How to Make It Visible

Here’s what worked for us in getting leadership to pay attention:

Link it to business outcomes. Don’t just say “design-eng collaboration is suffering.” Show:

• Feature delivery time increased 31% (track from design hand-off to production)
• Design rework cost: $X in engineering hours + Y weeks of delay
• Product launches slipped: 2 of 4 planned features missed quarter

Show the trend line. One quarter of bad data is noise. Three quarters of degrading metrics is a pattern. We created a simple dashboard:

• Q1: Manager span 1:8, rework rate 8%, cross-functional score 4.2
• Q2: Manager span 1:11, rework rate 15%, cross-functional score 3.8
• Q3: Manager span 1:14, rework rate 23%, cross-functional score 3.1

Leadership saw the correlation immediately.

Bring cross-functional partners to leadership meetings. I invited our Head of Design to our quarterly engineering review. She shared (diplomatically) what you just described: EMs cancelling meetings, losing context, making decisions without design input.

Coming from a cross-functional partner, it hit different. Engineering saying “we’re overloaded” sounds like complaining. Design saying “we can’t get engineering leadership engaged” sounds like a business problem.

The Framework We Use Now

Every quarter, our leadership team reviews:

Engineering metrics:

• Span of control by manager
• Manager attrition rate
• Engineering velocity

Cross-functional health metrics:

• Design-eng rework rate
• Product-eng alignment meeting effectiveness
• Cross-functional collaboration score (survey)

Business impact:

• Feature delivery time (design → production)
• On-time delivery rate
• Customer-facing quality issues

When cross-functional health degrades before engineering velocity drops, we know to act early.

To Your Specific Question

How do we make this visible to executive teams before the breaking point?

Start collecting the data now. Even informally:

• After every design-eng review, note: did the right people show up? Did we make progress?
• Track design rework requests due to technical constraints
• Note when key engineering meetings get cancelled

Then in 2-3 months, you have trend data. Bring it to your design leader, who can bring it to the exec team.

The key is framing it not as “engineering is struggling” but as “our cross-functional velocity is declining, and here’s the pattern we’re seeing.”

Executives respond to patterns, trends, and business impact. Give them that data, and they’ll ask engineering leadership the hard questions.

---

And yes—watching talented people burn out is the hardest part. Thanks for caring about your engineering partners. That empathy matters.