How Many Direct Reports Are Too Many for an IT Manager
Where’s the tipping point between impressive and impossible?
Managing an IT team is like spinning plates, where the plates are your direct reports. One or two? Graceful. A half‑dozen? Impressive. A dozen? The audience stops admiring and starts counting the seconds to a crash.
Where’s the tipping point between impressive and impossible? While there’s no one-size-fits-all answer, research and experience provide dependable guardrails. In this post, we’ll explore those limits and take a closer look at span of control, decision making, and title inflation.
On paper, a software team looks clean: a few engineers, a QA, maybe a designer, all reporting neatly to you. But in reality, it’s far messier. Code reviews pile up, incidents flare at night, requirements shift mid-sprint, and someone always needs a career check-in right when you’re handling a blocker. Eventually, you start to ask: How many direct reports can I juggle before something breaks?
That question is captured in a familiar management concept: span of control. Span of control refers to the number of direct reports a manager can effectively oversee. It’s a measure of how wide or narrow a manager’s supervisory responsibilities are. As Will Larson argues in “An Elegant Puzzle”, it’s “seven, plus or minus two.”
How to determine the ideal number of direct reports
For IT managers, the right span depends on six key factors:
Factor 1: Work complexity
The more complex and variable the work, the more time each team member will need from their manager.
For example, leading a team building custom infrastructure tools requires more guidance and oversight than managing a team running well-defined scripts for server maintenance.
Factor 2: The team’s experience
The more experienced the team, the less control it requires.
A group of senior engineers who’ve worked together for years likely needs far less day-to-day support than a team of junior developers just starting out. Onboarding, mentoring, and code reviews all take time, and newer teams require more of it.
Factor 3: How much error the system can tolerate
The higher the stakes, the narrower the manager’s span should be.
In some environments, small mistakes are no big deal—maybe a minor bug that gets fixed in the next sprint. But in others, like fintech or healthcare, a single slip-up could have serious consequences.
Factor 4: Your own maturity as a leader
A seasoned manager who’s handled multiple teams and tough trade-offs might confidently manage more people.
But for someone new to the role, or still juggling individual contributor work, fewer reports is more realistic.
Factor 5: Market speed
If your company ships updates weekly and reacts quickly to user feedback, your team will need tight feedback loops and quick decisions.
That’s hard to maintain if your calendar is packed with 10 one-on-ones.
Factor 6: The strength of the tools in place
Strong internal systems—like shared dashboards, automated reports, and async status updates—can take pressure off the manager.
But if updates still live in long meetings or scattered spreadsheets, there’s less time for coaching and decision making.
When these factors are aligned, a manager might thrive with 8–10 reports. But if several are working against them—new hires, complex projects, fast deadlines, and clunky business processes—it’s wiser to keep the number much lower.
Let’s study each of the factors mentioned above and how they influence the ideal number of reports.
Complexity eats bandwidth: Why complex work needs smaller teams
IT teams vary widely in complexity, speed, and responsibility, which means the ideal number of direct reports depends on the kind of work being done.
In a network operations center (NOC), tasks are routine and standardized. Operators follow clear procedures and respond to alerts using pre-set rules. Since most of the work is predictable and automated, a manager can oversee 15 to 20 people with minimal need for hands-on coaching.
Compare that to a platform engineering team building internal cloud tools. Their work is often ambiguous and complex, involving frequent architectural decisions and constant prioritization. These engineers need regular input from their manager, which limits how many people one person can support—five or six might already be too many.
As a rule of thumb: if the work is too complex to explain in a quick whiteboard session, the team likely needs closer guidance and a smaller span of control. The more support each person needs, the fewer reports a manager can handle effectively.
More experience, less oversight
The experience level of your team strongly affects how many people you can realistically manage. A seasoned group—say, senior engineers who helped build your internal system—can operate with minimal guidance. They often flag issues early, mentor others, and move independently, making it possible for a manager to support 8 or more direct reports.
A junior team, however, is a different story. New graduates or entry-level engineers need far more support—pair programming, documentation walkthroughs, and frequent unblocking sessions. Sometimes you’re the “rubber duck” they talk to just to work through a problem aloud.
That kind of support is important but time intensive. It’s not just about shipping code, it’s about helping new engineers gain confidence, develop good habits, and grow into effective team members. In these cases, a smaller span of control is essential.
If hiring another manager isn’t an option, consider assigning a senior engineer as a mentor or buddy. It can ease the load while helping junior team members ramp up faster. Either way, it’s not just the number of reports that matters—it’s how much support each one needs.
The cost of mistakes should shape your team’s size
Every team makes mistakes, but not all mistakes carry the same weight. Your organization’s tolerance for error plays a big role in how many people a manager can support.
In low-stakes environments, like SaaS tools or internal platforms, bugs are often minor—maybe a broken UI or a short outage. Customers are usually forgiving if issues are fixed quickly, and teams can move fast with more autonomy and less oversight.
Now consider high-stakes domains like fintech or healthcare. Here, a small error could lead to financial loss, legal trouble, or a serious breach of trust. As a result, engineering processes tighten: reviews are stricter, QA is deeper, and releases are more controlled.
In this kind of environment, managers need to be closely involved—reviewing work, providing direction, and ensuring standards are met. And that means supporting fewer direct reports.
If your team operates in a high-risk space, a smaller span of control isn’t wasteful—it’s necessary.
Let your role, not your title, guide your span
How many people you can manage depends not just on your team, but on what kind of manager you are. In IT, most fall somewhere between two managerial archetypes: the player‑coach and the coach.
The player‑coach still writes code, reviews PRs, or jumps into incidents. Since they split time between hands-on work and people management, their effective span is smaller—three to five direct reports is usually the max before performance starts to slip.
The coach, on the other hand, focuses on guiding the team, developing talent, and coordinating across functions. They spend less time coding and more time enabling others, so they can usually manage six to seven reports, or up to eight in a stable, experienced team.
It’s important to be honest about your role. As Camille Fournier’s “The Manager’s Path” puts it, title inflation can blur the lines—someone called “Director” who’s still deep in the code is really a player‑coach and should have a smaller span.
Your responsibilities—not your title—should guide how many people you lead. Getting that balance right prevents burnout and ensures your team gets the support they need.
What is the difference between a team lead and a manager? Find out here ->
Fast teams, fewer reports
How fast your product moves and how often your team needs to react directly affects how many people you can manage.
A mature B2B product that ships quarterly allows for longer planning cycles, steady priorities, and decisions made in batches. In that setting, managing eight or nine people may be realistic.
But if you’re running a consumer-facing app or a cloud services team that ships weekly or daily, you need to make quick calls, respond to shifting priorities, and stay hands-on. You can’t wait for the next sprint to adjust course.
Managing ten people in that environment means constant context switching and decision fatigue. It’s not sustainable for you or your team.
In fast-moving teams, it’s not about micromanaging—it’s about staying responsive. And that means keeping your span of control tight.
The tight tools can free up your time (or eat it)
Great tools don’t just help your team—they help you manage more effectively. When systems are automated and transparent, you spend less time chasing updates and more time coaching, planning, and making decisions.
For example, a team with solid CI/CD pipelines, shared dashboards, and async workflows—like recorded demos or lightweight RFC templates—runs with less friction. That efficiency can let you support seven or eight people without losing quality, because the system carries much of the communication overhead.
Now picture the opposite: updates live in an outdated spreadsheet, docs are scattered, and every proposal feels like starting from scratch. You’ll spend more time untangling the mess than leading the team.
In fast-moving environments, good tooling isn’t optional. It often makes the difference between managing effectively or burning out trying to keep up.
Signs you’re over the line
Even if all six factors look good on paper, reality leaks through your calendar. Watch for:
- One‑on‑ones slipping from weekly to “when we find time.”
- Code reviews piling up because you’re the only approver
- Feedback becoming vague or generic—something that could apply to anyone on the team
- High performers start leaving because they don’t see a clear path for growth
- Alerts and incidents start wearing people down as they bounce between team members without clear ownership or resolution
If two or three of these issues persist for more than a sprint or two, there’s a good chance your span of control is too wide.
Designing an IT‑friendly span of control
Once you understand the key factors that influence how many people a manager can reasonably support, the next step is to design your org structure around them.
Plan for the org you’ll need, not just the one you have
Think beyond today’s team structure and sketch out what your engineering org might look like two or three releases from now. As headcount grows, roles shift, and systems get more complex, a reactive approach to structure often leads to unnecessary layers and confusing reporting lines. A little forward thinking now prevents a lot of cleanup later.
Add managers when milestones demand it
Don’t tie management roles to headcount milestones. Instead, add leaders when the work requires it—like launching a new product, expanding globally, or needing 24/7 coverage. Roles should support business needs, not just numbers.
Beware title inflation
Promoting someone to “Manager” or “Lead” without changing their responsibilities causes confusion. If they’re still coding full time, others may expect support they can’t provide. Match titles to actual scope to avoid masking gaps.
Check your span when a manager hits six reports
When a manager hits six direct reports, check in. Can they still give timely feedback, mentorship, and strategic input? If not, consider splitting the team, rebalancing responsibilities, or adding a team lead.
Invest in real management training
Good managers aren’t born—they’re trained. Give new leads mentoring and practical tools for coaching, feedback, and people development. A supported manager can lead more effectively—and hold a healthier span.
A quick stress formula
If you’re not sure whether your current span of control is manageable, rate each factor 1 to 3 and then use this simple formula to gauge the pressure you’re under:
(work complexity × error stakes × market pace) ÷ ( team experience × tooling maturity ) = stress score
- Score < 5 → a span of 10 – 12 might fly.
- Score 5‑9 → aim for 6 – 8.
- Score ≥ 10 → keep it 4‑6 and distribute leadership.
Example
Let’s say you manage a cloud infrastructure team at a fast-growing startup. You’re trying to decide whether managing eight direct reports is realistic.
Start by rating the factors:
- Work complexity = 3 (you’re building internal tooling and custom automation across environments)
- Error stakes = 2 (mistakes might disrupt deployments but aren’t business-critical)
- Market pace = 3 (you ship updates weekly and react quickly to new needs)
- Team experience = 2 (a mix of junior and mid-level engineers)
- Tooling maturity = 2 (you have some automation, but updates still require a lot of manual coordination)
Plug into the formula:
(3 × 2 × 3) ÷ (2 × 2) = 18 ÷ 4 = 4.5
Score = 4.5, which suggests you’re probably fine with up to 10–12 direct reports if everything else stays stable.
But let’s say you’re onboarding three new team members soon (dropping team experience to 1) and your CI/CD pipeline is still flaky (tooling maturity = 1):
(3 × 2 × 3) ÷ (1 × 1) = 18 ÷ 1 = 18
Now your score jumps to 18, which is a strong sign that you should reduce your span to 4–6 and consider distributing leadership—perhaps by appointing a team lead or adding a manager.
Bringing it back to people
Management isn’t just task-tracking—it’s hands-on work that takes time and care. Your team needs check-ins, feedback, and space to talk through challenges. That’s how trust grows, and engagement lasts.
But when your span stretches too far, those moments disappear. Support fades, decisions slow down, and burnout creeps in for you and your team.
Take fifteen minutes this week. List your direct reports, score the six factors, look ahead, and ask yourself: are you leading with intention, or just trying to stay afloat? If things are slipping, don’t hesitate to rebalance. Your team—and your headspace—will thank you.
