The Peer Spans-and-Layers Playbook: Public Profiles to a Dated Range

This playbook is for strategy, research, and talent-intelligence analysts who have been asked how lean one of their functions is next to a named peer, and who have public profiles rather than the peer's org chart. It takes you from one peer and one function to a dated estimate of people-manager share, IC-to-manager ratio, and layers from function head to frontline, each as a low-high range, with your own HRIS figures restated on identical counting rules. Plan on six to seven working days per peer-function pair; the stage durations below are planning estimates, not measured times.

What does a peer spans-and-layers benchmark actually measure?

A peer benchmark produces three numbers for one function at one date: the share of people who manage people, the number of individual contributors per manager, and the number of distinct reporting levels from function head to frontline. Each needs a fixed definition before any external org design benchmarking from public data can mean anything.

Define the terms once and use them everywhere:

• People manager: someone with at least one direct report. A title containing "Manager" is not enough.
• Individual contributor (IC): anyone in the function who is not a people manager.
• Manager share (p): people managers divided by total function headcount, M / N.
• IC:manager ratio: ICs per manager, which is (1 - p) / p.
• Average span: (N - 1) / M. Because managers report to managers, this is roughly IC:manager + 1.
• Layers: the count of distinct reporting levels between the top of the unit and the frontline.

The last identity matters more than it looks. Peers announce IC:manager figures; consultancies publish spans. Amazon's CEO asked each s-team organisation "to increase the ratio of individual contributors to managers by at least 15%", which is an IC:manager target, while Bain's benchmarks are spans. Put one beside the other without converting and you invent a gap of about one report per manager.

What the published benchmarks say

These are the context lines for your chart. None of them is function-specific with a stated sample size, and that gap is why you are building your own.

Three limits to state in any deck that uses this table:

• Bain's benchmark is old, though still widely cited. Treat it as a reference frame, not a current norm.
• Bain's layer counts are company-wide. Your function-level count, from function head to frontline, will be smaller and cannot be set against 8 to 9 directly.
• Bain's function guidance is by work type: skills-based roles such as engineers at six to eight, task-based roles such as call-centre supervisors at 15 or more. Support teams may sit in either bucket depending on the work, so do not assume.

For calibration of expectations: Bain reports that companies in its database improved spans by 24 percent and cut layers by 14 percent on average, Intel moved manager spans from six or seven to eight or nine, and AT&T cut management layers by half to seven. Those are the sizes of change leadership will have in mind when they ask "how lean is the peer".

Why do raw public profiles make every peer look top-heavy?

Managers are heavily over-represented on public profiles, so a raw count of manager titles against IC titles understates span by a large factor. In Refolk's index, the raw IC-to-manager-band ratio for US software engineering is 1.09, against the roughly 5 to 6 implied by Bain's average span.

The mechanism is how people write headlines. Managers tend to write their function into the title ("Director of Software Engineering"), while ICs often do not. A keyword search on the function name therefore catches a larger fraction of managers than of ICs. The table below shows the raw cohorts and how clean the manager band actually is.

Read this table with its limits in view. The 5x figure is illustrative: it is confounded by headline-keyword matching, and the title samples are 25 per query with only the top 10 visible. What it proves is direction and rough magnitude: uncorrected, any peer will look top-heavy. What it cannot give you is a correction factor to apply. That has to be calibrated locally (step 5).

External evidence points the same way without quantifying it. A World Bank and LinkedIn methodology study found that young, skilled people with at least a bachelor's degree are more likely to be on LinkedIn than those with less education. A separate study of job-ad data found a significantly higher share of management, computer, and mathematical occupations than the labour market as a whole; that is about ads, not profiles, so treat it as an analogy. No published coverage rate by seniority exists.

Which counting rules must be fixed before collecting anything?

Write a one-page rule sheet covering the manager definition, the function boundary, contractor treatment, and the snapshot date, and get it signed by the analyst and an HRBP before the first profile is pulled. Rules chosen after you have seen the numbers will drift toward the answer leadership expects.

The most common HRIS convention is to count anyone with at least one direct report as a manager. Use it, because it is the definition you can apply to both sides. On contractors and vendors there is no published counting standard for external spans benchmarks, so the choice is yours; what matters is that it is written down and applied identically to the peer column and your own.

Peer:
Function:
Snapshot date (pull date for peer, effective date for HRIS):
Prepared by (analyst):
Signed off by (HRBP):

1. People manager = at least one direct report, inferred from title coding (Appendix B)
2. Function boundary = titles in Appendix A include list; everything on the exclude list is out
   Adjacent roles decided: TPM [in/out], SRE [in/out], enablement/ops [in/out]
3. Contractors and vendors = [in/out]; profiles where status cannot be read = [rule]
4. Stale profiles = drop if no update in more than [N] months (state threshold; it is a judgement call)
5. Layers = distinct rungs from function head to frontline; a rung needs [N] evidencing profiles
6. Sample floor = do not publish manager share or IC:manager below [N] coded profiles
7. Coverage factor source = [own firm vs HRIS / UK organogram], calibrated per band
8. Second-coder sample = 10% of rows; agreement recorded in the coding log

The procedure, step by step

Run these eight steps in order for each peer-function pair; steps 1 and 2 are shared across peers if you benchmark several against the same function.

There is a genuine disagreement about direction. Bain works top-down from leadership to the frontline. A practitioner deck argues the opposite: start with the frontline "doer" layer, work out what they do and how many managers there should be above them, and work up. For an external estimate I combine them: build the ladder top-down, because senior rungs are the best-evidenced on public profiles, but size the function bottom-up, because the frontline is where the headcount and the coverage gap both live.

How do you code titles as people manager, ambiguous, or IC?

Code from the title text itself with a rule written for that function, send every "Manager" title without a team noun to an ambiguous list for hand review, and never use a platform's automated seniority label as a proxy for managing people. Title coding is where most of the error enters, and no one has published an error rate for title-based manager classification checked against known org charts.

Three coding rules carry most of the weight:

1. Code the head noun, not any token. Refolk's sales sample included "Sales Enablement Product Manager" and "Executive Sales Assistant to Director of Sales". Both contain manager-sounding words; neither is a people manager.
2. Write the rule per function. In Refolk's index, 93% of sampled engineering manager-band titles were unambiguous people managers, against 38% in sales. Sales titles encode territory and rank rather than reports, so a rule tuned on engineering will badly inflate sales manager share.
3. Recode from the title, ignoring seniority bands. The automated Senior/Entry band for US software engineering contained a CTO, a VP of Engineering, two of them in one case, and a Head of Engineering. Seniority describes level, not reports.

Have a second coder independently code 10% of rows and log the agreement rate. No published threshold exists for acceptable agreement, so set yours in the rule sheet and report it in the appendix; a steering committee will trust a number with a visible agreement rate more than one without.

Much of the ambiguity can be removed at retrieval rather than at coding. Asking Refolk in plain English for "sales managers with direct reports, not account managers, at HubSpot in North America" returns people rather than keyword hits, which shrinks the ambiguous pile you have to hand-review. You still code every row, but you start from a cleaner list.

How do you correct for coverage and count layers?

Calibrate a ratio of observed public profiles to true headcount for each band on an organisation whose structure you know, divide each peer band count by its own factor, then build the layer ladder from coded titles with an evidence count on every rung. Without the correction, the manager-heavy skew described above flows straight into the peer's span.

Calibrating the coverage factor

You need a known structure to calibrate against. Two work:

• Your own firm. Run steps 3 and 4 on your own company's public profiles for the same function, then compare each band with your HRIS. This is the best source because it is the same function and a similar labour market.
• UK government organograms. UK departments publish junior data in CSV format giving the number of full-time-equivalent junior staff reporting to each senior post, a series that started in October 2010 and is still released. Profiles of a department's staff can be set against it.

For each band (at minimum, people manager and IC; better, each rung), compute:

• factor for band = observed profiles in band / true headcount in band
• corrected peer band count = observed peer profiles in band / factor for band

If your two calibration sources give different factors, keep both. Run the estimate once with each and carry the outer bounds into the published range. A single point factor hides the largest uncertainty in the whole exercise.

Building the ladder

Order the coded people-manager titles from function head down to frontline and count distinct rungs. Note how many profiles support each rung. Report layers as a low-high pair: the low end counts only well-evidenced rungs, the high end includes rungs supported by one or two profiles.

Hold three limits in view:

• Nobody has published a procedure for this or measured how far a title-ladder count diverges from true reporting depth. The UK organogram files let you test that divergence yourself; do it once and note the result in the method appendix.
• Rank titles add phantom rungs. A sales ladder that runs Account Executive, Senior AE, Regional VP, Managing Director may be one reporting level dressed in four titles.
• Use the current snapshot only. Retro-edits are concentrated in tech and among workers under 30, so a historical ladder reconstructed from profiles drifts more in engineering than elsewhere.

For orientation, peers in one people-analytics practitioner forum reported company-wide layer counts of 8, 9, and 12. Your function-level count should be well below those, and if it is not, suspect rank titles before you suspect bureaucracy.

How many coded profiles before you can publish?

Treat roughly 400 coded profiles in the function as the floor for publishing manager share and IC:manager. Below it, the 95% range on IC:manager is wide enough to cover both Bain's average and best-in-class companies, so the number cannot answer the question leadership asked.

The method is a Wilson interval on manager share, converted to IC:manager with (1 - p) / p. Wilson behaves better than the normal approximation when manager counts are under 20, which is exactly where small peers land: 100 coded profiles at a 15% share is only 15 managers. The table shows how the range tightens around a point estimate of 5.7 ICs per manager.

All values are computed with the standard formula at an observed share of 15%; neither the floor nor the method is a sourced industry benchmark. Use n = coded profiles, the actual evidence, rather than the corrected headcount when you compute the interval; inflating n with corrected counts makes the range look tighter than the evidence allows.

How this goes wrong: failure modes and false positives

Most failed peer benchmarks are wrong in the same direction: they make the peer look more manager-heavy than it is, because manager-sounding titles, rank titles, and profile coverage all push manager share up. Check each mode below before a number leaves your desk.

1. The "Manager" token. Product, Account, and Program Managers get coded as people managers and inflate manager share. Looks like: a sales function with a span near 2. Check: hand-review every "Manager" title without a team noun; only 38% of sampled sales manager-band titles in Refolk's index were unambiguous.
2. Rank titles. "Managing Director" and "VP" in banking and many sales orgs are ranks, not spans; three MDs appeared in Refolk's sales sample. Looks like: extra layers and a top-heavy ratio. Check: look up the industry's grade convention and code ranks as ambiguous until confirmed.
3. Vendor seniority labels. The automated Senior band for software engineering held CTO and VP titles, a 29% executive leakage in the visible sample. Looks like: ICs counted as executives or the reverse. Check: recode every row from the title itself.
4. Coverage skew. Raw profile ratios understate span by roughly 5x in the illustrative comparison. Looks like: every peer, and your own firm, looks top-heavy. Check: apply a calibrated per-band factor; if your own uncorrected profile ratio looks absurd against your HRIS, the peer's does too.
5. Stale and edited profiles. Leavers still show as current. In NBER working paper 35546, roughly one in five established US users goes back and edits the title or description of a job they have already left, rising to 38.1% among users under 30. Looks like: a peer that still "has" managers it let go. Check: drop profiles with no update in more than 12 months; that threshold is a judgement call, not a sourced standard, so state it.
6. Span versus IC:manager. Span is roughly IC:manager + 1. Looks like: a peer's announced ratio sitting one below Bain's span and read as "leaner than average". Check: convert everything to one metric before charting.
7. Small n. At 100 coded profiles the IC:manager range is 3.3 to 9.7, which covers Bain's average and best-in-class values at once. Looks like: a confident point estimate on a thin sample. Check: apply the floor and show the range, never the point alone.
8. HRIS flag versus title coding. A "manages others" flag counts player/coaches that title coding misses. Looks like: your own firm appears more manager-heavy than the peer for reasons of method. Check: restate HRIS by titles (next section).

A peer that looks dramatically top-heavy is usually a coding problem before it is a finding.

Restating your own numbers and keeping the benchmark current

Rebuild your own column from HRIS using the same title coding, the same function boundary, and the same snapshot date as the peer, not the HRIS "manages others" flag, and then re-pull the peer on a fixed cadence because profile changes surface with a lag. A comparison holds up in a steering committee only when both columns were counted the same way.

Restating the HRIS column

HRIS systems may classify managers by job title, job level, or a "manages others" flag. For this comparison, export titles and run them through the exact coding rule you used on the peer, including the ambiguous list and how you resolved it. Then compute share, IC:manager, span, and layers with the same formulas. Show the flag-based figure as a reconciliation line beneath, so anyone who knows your internal number can see where the difference comes from.

Convert any announced peer targets before comparing. As illustrative arithmetic: if a function's IC:manager is 5.7, a 15% increase takes it to about 6.6, which moves average span from about 6.7 to 7.6, an increase of roughly 13%, not 15%. Amazon later said it had reached its target, according to secondary reporting; even with that, you know the direction of a peer's change, not its level.

Peer spans-and-layers benchmark: [Function], [Peer] vs [Own org]
Peer snapshot: profiles pulled [date] | Own org: HRIS effective [same date]
Rules: rule sheet v[N], signed [analyst], [HRBP]

Metric                 | Peer (low to high)  | Own org (title-coded) | Own org (HRIS flag, reference)
Manager share          | [x% to y%]          | [z%]                  | [z%]
IC:manager             | [a to b]            | [c]                   | [c]
Average span           | [a+1 to b+1]        | [c+1]                 | [c+1]
Layers, head to front  | [low to high]       | [n]                   | n/a

Evidence: [n] coded profiles; second-coder agreement [x%]; coverage factors per band [list] from [source]
Context only: Bain average span 6 to 7, best in class 10 to 15 (company-wide, not function-specific)
Not established: function-specific published spans; title-ladder vs true-depth divergence (tested on [organogram], result [x])

Keeping it current

One modelled study puts the lag between a real job change and its appearance in aggregated profile data at 0 to 120+ days. Three practical consequences:

• Date-stamp every pull and compare only like-dated snapshots.
• Do not snapshot right after a peer announces a restructure; the profiles will not reflect it yet.
• Re-pull on a fixed cadence and keep the rule sheet versioned, so a change in the number is a change in the peer, not a change in method.

The re-pull is where the time goes on repeat runs. Saving the exact plain-English request in Refolk, for example "Customer support team leads and support managers at Zendesk in Europe", lets you rerun the same population on the next snapshot date instead of rebuilding the pull, and keeps the boundary identical across runs.