LeadDev's 2025 State of Engineering Management report found that 40% of engineering leaders now manage more direct reports than they did a year ago. The average engineering manager oversees 8-12 engineers, up from 6-8 three years ago. The cause is not org growth. It is the talent shortage: companies cannot hire fast enough, so they stretch existing managers thinner instead of adding management capacity.
The result is predictable. Managers who should spend 30-40% of their time on strategic work (architecture reviews, technical roadmap, process improvement) spend 80%+ on people management: 1:1s, sprint planning, standups, performance reviews, conflict resolution, and the endless stream of Slack DMs that starts at 8 AM and does not stop until 7 PM.
I manage engineers for a living. My observation: the single most common reason engineering teams underperform is not bad engineers. It is overloaded managers.
The Numbers
LeadDev (2025):
- 40% of engineering leaders manage more people than last year
- Average span of control: 8-12 direct reports (up from 6-8)
- 62% say they do not have enough time for strategic technical work
- 78% report that administrative tasks have increased
Gartner (2025):
- Engineering manager turnover increased 23% year-over-year
- The #1 reason for manager departure: workload exceeding capacity
- Average tenure of engineering managers: declining for 3 consecutive years
Google's Project Aristotle and re:Work research:
- Manager quality is the single strongest predictor of team performance
- Teams with good managers are 25-30% more productive than teams with overloaded managers
- The inflection point: managers with more than 9 direct reports show measurable decline in team satisfaction and output
Why 8-12 Direct Reports Breaks
1:1 meetings eat the calendar
A good 1:1 with a direct report takes 30-45 minutes every week or biweekly. At 10 direct reports with weekly 1:1s, that is 5-7.5 hours per week on 1:1s alone. Add sprint planning (2 hours), daily standups (2.5 hours), retrospectives (1 hour), and the manager's own leadership meetings (3-5 hours), and the calendar is 60-70% meetings before any actual work begins.
The remaining 30-40% of time is not "strategic work time." It is the time between meetings — 30-minute gaps that are too short for deep thinking and too long to waste. The manager fills them with Slack, email, and PR approvals. The strategic work — architecture decisions, process improvements, hiring plans, technical debt prioritization — never gets scheduled because there is no block large enough.
Code review becomes a bottleneck
Many engineering managers still participate in code review. At 10 direct reports producing 3-5 PRs per week each, that is 30-50 PRs the manager should review. Reviewing a meaningful PR takes 15-45 minutes. Even cherry-picking the most important 10, that is 2.5-7.5 hours per week on code review.
When the manager cannot keep up, PRs sit in review for 2-3 days instead of hours. Developers context-switch to other work. The sprint slows. The team ships less. Nobody blames the manager's span of control. They blame the "slow PR review process" and add a tool to fix it (which creates more tool sprawl).
Context switching destroys management quality
An overloaded manager handles: the senior developer who wants a promotion path conversation, the junior developer who is struggling with the codebase, the client who is unhappy with last sprint's velocity, the VP who wants a headcount plan by Friday, and the production incident that just landed in the alert channel. All between 10 AM and noon.
Each of these requires a different mode of thinking. The promotion conversation requires empathy and long-term perspective. The struggling developer requires patience and teaching. The unhappy client requires diplomacy and data. The VP requires a spreadsheet. The production incident requires technical diagnosis.
Switching between these modes 10 times per day is exhausting. The manager's quality of attention declines with each switch. The promotion conversation gets cut short because the incident needs attention. The incident analysis is shallow because the VP's headcount request is overdue. Nothing gets the full attention it deserves.
What It Costs
An overloaded manager costs more than an additional manager salary. The costs are distributed across the team:
Engineer attrition. Engineers who do not get adequate 1:1 time, career development, or technical mentorship leave. 24% of developers are unhappy and the #2 reason is lack of growth opportunities. Replacement cost: $150K-$250K per departure. One departure that a better-resourced manager would have prevented pays for a year of management capacity.
Reduced velocity. Google's research shows 25-30% productivity difference between teams with good versus overloaded managers. For a 10-person team at $80K-$160K per engineer, that is $200K-$480K in annual productivity loss.
Technical debt accumulation. A manager who is too busy for architecture reviews lets suboptimal decisions ship. Over 12 months, the accumulated technical debt becomes a tax on every future sprint. The 45% project overrun rate is partly a manager capacity problem: nobody had time to catch the architectural issue in sprint 2 that caused the overrun in sprint 12.
Burnout. The manager burns out first. Then the team burns out because the burned-out manager cannot support them. The cascade is predictable and expensive.
How to Fix It
Reduce span of control
The research is clear: 5-7 direct reports is optimal. Above 9, quality declines measurably. If your engineering managers have 10-12 directs, you need more managers, not more efficient managers.
The math: promoting a senior engineer to tech lead and giving them 4-5 direct reports costs one senior IC salary. The productivity gain from unburdening the existing manager is worth 2-3 senior IC salaries. The investment pays for itself in one quarter.
Separate people management from technical leadership
The model where one person manages engineers and also makes architecture decisions breaks at scale. Split the roles: engineering managers handle people (1:1s, career development, hiring, performance), and tech leads handle technology (code review, architecture, technical standards, debt prioritization).
This is how we operate at EltexSoft. Our fractional CTO handles technical leadership. The client's internal manager (or our PM) handles coordination and people management. The CTO reviews architecture. The PM runs sprints. Neither is overloaded because neither is trying to do both jobs.
HeyTutor ran this way for 9 years. Our co-founder handled technical leadership. The founders handled business priorities. Nobody was a 12-report manager trying to also review PRs and also attend board meetings and also write the technical roadmap.
Augment, do not stretch
When the talent shortage prevents hiring a new manager, augmenting the team with a retained engineering team that brings its own technical leadership reduces the existing manager's load without requiring a new hire.
Snapwire had 30 engineers and needed to scale. Instead of hiring 10 engineers and adding a manager, they brought our team of 10 with our tech lead included. The existing managers did not gain 10 more directs. Our tech lead managed our engineers. The span of control stayed manageable for everyone.
The manager overload problem is a capacity problem. Solve it with capacity: more managers, split roles, or retained teams that bring their own leadership. Do not solve it with tools, processes, or exhortations to "work smarter." An overloaded manager is not failing because they are not smart enough. They are failing because the job is too big for one person.
Last updated September 1, 2024