The 12.1 Direct Report Reality vs the 5-10 Research Ideal: Your Engineering Managers Are Underwater, But "Just Hire More Managers" Isn't an Option. Now What?

vp_eng_keisha · March 29, 2026, 2:51pm

The 12.1 Direct Report Reality vs the 5-10 Research Ideal: Your Engineering Managers Are Underwater, But “Just Hire More Managers” Isn’t an Option. Now What?

I need to be honest with y’all: my engineering managers are drowning, and I suspect I’m not alone.

When I joined as VP Engineering 18 months ago, we had 25 engineers organized into 4 teams with 4 managers. Nice and tidy—about 6 reports per manager. Today? We’re at 82 engineers with… still basically 6 managers. That’s 13.6 direct reports per manager on average. And before you say “just hire more managers,” let me tell you why that’s not as simple as it sounds.

The Data Should Worry All of Us

According to recent research, the average engineering manager now handles 12.1 direct reports, up from 10.9 just last year. Meanwhile, every management expert will tell you the optimal range is 5-10 direct reports, with a sweet spot around 6-8 for engineering teams specifically.

That gap? That’s where manager effectiveness goes to die.

Sources: Span of Control in 2026, Leadership Strategies to Scale Engineering Teams

Why “Just Hire More Managers” Doesn’t Work

Here’s what I hear from leadership when I bring this up:

CFO: “We can’t afford 3 more manager salaries right now. Can’t your current managers handle it until Q3?”

CEO: “Reorganizing the team will disrupt momentum. Let’s wait until after the product launch.”

HR: “We’re having trouble finding senior engineering managers. The pipeline is thin.”

Meanwhile, my managers are running 45-minute 1:1s every two weeks instead of weekly hour-long sessions. Performance reviews are surface-level. Career development conversations happen once a quarter if we’re lucky. And I see the burnout in their eyes during our skip-level meetings.

What Actually Happens at 12+ Direct Reports

Let me paint the picture from what I’m seeing:

1:1s become status updates. There’s no time for coaching, no space for career conversations. It’s just “what are you working on?” and “any blockers?”

Performance reviews become generic. When you have 15 performance reviews to write, you start using templates. The personalization disappears.

Career development stops. Managers don’t have time to identify growth opportunities, sponsor their reports for projects, or advocate effectively for promotions.

The best engineers leave. Your senior engineers who could become staff or principal? They bounce because nobody’s investing in their growth.

Managers burn out. The job becomes reactive coordination instead of proactive leadership.

The Solutions That Are Actually Working for Us

I can’t wait until Q3, so here’s what we’re experimenting with:

1. Technology-Enabled Management

We invested in better async tools. Managers record 5-minute Loom updates for their teams. Engineers use structured templates for 1:1 prep so meetings are more efficient. We use an automated performance tracking tool that surfaces accomplishments so managers don’t have to dig.

Result: We saved about 3-4 hours per manager per week.

2. Tiered Management Models

We promoted 4 senior engineers to “Technical Lead” roles. They’re not managers, but they mentor junior engineers, do technical code reviews, and help with onboarding. This took pressure off managers for IC development.

Key learning: Clear role boundaries matter. Tech leads coach on technical growth, managers coach on career and performance.

3. Strategic Team Organization

Instead of organizing by technical layer (frontend, backend, infra), we reorganized around business domains (user growth, enterprise features, platform). Each domain has clearer ownership, fewer cross-team dependencies, less coordination overhead for managers.

Result: Managers spend less time in alignment meetings, more time with their people.

4. Empowering Senior Engineers

We created explicit expectations that Staff+ engineers should be highly autonomous and should enable others’ autonomy. If you’re a Staff Engineer, you shouldn’t need weekly manager check-ins on your technical decisions.

Controversial take: If your Staff Engineer needs hand-holding, that’s a performance issue, not a management bandwidth issue.

The Uncomfortable Question I’m Wrestling With

Here’s what keeps me up at night: Are we just delaying the inevitable?

These solutions buy us time. They make 12+ reports more sustainable. But is “more sustainable” the same as “healthy”? Is “less drowning” the same as “thriving”?

I look at the research saying 6-8 is optimal and I think: maybe that’s what excellence looks like, and we’re just optimizing for survival.

Your Turn

I know I’m not alone in this. So let’s get real:

What’s your actual manager-to-IC ratio? (Not the official number—the real one.)
What creative solutions have worked in your org?
Have you figured out how to convince leadership this is a real problem worth investing in?
Am I wrong to think 12+ reports is unsustainable long-term?

The research is clear that this gap between reality (12.1) and ideal (5-10) is growing. If we don’t figure this out, we’re going to lose our best managers to burnout and our best engineers to companies that actually invest in their development.

What am I missing? What’s working for you?

Background: I’m VP of Engineering at a high-growth EdTech startup (formerly Google, Slack). We’ve scaled from 25 to 82 engineers in 18 months, and my managers are feeling the weight of that growth.

eng_director_luis · March 29, 2026, 2:51pm

Keisha, this hits home hard. I’m managing a similar situation in financial services—40+ engineers across distributed teams, and yes, my managers are underwater too.

The 12.1 to 5-10 gap you’re describing? We’re living it. I inherited a structure where engineering managers had 14-16 direct reports, and it was exactly as you described: 1:1s became check-ins, career development was nonexistent, and we lost two strong senior engineers to companies that “actually invested in people.”

The Tech Lead Solution That’s Working

Your tiered management model resonates because we implemented something similar about 8 months ago, and it’s been our most effective intervention.

Here’s what we did:

Created explicit “Tech Lead” roles with clear scope:

Tech leads mentor 3-4 engineers on technical skills
They do code reviews, pair programming, architecture guidance
They help with technical onboarding and ramp-up
They DO NOT do performance reviews, compensation decisions, or career planning

The math:

Started with 2 managers, each with 15 reports
Promoted 3 senior engineers to tech leads
Now: 2 managers with ~7 direct reports each, plus 3 tech leads handling technical mentorship

Result: Our manager satisfaction scores went from 2.1 to 3.8 (out of 5) in six months. Engineers report better technical growth AND better career conversations.

The Boundaries Are Critical

The mistake I see other orgs make is creating “tech lead” roles without clear boundaries. Then tech leads become “manager lite”—doing all the coordination work without the authority or compensation.

Our rule: If it touches performance, compensation, or career trajectory, it’s a manager conversation. If it’s technical skill development, it’s a tech lead conversation.

We literally have a RACI chart for this, and we review it quarterly because the boundaries get fuzzy.

The Leadership Conversation

On convincing leadership this is worth investing in—I used retention data. We calculated the cost of replacing a senior engineer (recruiting, onboarding, productivity ramp = ~$150K per person). Then I showed that we’d lost 4 senior engineers in 6 months, citing “lack of career development” in exit interviews.

$600K in turnover costs vs. $400K in three tech lead salaries (promoted from senior to staff with 15% raises). The ROI case made itself.

The Question I’m Still Wrestling With

Here’s what I’m stuck on: How do you prevent tech leads from becoming de facto managers?

We set boundaries, but in practice, when a junior engineer is struggling, the tech lead often gets pulled into “soft” performance conversations. They start giving feedback that sounds a lot like a performance review. The engineer starts going to them instead of their actual manager for career advice.

Have you seen this pattern? How do you keep the roles cleanly separated when reality is messy?

Also: your point about Staff+ engineers needing autonomy—100% agree, but how do you handle the transition? We promoted engineers to Staff who were amazing senior engineers but struggled with the autonomy expectation. Is that a coaching issue or a role fit issue?

Great thread. This is the conversation we need to be having.

maya_builds · March 29, 2026, 2:51pm

This is hitting a nerve from a completely different angle—I’m seeing this same span of control crisis on the design side, and the hidden costs are massive.

The Startup Story Nobody Talks About

At my failed startup, our Director of Product Design had 18 direct reports at peak. Eighteen. And before anyone asks “why didn’t you just hire another manager?”—we tried. Three times. Candidates looked at the mess and walked away.

Here’s what broke:

Quality disappeared. Our design manager couldn’t give meaningful feedback on work anymore. Review sessions became “yeah, looks good, ship it.” We shipped designs I knew weren’t ready because there was no time for proper critique.

Junior designers didn’t grow. They needed coaching on design systems, accessibility, user research. Instead they got occasional Slack messages and biweekly check-ins that were just status updates.

The craft died. Design is about iteration, refinement, attention to detail. When your manager has 18 reports, there’s no space for “let’s try three more variations” or “what if we explored this differently?” You ship the first version that works.

That startup failed for lots of reasons, but the design manager span of control issue was definitely on the list. We couldn’t deliver quality fast enough because nobody was developing the team.

The Cross-Functional Insight

What strikes me about Keisha’s post and Luis’s response is that this isn’t just an engineering problem. Every creative discipline suffers when managers are underwater.

The solutions you’re both describing—tech leads, structured 1:1 templates, domain-based org design—they apply to design, product, even marketing. The pattern is universal: when managers have too many reports, development and quality both suffer.

The Async Documentation Solution

One thing that helped us (too late, but still): we started requiring async documentation for everything. Not just code—design decisions, product specs, customer insights.

Why it helped:

Managers could review written docs in 15 minutes instead of 30-minute meetings
Junior folks learned by reading senior people’s decision-making
Peer reviews became possible—you don’t need your manager to be your only feedback source

We built a culture where if you didn’t document your work, it didn’t count. Brutal, but it reduced manager dependency.

The IC Track Matters

Luis, your tech lead model is smart, but here’s the design perspective: not everyone should be on a management track, and that needs to be okay.

In design, we have “Principal Designer” roles—same level and pay as design managers, but purely IC. They mentor through craft, not through performance reviews. They influence through design quality, not team management.

The problem: most companies still treat management as the only path to seniority. So people become managers to get promoted, even when they’d be better (and happier) as high-leverage ICs.

If you solve the span of control problem by adding more managers, you might just create more mediocre managers. If you solve it by empowering IC paths, you get leverage without the overhead.

My Question

Keisha, you mentioned empowering Staff+ engineers to be autonomous—love that. But how do you create that culture in an organization that’s been manager-dependent?

We tried that at the startup and got pushback: “But I need my manager’s approval” or “I don’t feel empowered to make that decision.” Changing that mindset is hard when people have been trained to escalate everything.

What does the transition look like? How do you teach autonomy when it hasn’t been the norm?

product_david · March 29, 2026, 2:51pm

Coming at this from the product side, and honestly, the engineering manager span of control problem is causing massive product-engineering misalignment that nobody’s talking about.

The Business Impact Is Real

At my previous company (Airbnb), we had engineering managers at 7-8 reports. Decision-making was fast, communication was clear, and product-engineering partnership was strong.

Current company? Engineering managers at 13+ reports. And here’s what happens:

Managers can’t attend customer interviews or user research sessions. They’re too busy with their team. So product and engineering drift apart on what customers actually need.

Sprint planning becomes transactional. There’s no time for “why are we building this?” conversations. It’s just “here’s the ticket, can you do it?”

Cross-functional alignment breaks down. When engineering managers are underwater, they can’t be strategic partners. They become ticket takers.

Product decisions slow down. Every decision requires async coordination because managers don’t have time for alignment meetings. What used to take 2 days takes 2 weeks.

The financial impact: our velocity looks okay (story points per sprint), but our cycle time from concept to customer value has doubled. We’re building efficiently but shipping slowly because of coordination overhead.

The Coordination Tax Framework

Here’s a framework I use to make this tangible for leadership:

Calculate your “Coordination Tax”:

Count the number of meetings each engineering manager attends per week
Count the number of 1:1s (both with reports and with cross-functional partners)
Count the context switches between different topics/projects
Calculate hours spent on status updates vs strategic work

For our team:

Manager with 8 reports: ~40% coordination, 60% strategic
Manager with 14 reports: ~75% coordination, 25% strategic

That gap? That’s where product-engineering partnership dies.

The Pod Model We’re Testing

Keisha, your domain-based org design resonates. We’re experimenting with product-engineering pods:

Each pod = 1 PM + 1 EM + 6-8 engineers
Pod owns a business outcome (e.g., “enterprise customer activation”)
Pod has autonomy to make decisions within their scope
Fewer cross-pod dependencies = less coordination overhead

Early results: our pod teams are shipping features 40% faster than our traditional project teams, and engineering manager satisfaction is noticeably higher.

The trade-off: you lose some engineering flexibility (can’t easily shuffle people between pods), and you need engineers who can think about business outcomes, not just technical tasks.

The Leadership Conversation Angle

Luis, your retention cost analysis is brilliant. I’d add the opportunity cost of slow decisions.

Here’s the case I made to our CEO:

Last quarter, we delayed launching a key enterprise feature by 6 weeks because of cross-team coordination issues
Sales estimated that feature would unlock 3 enterprise deals at ~$300K ARR each
6-week delay = ~$150K in lost ARR (plus competitive risk)
We delayed 4 features last quarter for similar reasons = ~$600K in lost ARR

Cost of adding 2 more engineering managers: ~$500K/year (all-in).

Return: faster decision-making, better product-engineering alignment, ability to ship features when market needs them.

That flipped the conversation from “can we afford it?” to “can we afford not to?”

My Questions

Keisha, when you reorganized around business domains, how did you handle shared services (like platform, infra, security)? Those teams by nature support multiple domains, so they don’t fit cleanly into a pod model.

Also: Maya’s point about IC tracks is spot on, but from a product perspective, I worry that pure IC paths create knowledge silos. A Staff Engineer who’s deeply autonomous might make brilliant technical decisions that don’t align with product strategy. How do you maintain cross-functional alignment when ICs are empowered to make autonomous decisions?

This is a critical conversation. The span of control problem isn’t just an HR issue—it’s a business execution issue.

cto_michelle · March 29, 2026, 2:52pm

This thread is exactly the right conversation, but I’m going to push back on some of the assumptions here.

The Uncomfortable Truth

Everyone’s treating 12.1 average reports as a crisis to be solved. But let me offer a different lens: maybe 12.1 is the new sustainable with the right model.

I’m not saying the traditional management approach works at that scale—it clearly doesn’t, as everyone here has demonstrated. But perhaps the answer isn’t “get back to 6-8” but rather “fundamentally reimagine what management looks like at scale.”

The Managerial Leverage Concept

In our organization, I’ve been experimenting with what I call “managerial leverage”: technology and process that multiply a manager’s effectiveness without adding headcount.

Here’s what we’ve implemented:

1. AI-Assisted 1:1 Preparation

Our tool scrapes PRs, commits, Slack conversations, Jira updates
Generates a pre-meeting summary: “This person shipped X, struggled with Y, mentioned career interest in Z”
Managers review 5-minute AI summary instead of manually preparing for 30 minutes
Result: More personalized 1:1s in less time

2. Automated Performance Tracking

System auto-captures accomplishments from project completions, shipped features, peer feedback
Quarterly performance reviews auto-generate first draft from structured data
Managers spend time on insights, not data gathering
Result: Performance reviews are more comprehensive AND take less manager time

3. Structured Career Frameworks

Clear career ladders with explicit expectations at each level
Engineers self-assess against framework, identify gaps
1:1s become coaching conversations about gaps, not “what do I need to do to get promoted?”
Result: Career development becomes more scalable

4. Peer Feedback Systems

Engineers give and receive peer feedback quarterly
360-degree input reduces manager as single source of truth
Managers synthesize and coach, they don’t have to observe everything directly
Result: Managers can effectively develop people they don’t work with daily

With these systems, our managers handle 11-12 reports effectively. Not easily, but effectively. Our manager satisfaction is 4.2/5, and our engineering retention is above industry average.

The Resistance Nobody Talks About

Here’s the thing nobody wants to say out loud: some managers resist this model because they prefer smaller teams.

Why? Because managing 6 people the old-fashioned way is comfortable. You can keep everything in your head. You don’t have to learn new tools. You can be the central hub of all information and decisions.

Managing 12 people with leverage requires:

Learning new tools and systems
Delegating decision-making
Trusting processes, not just people
Being comfortable with less direct control

Some managers don’t want to make that shift. They’d rather lobby for more manager headcount than modernize their approach.

The Strategic Choice

Organizations face a choice:

Option A: Get span of control back to 6-8

Requires ~40-50% more managers across the organization
Maintains traditional management model
High cost, but known approach

Option B: Enable managers to be effective at 10-12 reports

Requires investment in tools, processes, training
Requires manager mindset shift
Lower headcount cost, but change management overhead

There’s no right answer. But let’s be honest about what we’re choosing and why.

My Challenge to the Thread

Keisha, you asked “are we just delaying the inevitable?” I’d flip that: maybe we’re inventing the future of management.

The companies that figure out how to enable effective management at scale with technology leverage will have a massive competitive advantage. They’ll move faster, cost less, and scale more efficiently.

The companies that insist on 6-8 reports per manager will either:

Carry massive management overhead (expensive)
Accept manager burnout as the cost of doing business (unsustainable)
Grow slowly to maintain ideal ratios (competitive disadvantage)

Luis, your tech lead model is smart. Maya, your IC track advocacy is right. David, your opportunity cost framing is brilliant.

But I’d add: invest in manager enablement technology like your business depends on it, because it does.

My Question

For everyone in this thread: how much of your engineering budget goes to developer tools (IDEs, CI/CD, monitoring) vs. manager enablement tools (1:1 software, performance systems, feedback platforms)?

I bet it’s 95% to 5%. What if we rebalanced that to 85% to 15%? Would we unlock 10x more manager effectiveness?

That’s the experiment we’re running. Too early to declare success, but early results are promising.