The Management-Load Score: Grading Spans and Layers From Public Profiles

You have a target company and a question your own HRIS cannot answer for someone else's org: is it over-layered and management-heavy, lean, or normal for its stage? This guide is for strategy, research, and talent-intelligence analysts who need a defensible verdict built only from public profiles, where you have titles but no reporting lines. It supplies the scoring model, the peer-set construction, the manager-title correction that everything turns on, and the confidence bounds to render a verdict you can defend.

Every published span-of-control guide grades your own org from an HRIS field that flags who manages people. That field does not exist for a competitor. What you have instead is a pile of public titles, and titles lie in one specific direction. The whole method below is built to correct that lie and to say plainly where the estimate ends and the guess begins.

What the management-load score measures

The management-load score is a stage-matched verdict - over-managed, normal, or lean - built from three metrics computed off public profiles: span of control, percent-managers, and layer depth. No single one of them is enough on its own.

The reason you need all three is that they contradict each other in useful ways. A firm at 15% managers with a 6:1 average span is flat with broad oversight. The same 15% at 3:1 span is layers stacked on layers. Report one number and the verdict is meaningless. The score exists to force the pair into view and to anchor the result against peers rather than a population average.

The definitions you compute:

• Span of control = number of employees managed divided by number of managers.
• Percent-managers = people-managers as a share of total headcount.
• Layer depth = reporting steps from the CEO to a front-line employee, where the top leader is layer 0, their direct reports are layer 1, and so on.

The lower layers are where the work is. Get the corrected manager count wrong and every number above it is wrong in the same direction.

Why the average is a trap and the shape is the signal

Do not anchor a verdict on a single population mean. Gallup's average span rose from 10.9 in 2024 to 12.1 in 2025, up from 8.2 in 2013 - but that average is dragged up by the 13% of managers who oversee 25 or more people, while roughly two-thirds manage fewer than 10.

If you grade a knowledge-work company against 12.1, you will call almost every one of them lean, because knowledge-work spans typically run 6 to 8. The headline number describes a distribution that includes warehouse and retail operations, where spans of 15 to 25 are normal. The mean is not your benchmark. The stage-and-function-matched range is.

The lesson for external scoring: build the benchmark from the segment your target actually sits in, and read the shape. Two companies with the same average span can have completely different structures once you separate the broad-span operational functions from the narrow-span leadership tiers.

Published benchmarks by stage and by work type

Two tables anchor the benchmark. The first is percent-managers by stage and segment. The second is span by the type of work being managed. Match your target to a row in each before you score anything.

The spread here is the point. Ravio's climb from 13.5% at growth stage to 16% at late stage happens while IC share stays flat, which means organizations add management as they scale without necessarily adding proportional productive capacity. Your stage-matched benchmark must therefore rise with stage. Hold a growth-stage yardstick against a late-stage firm and you will flag normal maturation as bloat.

Read these two tables together. A SaaS company whose profiles are 80% engineers should be judged against a 5-7 span, not against the 12.1 population average and not against an operations-heavy peer.

The manager-title error, and why it only runs one way

This is the reason the guide exists. A "manager" in org design is anyone with at least one direct report - an operational definition, not a title. Public profiles do not expose reporting lines, and titles routinely mislead: Sales Director, Program Manager, Account Manager, Customer Success Manager, and Account Executive are all titles commonly held by individual contributors.

The critical property is that the error is not symmetric. People are given "Manager" as a seniority marker far more often than genuine managers get filed under an IC title. So uncorrected title-counting almost always overstates management load. If you skip the correction, your default failure is to call companies over-managed that are not.

Refolk's index makes the size of the trap visible. There are 43,042 US profiles with "Engineering Manager" in the title against 353,811 with "Software Engineer" - a manager-to-IC title ratio of about 1:8.2, or a 10.8% engineering-manager share.

Treat that 10.8% as an upper bound, not a measurement. Some of those "Engineering Manager" titles belong to player-coaches or IC tech leads who manage no one. And the player-coach problem cuts the other way too: a documented 97% of managers still perform IC work alongside their leadership duties, so a lean-looking span can hide managers who barely manage.

Titles inflate management load in one direction, so the uncorrected verdict is almost always too heavy.

How to classify an ambiguous title

When you hit a "Manager" title with no visible reporting line, do not guess from the noun. Cross-read three things: the described scope in the profile summary, the normalized level band, and any team-lead language.

• Likely people-manager: references a team size, "led a team of", "grew the org", sits in an M3-E9 level band, direct reports named elsewhere.
• Likely IC: "Manager" is the seniority suffix on an IC function (Account Manager, Customer Success Manager, Program Manager), scope described as individual delivery, sits in a P3-P6 band.
• Ambiguous, hold for bounds: title says manager, scope is silent, level unclear. Count these into your confidence band, not your point estimate.

The classifier that separates the manager-titled ICs from the real people-managers is the single highest-leverage step in the whole procedure. Everything downstream inherits its accuracy.

Counting layers, and why depth is always an estimate

Layer depth is the count of reporting steps from the CEO to a front-line worker, top leader at layer 0. Most organizations run effectively on 5 to 7 layers; beyond about 8 layers you should expect slow decisions and diluted accountability. McKinsey is more aggressive, arguing even the largest orgs should not exceed six layers and that truly agile ones often run only three.

Here is the honest limit. Clean layer counting requires that each employee except the top leader has exactly one primary manager. Public data cannot confirm that. Dual reporting, matrixed roles, and hidden dotted lines all corrupt the count, and you cannot see any of them from a profile. So layer depth from public data is an estimate, and you should state it as a range, never a single integer.

A useful sanity check: an idealized org with no more than five layers and no manager spanning more than five reports caps out around 781 people. If your estimated depth implies a far larger or smaller org than the headcount you know, one of your inputs is wrong.

The scoring procedure

Run these seven steps in order. Sources disagree on whether span and layer depth are computed in parallel or layers first; either works, provided the corrected manager count in step 4 is settled before you compute anything in step 5.

The peer set deserves a warning of its own. Some practitioners try to find the "right" number by industry benchmark, and the analytical evidence is that a peer-benchmark approach, while appealing, often causes new problems. Use peers to locate your target on a distribution, not to prescribe what it should be.

Pulling those two counts by hand across a target and four peers is a day of tab-switching. Refolk returns them as a single grouped answer, which is where the friction in steps 1 and 2 actually lives.

Turning the metrics into a verdict with bounds

The verdict is a two-axis judgement: how the corrected percent-managers compares to the stage benchmark, and how the average span compares to the work-type benchmark. Plot the target on both and the quadrant names the call.

Attach bounds, not a point verdict. Your confidence band should widen with two things: the count of ambiguous titles you held in step 4, and the gap between your profile count and the company's known headcount. State both. A defensible output reads: "Late-stage SaaS, estimated 19% managers (range 15-23% given title ambiguity), average span 4.5, 6-7 layers; verdict over-managed against a 16% stage benchmark, medium confidence, coverage 40% of headcount."

A scoring rubric you can copy

Company: [name] | Stage: [growth/late] | Headcount (known): [n] | Profiles pulled: [n] | Coverage: [%]
Corrected managers: [n] | Percent-managers: [%] (range [%]-[%])
Average span: [x:1] | Work-type benchmark span: [range]
Estimated layers: [low]-[high] from CEO=0
Ambiguous titles held: [n]
Stage benchmark percent-managers: [%]
Verdict: over-managed / normal / lean | Confidence: low / medium / high
Drift over 8 quarters: [+/- points] | Event alignment: [funding / M&A / reorg / none]

How this goes wrong

The failure modes below are the most valuable part of the standard, because every one of them produces a confident wrong answer. Most of them push the verdict toward "over-managed," which is exactly why an uncorrected read is untrustworthy.

• Title-counting inflates management load. The default false positive: a target scored over-managed because it uses "Manager" as an IC seniority marker. Check by cross-reading described scope and level band, not the noun.
• Player-coach undercount. With 97% of managers still doing IC work, a lean-looking span can hide managers who barely manage. Check for team-lead language and small reported teams.
• Layer miscount from dual reporting. Clean counting needs each employee to have exactly one primary manager, which public data cannot confirm. Report depth as a range and call it an estimate.
• Peer-set contamination. Grading a product company against an ops-heavy peer imports the 15-25 operational span as normal and makes the product company look artificially lean. Match function mix, not just headcount.
• Sampling bias toward the visible. Public profiles over-represent engineers and senior staff who maintain profiles and under-represent frontline and ops, which deflates true percent-managers. Compare profile count to known headcount and flag coverage gaps.
• Drift mistaken for strategy. A jump to 17% managers may be deliberate M&A integration inheriting duplicate layers, not bloat. Align the timeline against funding, M&A, and reorg events before calling drift.
• Legal false comfort. "It's public" does not clear GDPR for individual-level collection, where a name, job title, and employer are personal data. Keep collection at aggregate count level and document your lawful basis.

Staying inside the defensible legal lane

The legal risk is in method, not data. Reading publicly visible pages is largely protected: a 2019 ruling reaffirmed by the Ninth Circuit in April 2022 found the US CFAA did not apply to automatic collection of publicly accessible data, so platforms cannot fence off public pages to only certain parties.

But contract and tort law bit hiQ hard: a $500,000 judgment plus a permanent injunction ended its LinkedIn scraping. And under GDPR, public does not mean free - a name, job title, and employer is personal data whether or not it is public. Regulators have acted: CNIL fined KASPR 240,000 euros over a roughly 160-million-contact LinkedIn database, and the Dutch DPA fined Clearview AI 30.5 million euros for scraping 30 billion-plus photos.

The defensible lane for this guide's aggregate use is to work from publicly visible aggregate data - job counts, title counts, hiring trends - from unauthenticated public indexes, without targeting individuals. Because the management-load score only needs counts by title and function, you never need individual-level personal data to produce it. That is not a happy accident; it is why the method was built on aggregate counts.

Verify before you ship the verdict

Run this checklist before the number leaves your desk. If any item fails, the verdict is not defensible yet.

Keeping the score current

A management-load verdict has a shelf life, because the thing it measures moves. Percent-managers drifts with hiring, layoffs, and integration, so treat the score as a snapshot with a re-check date, not a permanent label.

Set the observation window at up to eight quarters and re-pull on the same cadence you use for the rest of your account intelligence. The published drift signal is qualitative: a company that was at 12% managers two years ago and is now at 17% with no strategic rationale has a structural drift problem. There is no established "X points per year equals bloat" rule, so watch the direction and always test it against events before you conclude.

Two things to re-check specifically. First, the manager-title mix shifts as companies adopt "conscious unbossing" - a Robert Walters finding reports 72% of professionals would rather progress as ICs than take a middle-management role, which over time thins the genuine-manager population behind stable-looking titles. Second, your benchmark tables age; re-anchor them when the underlying stage data updates rather than trusting a number you cached a year ago. The method is evergreen. The numbers inside it are not, and the discipline is knowing which is which.