# The Competitor Org-Chart Reconstruction: Reporting Lines and Headcount by Function

*You can produce a confidence-tagged competitor org chart down to a chosen layer plus a headcount-by-function breakdown, from public profiles, postings, and press alone.*

- Canonical URL: https://www.refolk.ai/guides/competitor-org-chart-reconstruction
- Pillar: Market and talent intelligence
- Format: Playbook
- Published: 2026-09-12
- Last reviewed: 2026-09-12
- Reading time: 15 min
- Keywords: reconstruct competitor org chart, headcount by function estimate, who reports to whom from public profiles, map competitor team structure, estimate headcount from linkedin profiles

## Key takeaways

- Confirmed reporting lines cluster at the top of the house because SEC filings, press, and verified directories name executives; mid-layer lines are almost always inferred, so grade quality falls as you descend.
- Raw public-profile counts mislead in two directions at once: one analysis found only 10 to 20 percent of profiles reflect current employment, while non-platform staff go uncounted, so per-cell confidence tags matter more than the headline number.
- Grade every node with the Admiralty Code, which scores source reliability A to F and information credibility 1 to 6 on separate scales, and promote a node from inferred to confirmed only when a second independent source corroborates it.
- Country choice changes your evidence base more than function choice: Refolk's index holds 349,217 US 'Software Engineer' profiles against 22,300 in Germany, a 15.7x thinner pool that warrants systematically lower credibility grades abroad.
- Span-of-control benchmarks let you back-fill hidden layers: at firms of 1,000-plus employees managers average 5.89 reports, so missing individual contributors become estimable rather than guessed.
- Plan for roughly annual decay: companies revamp their organizations on average every three years, and 82 percent of executives report a redesign, 70 percent within the past two years.

This playbook reconstructs a competitor's reporting structure and its headcount split across functions using only public data: profiles, job postings, and announcements. It is written for strategy and research teams, talent-intelligence analysts, and operators sizing a market who need a structure map they can defend in a review, not a vendor's marketing screenshot. By the end you will have produced a reporting-line org chart down to a chosen layer plus a headcount-by-function breakdown, with every cell tagged by a confidence level and its supporting evidence.

Most published guides on reconstructing a competitor's customers, revenue, or talent outflow stop short of the hardest artifact: the structure itself. Reporting lines and function-level headcount are where scattered evidence has to be triangulated and where an honest analyst tags what they know against what they merely infer. That tagging discipline is the whole job. A chart that looks confident everywhere is a chart that is wrong somewhere without telling you.

## What public sources yield reporting-line evidence, and what each one proves

Four source classes carry reporting-line evidence, and each proves something different from what it suggests. Treat none of them as a finished answer on its own.

Public profiles segment the org by title and team name, but a title alone only suggests a line. The real evidence hides in prose: recent hires often reveal their manager in an "about" section, a recommendation, or a first-day post, and phrases like "reports to," "team lead," or a manager shout-out are free intelligence in plain sight. Job postings are stronger on structure: a "you will report to the Head of Growth" line names the hiring manager's exact title and a team name narrows the org from thousands to a handful. But a posting names a title, not a person, and companies leave the manager off on purpose when they want to.

Executive-hire press releases name a person and a level, but they describe intended structure, which is not always the operational one. Public org-chart directories are the fourth input. On a directory like The Org, accuracy depends on verification: a company that has claimed its page (the blue check) should be close to 100 percent accurate, while unverified pages are weaker. For public companies, SEC filings such as the 10-K and the proxy let you piece together executive listings, subsidiary structures, and board disclosures, though rarely a complete or up-to-date chart.

| Source class | Proves | Only suggests |
|---|---|---|
| Public profiles | Title, team, start date | The reporting line above a role |
| Job postings | Manager's title, team name | Who the person is; manager may be hidden |
| Executive press releases | A person and a level | That the structure is operationally live |
| Verified org directory | A confirmed node (if blue-check) | Anything on an unverified page |

> **Rule:** Confirmed needs an explicit statement
>
> A reporting line is confirmed only with an explicit statement: a posting's "will report to" clause, a press release, or a verified directory node. Everything triangulated from title, team, and span is inferred until a second independent source corroborates it.

## Why raw profile counts are not headcount

The gap between the number of public profiles and true active headcount is real and directional, and it points both ways at once. That is why you correct the count and tag it, rather than trusting it.

One analysis found only 10 to 20 percent of profiles truly reflect real-world, up-to-date employment. The error runs in two directions. Many profiles are never updated when people leave, so the count overstates true active headcount. At the same time it undercounts staff who are not on the platform and new hires who have not updated yet. One vendor puts employee-count accuracy at 70 to 90 percent depending on company size and industry. Because the inflation and deflation forces push against each other, a raw count can look right by luck, which is exactly why per-cell confidence tags matter more than the headline figure.

The correction is a sector-specific scale factor, not a single universal ratio. Coverage is reasonably reliable for software and financial services, and routinely under- or over-counts in agriculture, healthcare, manufacturing, and professional services because of low platform adoption and inflated self-reported ranges. Treat tech and finance as high-coverage and apply a multiplier elsewhere; a single universal coverage ratio is not established publicly, so state the multiplier you used and where it came from.

**10-20% - Share of profiles that reflect current, up-to-date employment**

The rest are stale, incomplete, or inactive, which is why a raw profile count is never a headcount.

Refolk's index gives a sense of how large a single function's public footprint can be, and how much country changes it. In Refolk's index there are 349,217 profiles titled "Software Engineer" in the United States against 22,300 in Germany, a multiple of about 15.7x. A thinner pool abroad means non-US nodes deserve systematically lower credibility grades, because you are reconstructing from fewer signals.

| Country | "Software Engineer" profiles | Multiple vs Germany |
|---|---|---|
| United States | 349,217 | 15.66 |
| Germany | 22,300 | 1.00 |

## A title-to-function taxonomy that will not double-count

Segment profiles into 8 to 12 primary business functions and never more than 15, because beyond that you get overlapping definitions that cause mapping errors. This taxonomy is the backbone of the headcount-by-function estimate, so build it before you count anything.

Anchor to a standard rather than inventing categories on the fly. SOC 2018, the O*NET occupation taxonomy, or a custom B2B GTM framework of Sales, Marketing, Engineering, Finance, HR, Operations, Legal, and IT all work. A GTM practice often crosses 10 to 25 functions with 5 to 8 seniority levels; keep the function count at the low end unless you have a reason.

Run a two-pass parse. First extract seniority indicators (Junior, Lead, Manager, VP, Chief) into a separate column and strip them from the string. Then map the remaining phrase to the functional taxonomy. This matters because a single dataset of 50,000 resumes can contain 30,000 unique title strings, and you cannot map that variety cleanly if seniority and function are tangled in one field.

Two rules prevent double-counting. Draft written internal definitions to disambiguate borderline cases like Product Management versus Engineering, and route anything that resists into a residual "Other" bucket for manual review. And keep both the original and the normalized title: never overwrite the raw title, because the normalized value is a tag, not a replacement. If a review challenges a cell, you need the raw string to defend it.

> **Watch out:** Too many buckets collapses the map
>
> Going beyond 15 functions usually means your definitions overlap, and overlapping definitions push the same person into two counts. Keep 8 to 12 functions with written boundary rules and audit the "Other" bucket by hand.

Function size varies enormously, and Refolk's index shows the shape using title proxies. Software Engineer runs 5.30x the volume of Product Manager in the US, and Account Executive 3.65x. If your reconstructed chart shows a Product function larger than Engineering at a software company, that is a flag to re-check, not a finding.

| Function proxy (title) | Profiles (US) | Ratio to Product Manager |
|---|---|---|
| Software Engineer | 349,217 | 5.30 |
| Account Executive | 240,568 | 3.65 |
| Product Manager | 65,849 | 1.00 |

## Grading confidence with the Admiralty Code

Grade every node and every count with the Admiralty Code, a scheme in use since the 1940s and adopted by NATO as AJP-2.1. It scores a report on two characters: source reliability from A to F, and information credibility from 1 to 6.

The two scales are deliberately separate because reliable sources can pass bad information and questionable sources can later be confirmed. Separating them gives you a structured way to communicate confidence instead of a single fuzzy "high/medium/low." A confirmed executive named in a 10-K and a verified directory is close to A1. An OSINT claim with no detail from a sometimes-accurate source is logged as C3, not confirmed. The grade travels with the cell so a reviewer can see exactly why you believe it.

Promotion is the mechanism that turns an inferred node into a confirmed one: a second source, independent of the first, corroborates the same line. Independence is the load-bearing word. If both sources trace back to the same press release, you have one source cited twice, and grading credibility by consistency with what you already believe is how confirmation bias creeps in.

#### Placing a node on the Admiralty grid

Horizontal axis runs from Low information credibility to High information credibility. Vertical axis runs from Low source reliability to High source reliability.

| Quadrant | What it means |
| --- | --- |
| Reliable source, thin claim | Hold as inferred; seek detail before promoting |
| Reliable source, corroborated claim | Confirm the node and cite both sources |
| Weak source, thin claim | Log as a lead only; do not chart yet |
| Weak source, corroborated claim | Promote cautiously if the second source is truly independent |

*Reliability of the source and credibility of the claim are graded separately, so you know which kind of doubt you are carrying.*

I ran this search: `People at Ramp who joined in the last 6 months and mention who they report to` - [see the full result list](https://www.refolk.ai/s/3pjsxr5akd).

*Returns recent hires whose profiles or posts name a manager, giving you the explicit "reports to" statements that promote an inferred node to confirmed.*

Finding those first-day posts and manager mentions by hand is slow. Asking [Refolk](/) in plain English for the exact slice of people you need, filtered to recent joiners who name a manager, collapses the manual profile-crawling into a single query and hands you the corroboration evidence directly.

## The reconstruction procedure, start to finish

Run these nine steps in order. The spine is deliberately OSINT-first: primary-interview shops sometimes run interviews first and use external sources to check them, but this playbook inverts that and uses public sources as the backbone.

#### From scattered profiles to a confidence-tagged chart

1. **Scope and freeze the target** - Pick the company, the layer depth, and a snapshot date. Fix a target list and state the as-of date, because the map decays.
2. **Pull the raw population** - Export current profiles by company plus open postings and press releases into a deduped roster with raw titles, teams, locations, and start dates.
3. **Normalize titles into functions** - Run the two-pass parse, stripping seniority then mapping to an 8-to-12 function taxonomy. Budget roughly 10 minutes per unique title.
4. **Estimate headcount by function with coverage correction** - Apply a sector scale factor per function and record raw count, adjusted count, and the multiplier used.
5. **Build the skeleton from confirmed nodes** - Seed the tree with verified directory nodes, SEC-listed executives, and postings or press that explicitly state a line.
6. **Infer the middle layers** - Filter People one to two levels above each role and match recent-hire manager mentions. Tag each candidate parent as inferred.
7. **Grade every node and count** - Assign an Admiralty two-part grade to every node and every count so no cell is untagged.
8. **Verify and promote** - Seek a second independent corroboration for each inferred line; promote it or leave it inferred, and document the reviewer pass.
9. **Set the refresh trigger** - Define a monitoring rule on exec hires and headcount deltas, and schedule a re-run date.

Steps 3 and 6 are where the time goes. Normalizing titles takes 1 to 3 days and longer at scale: two to four weeks for a company with 500-plus unique title strings. Inferring the middle layers takes 1 to 2 days per pass. Everything else is roughly half a day each. The reviewer pass in step 8 is non-negotiable; it is the difference between a chart you can present and a spreadsheet of guesses.

#### How evidence narrows from raw pull to confirmed chart

| Stage | Figure | Note |
| --- | --- | --- |
| Raw public profiles pulled | 349,217 | Full US "Software Engineer" pool as a scale reference |
| Filtered to the target company | hundreds | Deduped roster for this employer |
| Normalized into functions | 8-12 buckets | Headcount-by-function estimate |
| Nodes with a stated line | dozens | Confirmed skeleton plus inferred middle |

*Each stage sheds volume: most of the raw population never becomes a confirmed node, and that is the intended shape.*

## Back-filling the layers you cannot see with span benchmarks

Span-of-control benchmarks let you estimate the individual contributors that public profiles hide. Confirmed nodes concentrate at the top of the house by design, so you need a way to reason about the middle and bottom you cannot fully observe.

The logic is simple. If you have M confirmed managers in a function and an adjusted function headcount of H, then the implied hidden individual contributors are roughly H minus M minus (M times average span). A documented average of 5.89 reports per manager at firms of 1,000-plus employees turns "we can only see a fraction of this team" into a defensible estimate rather than a shrug. Use the benchmark that fits the company's size and shape.

| Metric | Value | Source |
|---|---|---|
| Avg direct reports per manager (2022) | 5.2 | lattice.com |
| Avg reports, 1,000-plus employees | 5.89 | pave.com |
| Avg team size (2025) | 12.1 | gallup.com |
| Healthy management ratio | 12-18% | hyring.com |
| Best-practice layer count | 5-7 | hyring.com |

These benchmarks also work as sanity checks on the whole chart. Well-designed organizations run management ratios of 12 to 18 percent, while poorly designed ones run 25 to 35 percent. Best practice is 5 to 7 management layers, and more than 8 signals over-management. If your reconstruction implies a 30 percent management ratio or nine layers, either the target is genuinely top-heavy or, more likely, you have miscounted managers, missed individual contributors, or let title inflation distort span. Investigate before you publish.

> Confirmed nodes should come from the top and inferred ones dominate the middle, by design, not by failure.

## How this goes wrong: failure modes and false positives

The most valuable part of this method is knowing where it lies to you. Each failure mode below has a tell and a check. Run the checks before you call the job done, because most of these produce a chart that looks confident and is quietly wrong.

- **Stale-profile inflation.** A function looks overstaffed because leavers never updated their profiles, so the count overstates true active headcount. Check: cross-reference start and end dates and current-employer flags before counting.
- **Contractor bleed.** Profiles do not distinguish employees from contractors, who inflate the total even though the company does not count them. Check: flag agency and consultancy patterns and treat them as a separate band.
- **Subsidiary double-count.** When profiles spread across brand and geo pages, numbers double-count or undercount against one legal entity. Check: reconcile all brand and geo pages to a single legal entity.
- **Press-release fiction.** A reporting line published in a press release may never have been operationally true, producing a "confirmed" node that was announced but never staffed. Check: require a live profile at that node before confirming it.
- **Title inflation distorts span.** A director at one firm equals a senior manager at another. Check: score span and actual reports, not the literal word "Director."
- **Confirmation-bias echo.** Grading credibility by consistency with your prior belief inflates confidence. Check: require the corroborating source to be genuinely independent of the first.
- **Noise mistaken for trend.** A growth rate computed over three days is mostly noise multiplied by ten. Check: enforce a minimum 7-day observation window before reporting any headcount delta.
- **Small-function taxonomy collapse.** Too many buckets, beyond 15, means overlapping definitions and mapping errors. Check: keep 8 to 12 functions with written boundary definitions.

> **Note:** Two platform data caveats
>
> Headcount figures are often revised about twice a year and applied retroactively, so a number can change under you without any real hiring. And a growth rate computed over fewer than 7 days is flagged unreliable at source. Date-stamp every count and never trend on sub-week windows.

## Keeping the map current

A reconstructed org chart is a leading indicator with a shelf life, not a permanent verdict. Set refresh triggers when you build it, because the structure will move whether or not you are watching.

Plan for roughly annual decay. Companies revamp their organizations on average every three years, 82 percent of executives report having experienced a redesign, and 70 percent say the most recent one occurred within the past two years. A reader poll echoes the pace: about 42 percent reorganize every couple of years, 19 percent at least once a year, and 10 percent multiple times a year. Because of that churn, a node's confidence should decay with its age. Two triggers are worth watching directly: executive-hire announcements, which reshuffle the top of the house, and headcount deltas, especially a headcount figure going negative on contraction or a company still claiming a stale size band while the live count runs far higher.

Remember that the map pairs with, but does not replace, hiring and headcount evidence. A new function can be defunded a quarter later, and a VP can hire seven reports and still lose the budget. Treat the chart as one input to a market read, refreshed on triggers rather than on a fixed calendar.

#### Before you call the reconstruction done

- [ ] Every node and every count carries an Admiralty two-part grade, with no untagged cells.
- [ ] Confirmed nodes each trace to an explicit statement: a stated line, a press release, or a verified directory node.
- [ ] Each inferred line has been checked for a second, independent corroborating source before any promotion.
- [ ] The function taxonomy has 8 to 12 buckets with written boundary definitions and a reviewed "Other" bucket.
- [ ] Every count records raw count, adjusted count, and the sector multiplier used.
- [ ] Start and end dates and current-employer flags were checked against stale-profile and contractor bleed.
- [ ] All brand and geo pages are reconciled to one legal entity.
- [ ] A snapshot date is stamped and a refresh trigger plus re-run date are written down.

## Frequently asked questions

### How do I figure out who reports to whom from public profiles alone?

Take a job posting's stated reporting title and team name, open the company's People view, and filter to the title one or two levels above the role. Then compare those names against manager mentions from recently hired employees, whose first-day posts and profile 'about' sections often name their boss. The overlap is your likely parent, but log it as inferred until a second independent source confirms it.

### Can I trust a headcount estimate built from LinkedIn profile counts?

Only with a correction and a confidence tag. One analysis found just 10 to 20 percent of profiles reflect current employment, and vendors put employee-count accuracy at 70 to 90 percent depending on size and industry. Coverage is reasonably reliable for software and financial services but under- or over-counts in agriculture, healthcare, manufacturing, and professional services. Apply a sector scale factor and never publish a raw count untagged.

### What is the difference between a confirmed and an inferred reporting line?

A line is confirmed only with an explicit statement: a posting's 'you will report to' clause, a press release, or a verified org-chart node. Everything triangulated from title level plus team plus span is inferred. Promote inferred to confirmed only when a second source, independent of the first, corroborates the same line. Keep the two states visible in the final chart.

### How many functions should I split headcount into?

Keep it to 8 to 12 primary business functions. Beyond 15 categories you usually get overlapping definitions that cause mapping errors and double-counting. Anchor to a standard taxonomy such as SOC 2018, O*NET, or a custom GTM framework of Sales, Marketing, Engineering, Finance, HR, Operations, Legal, and IT, and write boundary definitions for borderline cases like Product versus Engineering.

### How long does a reconstructed org chart stay accurate?

Plan for roughly annual decay. Companies revamp their organizations on average every three years, and 82 percent of executives report a redesign, 70 percent within the past two years. Set refresh triggers on executive-hire announcements and headcount deltas rather than a fixed calendar. Note that platform headcount figures are often revised about twice a year and applied retroactively.

### Why do span-of-control benchmarks matter for this work?

They let you back-fill layers you cannot see directly. If you have confirmed managers and an adjusted function headcount, a documented ratio of 5.89 reports per manager at firms of 1,000-plus employees makes the missing individual contributors estimable rather than a pure guess. Use span to sanity-check whether a function's visible headcount is plausible given its confirmed managers.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/competitor-org-chart-reconstruction*