Span of Control (2026): Definition, How to Calculate It, Wide vs Narrow and How to Find the Real One

TL;DR

• Span of control is the number of people who report directly to one manager. A manager with eight direct reports has a span of control of eight.
• Average span is calculated as the number of people with a manager divided by the number of managers. A wide span means many direct reports and fewer layers. A narrow span means fewer reports, closer supervision and more layers.
• There is no universal right number. McKinsey describes five manager archetypes whose spans run from three to five up to more than 15, depending on the work.
• The span on the org chart is often not the real one. Sentra compares the HRIS reporting lines with who actually asks whom and who actually approves what, across email, chat, meetings and the ERP, and raises the gaps to the owner with the evidence.

What span of control means

Span of control is the number of direct reports a manager is responsible for. The term comes from management and HR practice, and it is also called span of management, as Wikipedia notes. A team lead with six direct reports has a span of six, regardless of how many people sit below those six.

Span of control and organizational layers move together. For the same headcount, wider spans produce a flatter company with fewer layers of management. Narrower spans produce a taller company with more layers. Most span of control reviews are really reviews of both: how many people each manager supports, and how many levels a decision or a piece of information has to cross.

How to calculate span of control

There are two numbers worth calculating. The first is each manager's individual span. The second is the company or department average.

• Individual span = the number of people who report directly to that manager.
• Average span = number of people who have a manager / number of managers.

In a single reporting tree, everyone except the chief executive has exactly one manager. So for a company of N people with M managers, the average span is (N minus 1) / M. A 241-person company with 30 managers has an average span of 240 / 30 = 8.

The average hides more than it shows. Always look at the distribution as well. A department with an average of eight might have two managers with 20 reports each and several with two. Teamflect works through the same direct reports divided by managers calculation.

Layers from span

Span also tells you roughly how many layers a company needs. With a constant span of s and a headcount of N, the number of layers is about the logarithm of N to the base s. For 10,000 people, a span of 5 needs about six layers, while a span of 10 needs about four. Real companies are never that uniform, but the arithmetic shows why widening spans removes layers quickly.

Why span is not just a headcount question

In 1933 the consultant V. A. Graicunas argued that a manager's load grows much faster than the number of reports, because the manager also deals with relationships between reports and with groups of them. His count of potential relationships is n x (2 to the power of (n minus 1) + n minus 1). With 5 reports that gives 100 potential relationships, and with 10 reports it gives 5,210, as summarized on Wikipedia. Few people use the formula to set spans today, since most relationships between reports never need the manager. Its point still holds: adding reports adds coordination, not just one more one-to-one.

Typical span of control ranges

There is no generally applicable optimum. Wikipedia's summary of the research concludes that the right span depends on structure, technology, the work and the capability of managers and staff. The published ranges that are well sourced are these.

McKinsey's five archetypes are player/coach, coach, supervisor, facilitator and coordinator. The practical lesson is to set span by what the manager actually does. A manager who spends most of the week doing individual work, or training new people on complex tasks, supports few reports. A manager who coordinates experienced people doing similar, well-defined work can support many.

Treat any single "ideal number" you read with care. Many guides quote a specific range without a source, and the ranges do not agree with each other.

Wide vs narrow span of control

The factors that push a span wider or narrower are the ones Wikipedia lists: how similar the tasks are, how capable and experienced the staff are, how capable the manager is, how spread out the team is, how much coaching the role needs and how much non-management work the manager carries.

How to find your real span of control

The span in the HRIS is the formal one. It records who each person reports to on paper. The span that drives a manager's workload, and the company's speed, is the number of people who actually depend on that manager for decisions, approvals and help. The two often differ, a gap our guide to the informal organization vs the org chart covers in detail.

Check four things.

1. Dotted lines and matrix reports. A person who reports to a functional head on paper but takes daily direction from a project lead adds to the project lead's real span. Count both.

2. Approvals outside the reporting line. Pull approval records from the ERP, expense tool and procurement system and group them by approver. A manager who approves purchases or expenses for three teams has a real span well beyond their direct reports.

3. Who people go to. Ask each person in a team who they went to for decisions in the last month, or look at who is consistently included in decisions in meetings and threads. Someone named by people outside their team carries load the chart does not show.

4. Vacancies and acting roles. A manager covering for an empty role above or beside them has temporarily taken on that role's span as well.

Then compare. For each manager, put the formal span next to the real one.

A real span far above the formal one is two problems. It is a workload problem, because that person is the queue every decision waits in, the pattern a bottleneck analysis finds. It can also be a control problem. If one person approves spend for three teams and also records or receives it, that breaks segregation of duties.

Worked example: the span the chart did not show

The figures are illustrative. A 241-person company runs a spans and layers review. The HRIS shows 30 managers and an average span of eight, with a finance operations lead who has four direct reports. On paper, she looks underused, and the review proposes merging her team into another.

Her approval records tell a different story. She approves purchase requests for finance, procurement and facilities, because the facilities manager's approval rights were never reassigned after he left, and the procurement head asked her to cover temporarily a year ago. In chat, people across the three teams send her decisions on vendor terms that the policy says belong to their own managers. Counting everyone who routes approvals and decisions through her, 22 people depend on her each week.

Merging her team would have widened a span that was already the widest in the company. The right fixes are different: reassign the facilities approval rights to a named owner, return procurement approvals to the procurement head, and check whether she both approves and receives any of the same purchases. Her formal span of four can stay as it is.

Common mistakes in span of control reviews

• Using only the average. One number for a department hides the managers with 20 reports and the managers with two.
• Setting one target span for everyone. Span should follow the work. A coordinator of standardized work and a player/coach on complex work should not have the same target.
• Trusting the HRIS as the whole picture. Reporting lines miss dotted lines, approvals and the people everyone asks.
• Cutting layers without moving decisions. Removing a layer while leaving its approvals unassigned just sends those approvals to whoever is left, often one person.
• Ignoring approval rights after people leave. Approvals that were never reassigned build up on whoever covered, and nobody sees it in the chart.

How Sentra catches this automatically

A spans and layers review is usually a snapshot of the HRIS. The real reporting and approval lines live in other places: the ERP's approval records, who is asked for decisions in chat and email, who is in the meetings where decisions are made.

Sentra joins what the systems of record say with what people do. It reads the HRIS reporting lines and the approval records in the ERP alongside email, chat, meetings and documents, and works out who is actually working on what and who decisions route through. It knows when a fact became true and when it stopped, so it can see that approval rights were handed to someone "temporarily" a year ago and never handed back.

When one person's real span runs far beyond their formal one, or one person approves for three teams, Sentra raises it to the owner who can act, such as the COO, the CFO or the HR lead, with the evidence: the reporting line, the approval records and the threads that show the routing. A named person approves each finding before it reaches anyone else. Every claim cites its source, and permissions follow the source, so a communication pattern is visible only to people who could already read the messages behind it. Sentra replaces none of your systems. The HRIS stays the record of formal structure. Sentra holds SOC 2 Type II and ISO 27001 certifications and runs in the cloud, in an isolated VPC or air-gapped on premises.

To see your formal and real spans side by side, book a demo.

How to start a span of control review

• Pull the formal spans. Export reporting lines from the HRIS and calculate each manager's span and the distribution, not only the average.
• Add approvals. Group 90 days of ERP, expense and procurement approvals by approver, and compare with formal spans.
• Pick the outliers. Look at the five managers with the widest real spans and the five with the narrowest formal spans, and talk to each.
• Set targets by archetype. Decide what each manager mainly does, then set a target range for that kind of role rather than one number for the company.
• Reassign before you restructure. Fix approvals and acting roles first. Then decide whether any layers or teams need to change.

FAQ