How Many Direct Reports Should a Tech Manager Have?

How many direct reports should an engineering, data, or AI manager have?

The honest answer is not seven, ten, or fifteen. It is the number of people that manager can support while still making the decisions, creating the clarity, and managing the risks the team needs.

That answer is less convenient than an industry benchmark. A benchmark fits neatly into a restructuring spreadsheet: compare managers, remove a layer, distribute the reports, and record the apparent savings. Yet two teams with eight people can impose radically different management loads. One maintains a stable internal platform with experienced engineers and clear service boundaries. The other is launching an AI agent across several business systems, hiring two new people, negotiating security controls, and discovering that its evaluation data is unreliable.

The headcount is identical. The management work is not.

The most useful way to choose a span of control is therefore to start with a capacity decision, not an organization-chart target. The framework below is designed for leaders reviewing AI, data, platform, and software teams. It also gives managers a more credible way to explain why their current load is sustainable—or why adding one more report would remove something important from the job.

Start with a load map, not a magic number

Use six dimensions to describe the team before discussing its size. Rate each dimension as low, medium, or high based on evidence from the last quarter, not optimism about the next one.

A team that is low across most rows can often support a wider span. A team that is high across several rows usually needs a narrower one, stronger support roles, or a reduction in the manager’s other responsibilities.

This is not a formula that converts six ratings into a precise headcount. Its purpose is to expose the assumptions hidden by the headcount. If a leadership team wants to increase a manager’s direct reports, it should be able to name which load will fall, which support will improve, or which management service will become less frequent.

That last point matters. A wider span always changes the job, even when the change is not written down.

Current averages describe the market, not your team

Recent evidence shows why one benchmark is misleading. Gallup’s 2026 analysis of span of control found that the average U.S. team grew from 10.9 people in 2024 to 12.1 in 2025, while the median stayed at six. A smaller group of very large teams pulled up the average; most managers still led fewer than ten people.

The same Gallup span-of-control research found that 97% of managers had some individual-contributor responsibility and that the median manager spent 40% of their time on it. Manager engagement was lower when hands-on work exceeded that level, and the problem became worse as teams grew. Gallup also found that meaningful weekly feedback was associated with high employee engagement across team sizes.

Those findings do not establish six as the ideal number. They establish something more useful: team size interacts with the design and quality of the manager’s job.

A benchmark can still start a conversation. It can reveal unusual structures, such as a department with many managers leading two people or one manager leading thirty specialists. It cannot finish the conversation. Before treating an outlier as waste, leaders need to inspect why the structure exists and whether the work could be redesigned safely.

Translate the manager’s job into capacity

An organization chart counts reporting relationships. A capacity review counts recurring obligations.

Begin with the management services the team should reliably receive. These might include:

• useful individual feedback and career conversations
• priority decisions and scope negotiation
• technical or product judgment where authority is unclear
• hiring, onboarding, and performance management
• coordination with security, legal, finance, operations, and other teams
• incident support and escalation
• quality review for data and AI systems
• team learning, succession, and capability development

Then ask how often each service must happen and how much preparation it requires. A weekly check-in is not merely its calendar duration. A good manager may need to understand the work, review a decision, follow up on a blocker, and carry an agreement into another meeting. A performance problem or a new hire can require much more attention for several months. A production incident can consume the reserve that made the normal week possible.

Next, subtract the work that is not people management. Many technical managers remain the senior architect, strongest debugger, customer escalation point, data owner, or executive translator. Calling that a “player-coach” role does not create extra hours. If hands-on delivery remains essential, the team size has to reflect it. If leadership wants a wider span, some technical ownership must move to staff engineers, platform leads, product partners, or other managers.

Finally, preserve a disruption reserve. A plan that consumes every available management hour works only when nobody resigns, no priority changes, no deployment fails, and no stakeholder escalates. That is not a plan for technology work. It is a plan for a fictional quiet week.

AI-assisted work can raise the supervision burden

It is tempting to reason that AI increases individual output, so one manager should be able to supervise more people. That may eventually be true in some stable workflows. It is not a safe default.

AI can remove administrative work: summarizing routine updates, drafting documentation, organizing feedback themes, or making project information easier to search. Those improvements can return time to a manager. But AI-assisted execution can also increase the rate at which drafts, code changes, experiments, and product ideas reach review. Faster production upstream may simply move the bottleneck to technical judgment, security, evaluation, or integration.

Google Cloud’s 2025 DORA research on AI-assisted software development describes AI as an amplifier of the surrounding organizational system. That is an important warning for team design. Clear priorities, fast feedback, good internal platforms, strong testing, and healthy documentation can turn assisted work into better delivery. Weak controls and confused ownership can turn it into faster rework.

AI systems also introduce work that a conventional task count misses. Someone must decide whether evaluation covers important failure cases, whether a retrieval system respects permissions, whether an agent can act without approval, how model changes are tested, and who owns quality after release. A manager does not have to perform every check. They do have to ensure the checks have owners and consequences.

Therefore, do not widen a span based on estimated AI productivity alone. First measure whether AI has reduced total coordination and review load. Generated output is not finished output.

Four team patterns need different answers

Consider how the load map changes the decision for common technical teams.

A mature platform team may have stable services, experienced engineers, clear on-call ownership, reliable documentation, and strong staff-level technical leadership. The manager may be able to lead a larger group because peer coordination and operating systems carry much of the daily load.

An applied AI product team may have fewer people but more ambiguity. Product expectations shift, model quality is probabilistic, data access needs negotiation, and security or legal review arrives early. A smaller team can still consume substantial management capacity because decisions cross functional boundaries and failures are difficult to predict.

A distributed data team may look mature on paper while serving many business units across time zones. Each analyst or engineer can have different stakeholders, definitions, and delivery rhythms. The manager’s load comes less from technical supervision than from individualized context and priority conflict.

A growing software team may have a stable architecture but several new hires. Its span can perhaps increase later, after onboarding, documentation, and peer mentoring become effective. Designing for the future state too early deprives people of support during the transition that is supposed to create that state.

This is why span should be reviewed as a condition, not assigned as an identity. “Managers here have twelve reports” is a blunt policy. “Managers can lead wider teams when work is stable, technical leadership is distributed, feedback remains frequent, and coordination load is controlled” is an operating principle.

Watch for work that disappears from the calendar

Overload rarely announces itself as a clean failure. The manager keeps attending meetings and answering messages. The organization assumes the wider span worked. What disappears first is usually the work that has no immediate deadline.

Career conversations become less specific. New hires learn by interrupting whoever seems available. Strong contributors inherit mentoring and coordination without explicit authority. Architectural decisions remain unresolved until implementation forces them. Stakeholder conflict reaches the team unfiltered. AI evaluation becomes a launch checkbox. One-to-one meetings turn into status collection. Quiet performance issues remain quiet.

These are leading indicators, not soft complaints. Left alone, they become rework, delayed decisions, preventable incidents, regretted turnover, and dependence on a few overloaded people.

A monthly span review can monitor a small set of signals:

• canceled or repeatedly shortened one-to-one conversations
• time from blocker identification to a decision
• onboarding time and unresolved role ambiguity
• unplanned work reaching the team
• decisions waiting on the manager
• recurring after-hours escalation
• quality or risk work postponed to protect delivery dates
• senior individual contributors carrying unrecognized people-management work

The point is not to create another dashboard. It is to detect when the formal structure has pushed essential work into delay, silence, or unpaid organizational debt.

For a broader view of this invisible load, see Manage AI Team Capacity Without Burning Budget. Capacity is not only the number of tasks assigned; it includes the clarity, review, and coordination needed to finish them well.

Widen a span only with an explicit exchange

There are legitimate reasons to flatten an organization. A layer may add approvals without improving decisions. Two small teams may have nearly identical work. Better platforms can make information and ownership clearer. Experienced teams may need less supervision and more autonomy. Cost matters too.

But a responsible change states the exchange. If a manager takes four more reports, what else changes?

• Does hands-on technical ownership move to a named lead?
• Are teams becoming more homogeneous, reducing individualized coordination?
• Will product or program management absorb stakeholder work?
• Are new hires already through their highest-support period?
• Can employees still receive meaningful feedback at a useful frequency?
• Which approvals or reporting rituals are being removed?
• What signals will trigger a reversal or added support?

Run the change as a reversible operating experiment. Establish a baseline for feedback, decision speed, manager workload, team health, delivery, and quality. Review it after 60 to 90 days. Ask the team privately what has become harder, because a manager who wants the redesign to succeed may underreport their own overload.

If the experiment fails, the only remedy is not necessarily another management layer. The organization might narrow the manager’s technical duties, appoint a team lead, improve documentation, simplify dependencies, clarify decision rights, add program support, or divide the team around coherent work. Structure should follow the diagnosed load.

This complements Promote First-Time Tech Managers With a Safety Net. A new manager and a newly widened span are both system changes. Both deserve explicit expectations, coaching, evidence, and a reversible path.

Management quality and management capacity are different

A highly capable manager can often lead a larger team than an inexperienced or poorly suited manager. Strong delegation, clear communication, judgment, and coaching matter. Yet talent should not become an excuse for structural overload.

Organizations often give the strongest manager the hardest team, the most cross-functional project, and extra direct reports. The manager initially succeeds, which is taken as proof that the design works. In reality, exceptional effort may be compensating for a weak system. When that person burns out or leaves, the hidden dependency becomes visible.

Management development should increase useful capacity: better feedback, sharper prioritization, stronger delegation, and calmer handling of conflict. It cannot eliminate the time required for human attention or the consequences of complex work.

The related note Middle Managers Matter More in AI-Heavy Teams explains the value that capable managers can add. The span decision asks a separate question: has the organization left them enough capacity to add it?

Choose the span that protects the work

There is no virtue in a small team by itself. Too many layers can slow decisions, weaken autonomy, and turn managers into messengers. There is also no virtue in a large team by itself. A flat chart can conceal missing feedback, delayed decisions, and coordination work transferred to senior specialists.

The right span of control is the one that fits the team’s current work, people, risk, dependencies, and management model. It may change when a system stabilizes, new hires mature, a platform improves, or responsibilities move. It should also shrink when the organization enters a migration, launches a high-risk AI workflow, reorganizes, or asks managers to become hands-on contributors again.

Count direct reports, but do not stop there. Count the decisions, relationships, exceptions, transitions, and review obligations the manager must carry. Name the management services the team needs. Protect room for disruption. Then choose a structure and test whether it delivers those services in practice.

An efficient organization does not maximize the number of people under every manager. It makes management capacity visible and spends it where the work needs judgment, clarity, and care.