The typical number of direct reports for engineering managers is shifting. Teams are getting larger, organizations are getting flatter, and the old rules no longer apply. This guide covers what the research says, what's actually happening, and how to manage effectively at any team size.
The Shift Happening Now
If you're an engineering manager or CTO, you've probably noticed: teams are getting larger. The manager who had 6 direct reports in 2022 now has 10. The director who managed 3 teams now manages 5. This isn't coincidence—it's a structural shift in how tech organizations operate.
The Numbers
Gallup data shows the average number of direct reports increased from 10.9 in 2024 to 12.1 in 2025. According to industry surveys, 48% of engineering managers have taken on more direct reports in the past 12 months, and 65% report expanded responsibilities overall.
Several forces drive this shift:
Flatter Organizations
Companies are removing management layers. The goal is faster decision-making, lower overhead, and more direct communication between leadership and ICs. Fewer managers means each manager handles more people.
Efficiency Pressure
The post-2022 shift from "growth at all costs" to profitability changed expectations. Being a successful manager now means doing more with less, keeping talent density high, and proving you're in the details while shipping fast. The manager who needs headcount to get results is viewed differently than before.
AI and Autonomy
AI tools are making engineers more autonomous. When an engineer can own full slices of a product with less coordination overhead, organizations need fewer managers per engineer. The span of control expands because the coordination cost per person drops.
Layoff Patterns
When companies reduce headcount, management layers often get cut disproportionately. Microsoft's 2025 layoffs explicitly targeted managerial roles. The engineers who remain get redistributed across fewer managers.
This isn't a temporary adjustment. The structural incentives favor larger teams per manager. Whether you're making team size decisions as a CTO or adapting as a manager who just inherited more reports, understanding this shift matters.
What Research Says: The Typical Number of Direct Reports
Research on span of control has been conducted for decades, but engineering-specific data has become more robust in recent years. Here's what the numbers actually show.
Key Statistics
- Average: 7 direct reports (with standard deviation of 5)
- Ideal (self-reported): 7 direct reports (with standard deviation of only 2)
- Effective range: 5-9 direct reports for most engineering managers
- Netflix benchmark: 6-8 reports for engineering managers
- New managers: 3-5 reports recommended for first 0-2 years
Why These Numbers?
The 5-9 range isn't arbitrary. It reflects cognitive limits on meaningful relationships and the time required for effective management.
Cognitive Capacity
Research suggests humans have cognitive capacity for meaningful, developmental relationships with approximately 4-5 people. Beyond that, the quality of each relationship degrades. You can manage more people administratively, but you can't deeply know more than a handful.
Time Math
Andy Grove's guidance in High Output Management suggests managers should spend about half a day per week on each report—not just 1:1 time, but also reviewing their work, thinking about their development, and understanding their context. Eight reports means eight hours of 1:1s alone. Add peer meetings, planning sessions, and your own work, and the math gets tight fast.
Coordination Cost
A team of 5 has 10 potential communication paths. A team of 10 has 45. A team of 15 has 105. The coordination overhead doesn't scale linearly—it scales exponentially. As teams grow, more of the manager's time goes to keeping everyone aligned rather than developing individuals.
Important Context
There is no universal magic number. As one engineering leader noted: "The magic number, skills, and structures that worked effectively at Palm, Facebook, Pebble, and Intel varied dramatically." Context matters—team experience, work complexity, organizational support, and individual manager capability all affect what's sustainable.
Engineering vs Other Functions
Benchmark data shows engineering managers typically have more direct reports than managers in other functions. This reflects the nature of engineering work—more autonomous, more project-based, and less dependent on constant manager involvement than some other roles.
However, engineering also shows more variation in span of control than other departments. Some engineering managers have 4 reports; others have 15. This variation likely reflects differences in product complexity, team seniority, and organizational philosophy.
How Team Size Affects What You Actually Do
The job of managing 5 people is fundamentally different from managing 12. It's not just more of the same work—it's a different role.
The Time Trade-off
Research shows that when a manager oversees 15 people instead of 6, each team member loses approximately 2.3 hours of meaningful development time monthly. That's time that would otherwise go to coaching, feedback, career conversations, and technical guidance.
The hours don't disappear—they get reallocated to coordination, status updates, and surface-level check-ins. The individual relationships become thinner.
Small Teams (3-6 reports): Player-Coach
With a small team, you can maintain deep context on each person's work. You likely still contribute technically. You can provide detailed code review feedback, pair on hard problems, and catch issues early. The risk is micromanagement—with this much visibility, you need discipline to let people own their work.
Medium Teams (7-9 reports): Pure Coach
This is where most engineering managers operate most effectively. You can maintain meaningful relationships with everyone. You know what each person is working on, can provide individualized coaching, and have time for both tactical and strategic work. Technical contribution becomes selective rather than constant.
Large Teams (10-12 reports): Coordinator
Management and coordination tasks start to dominate. You're spending more time in meetings, more time on status updates, more time managing dependencies. Individual development conversations become less frequent. You need to delegate coaching to senior ICs or tech leads. The relationship with each person becomes more transactional.
Very Large Teams (13+ reports): Air Traffic Control
At this size, you become effectively a coordinator who gets everything done through delegation. You can't maintain deep context on anyone's work. 1:1s become status updates rather than coaching sessions. The team often fragments into informal subgroups. This configuration can work temporarily but research consistently shows it's not sustainable.
None of these configurations is inherently wrong—but they require different approaches. Problems arise when managers try to operate at one level while their team size demands another.
Managing Effectively at Different Team Sizes
5-7 Direct Reports: The Foundation
This is where most engineering management best practices were developed. At this size, you can:
- • Hold weekly 1:1s of 30-60 minutes with real depth
- • Provide detailed feedback on work product
- • Know each person's career goals, strengths, and development areas
- • Catch early warning signs of burnout or disengagement
- • Maintain enough technical context to guide architectural decisions
The key risk at this size is over-involvement. With visibility into everything, some managers struggle to delegate effectively. Focus on outcomes over outputs, and resist the urge to weigh in on every decision.
8-12 Direct Reports: Intentional Trade-offs
This range requires deliberate choices about where you spend your time. You can't do everything you did with a smaller team. Effective managers at this size:
- • Move to biweekly 1:1s for some team members (typically senior ICs who need less support)
- • Delegate technical mentorship to staff engineers or tech leads
- • Focus their own time on highest-leverage coaching (struggling performers, high-potential ICs, critical projects)
- • Invest heavily in team processes that create visibility without requiring their constant attention
- • Use tools to maintain context that they can no longer keep in their head
Critical at This Size
Structured check-ins and async updates become essential. If you're relying on memory and ad-hoc conversations to know what's happening, you'll miss things. Tools like Vereda that capture context from standups and 1:1s help maintain visibility without adding more meetings.
13+ Direct Reports: Survival Mode or Structural Change
At this size, individual management breaks down. The math simply doesn't work—13+ hours of 1:1s per week, plus team meetings, plus planning, plus your own work. Something gives, and usually it's the quality of management each person receives.
If you find yourself here, you have two paths:
Path 1: Heavy Delegation
Identify 2-3 senior team members who can serve as de facto team leads. They handle day-to-day coaching, technical guidance, and first-line support. You manage them more closely and the rest of the team more lightly. This works when you have strong senior ICs who want leadership experience.
Path 2: Lobby for Structural Change
Make the case for splitting the team or adding another manager. Come with data: turnover risk, engagement scores, development velocity. Frame it as an investment in retention and performance, not an admission of personal limitation.
What doesn't work is pretending you can manage 15 people the same way you managed 7. The people who suffer most are the ones who need the most support—junior engineers, new hires, and anyone going through a difficult period.
Signs Your Span of Control Is Too Wide
Span problems often develop gradually. Here are the warning signs:
1:1s Are Suffering
You're rescheduling 1:1s frequently. When they happen, they're rushed. You're doing more status updates than coaching. You can't remember what you discussed last time.
Things Are Falling Through Cracks
Action items from previous conversations don't get followed up. You're surprised by issues that should have surfaced earlier. Team members are telling you about problems after they've escalated.
You Don't Know What People Are Working On
You can't summarize each person's current focus without checking a tool. You're learning about completed work in standups rather than during the process. You're not sure who's struggling.
Turnover Is Rising
Research shows a positive relationship between span of control and turnover. For every additional 10 people in a manager's span, turnover increases by about 1.6%. If you're losing people, insufficient management attention may be a factor.
You're Burned Out
65% of engineering managers reported burnout in the past year. Manager burnout often stems from being stretched too thin—trying to support too many people while handling expanded responsibilities. If you're exhausted and your team doesn't feel supported, the span may be the root cause.
These signals compound. A manager who's burned out provides less support, which increases turnover, which increases workload on remaining team members, which creates more problems to manage. Breaking this cycle often requires structural change, not just working harder.
Strategies for Managing Larger Teams
If you're managing more people than the research suggests is optimal, here's how to make it work:
Differentiate Your Attention
Not everyone needs the same level of management. Senior engineers often need less frequent 1:1s and more autonomy. New hires and struggling performers need more support. Explicitly tier your team and allocate time accordingly.
This isn't favoritism—it's matching support to need. A senior engineer who needs monthly strategic check-ins is better served by that than by weekly status meetings.
Build Leadership Within the Team
Identify engineers who want to grow toward management or tech leadership. Give them explicit responsibility for mentoring others, running team processes, or leading initiatives. This creates development opportunities for them and extends your capacity.
Be explicit about the arrangement. "I'd like you to be the go-to person for onboarding support" is better than hoping someone steps up.
Invest in Async Communication
With more reports, you can't rely on ad-hoc conversations for context. Structured async updates—whether through standups, weekly check-ins, or tools that capture work activity—give you visibility without adding meetings.
The key is making async communication genuinely useful, not performative. Ask questions that surface blockers and wins, not just status updates.
Use Tools That Aggregate Context
When you manage more people than you can keep in your head, tools become essential. You need something that shows you patterns across the team—who's mentioned blockers repeatedly, whose sentiment has shifted, what themes are emerging.
Tools like Vereda help by capturing context from 1:1s, standups, and check-ins, then surfacing signals that would otherwise get lost. This doesn't replace management—it makes meaningful management possible at scale.
Protect Your Highest-Leverage Activities
When time is scarce, ruthlessly prioritize activities that only you can do. Coaching conversations, performance feedback, and career development discussions can't be delegated. Status updates and administrative coordination often can.
When to Split the Team vs When to Adapt
Not every large team should be split. Here's how to think about the decision:
Consider Splitting When:
- • Team exceeds 12-15 reports sustainably
- • Natural subgroups already exist (different products, domains, or locations)
- • You have strong candidates for the new manager role
- • Turnover or engagement data suggests management attention is insufficient
- • Work is complex enough that deep technical context matters
Consider Adapting When:
- • Team is highly senior and self-directed
- • Work is relatively routine and well-understood
- • Situation is temporary (hiring in progress)
- • Strong informal leadership exists within the team
- • Organizational constraints prevent adding managers
Making the Case for Splitting
If you're a CTO or director deciding on team structure, or a manager advocating for change, frame the discussion around outcomes:
- • Retention: What's the turnover rate? How does it compare to teams with smaller spans?
- • Engagement: What do skip-levels and surveys reveal about whether people feel supported?
- • Development: Are people growing? Getting promoted? Building new skills?
- • Delivery: Is the team shipping effectively? Are quality issues emerging?
The research supports that teams with reasonable spans outperform on these metrics. But local data from your own organization is more persuasive than industry benchmarks.
Frequently Asked Questions
What is the typical number of direct reports for an engineering manager?
Research shows the average is 7 direct reports, with the effective range being 5-9 for most engineering managers. Companies like Netflix target 6-8 reports for optimal balance between technical mentoring and career development.
However, industry data from Gallup shows the average has increased from 10.9 in 2024 to 12.1 in 2025 as organizations flatten. The "typical" number is shifting upward, even as the "optimal" number remains in the 5-9 range.
How many direct reports is too many for an engineering manager?
Beyond 12-15 direct reports, most engineering managers become ineffective at individual development. Research shows managers with 7 or fewer reports score 20% higher on team engagement than those managing 15+.
At 15+ reports, managers spend all their time coordinating rather than coaching, teams fragment into subgroups, and individual development time drops by approximately 2.3 hours per person monthly. This configuration is sustainable only with heavy delegation or structural support.
Why are engineering teams getting larger per manager?
Several factors drive this trend: post-2022 efficiency pressure pushing "do more with less" mentality, flatter organizational structures with fewer middle management layers, AI tools enabling engineers to be more autonomous, and explicit targeting of management layers in recent tech layoffs.
48% of engineering managers report taking on more direct reports in the past 12 months. The focus has shifted from growth-at-all-costs to profitability, and larger spans per manager are one result.
What is the ideal span of control for new engineering managers?
New engineering managers (0-2 years experience) should start with 3-5 direct reports. This smaller team allows them to develop coaching skills, establish credibility, learn management fundamentals, and make mistakes without catastrophic consequences.
As they gain experience and demonstrate effectiveness, the team can grow to 6-8 reports. Throwing a new manager into a team of 10+ sets them up for failure and burns out both the manager and the team.
How do I know if I have too many direct reports?
Key warning signs include: 1:1 meetings becoming shorter or less frequent, action items falling through the cracks, not knowing what each person worked on last week, rising turnover on your team, feeling like you're only fighting fires, and engineers expressing they don't feel supported.
Research shows 65% of engineering managers reported burnout in the past year, often linked to expanded team sizes. If you're exhausted and your team still isn't getting what they need, the span is likely too wide.
Does team seniority affect optimal span of control?
Yes, significantly. Managing a team of senior engineers is typically less overhead than managing junior engineers. Senior ICs are more self-sufficient, require less hands-on coaching, and can take on informal leadership responsibilities that extend your capacity.
A manager might effectively handle 10-12 senior engineers while struggling with 7-8 junior engineers. When assessing your span, weight the team's experience level heavily in your calculation.