Estimating a Competitor's Attrition Rate From Public Profiles

You need to know how fast a rival is losing people - overall and by function - and you do not have a talent-intelligence subscription. This playbook is for strategy, research, and talent-intelligence analysts sizing a competitor from the outside. It gives you an end-to-end method to snapshot headcount, count observed departures over a fixed window, compute the rate by function and seniority, correct for the biases that inflate or deflate it, and land a defensible verdict against a stated benchmark.

The math here is not the hard part. The hard part is deciding who counts as a leaver, correcting for the lag that makes every public estimate run low, and refusing to compare a number to the wrong benchmark. Get those right and you can produce a figure you would defend in a board deck.

Why an outside-in attrition estimate is even possible

You can reconstruct a competitor's attrition rate because the standard formula only needs two numbers you can see from the outside: departures and headcount. The internal HR formula assumes you already hold the roster. The outside-in version rebuilds the roster from public profiles.

The formula every serious source agrees on is the same: attrition rate equals the number of leavers during a period divided by the average headcount for that period, times 100, where average headcount is normally (employees at start plus employees at end) divided by 2. LinkedIn Talent Insights uses exactly this - departures in the past 12 months over average employees across that period - and it registers a departure when a professional provides an end date for a position, excluding internal job changes within the same company.

That last clause matters. A departure is an end date attached to a person, not a role string that changed. Everything you build from public profiles is an approximation of that one event: a person who was at the company at date A and is not at date B.

The catch is that a public snapshot is never complete and never perfectly current. So this playbook is not "run the formula." It is "run the formula, then spend most of your time on the corrections that keep it honest."

What separates a defensible estimate from a guess

A defensible estimate is one where you wrote the inclusion rules down before you counted, corrected for update lag, and compared like-for-like against a named benchmark. A guess skips all three.

The formula is trivial; the numerator definition is the entire game. Two analysts can compute the same company at 14% and 31% purely from different inclusion rules - whether they count contractors, whether they count internal transfers, where they draw the window. There is no universal standard, so the only thing that matters is choosing a convention, writing it down, and applying it identically at both snapshots. A change in method is indistinguishable from a change in performance, and that is exactly how an attrition read gets quietly wrong.

Three properties make an estimate hold up:

• A frozen convention. The same exclusion rules, applied at both snapshots, so any change in the rate is a change in the company and not in your method.
• A lag-corrected window. A counting window that ends weeks before your snapshot, so late profile updates have had time to post.
• A matched benchmark. A comparison against total-separation data if you counted all departures, or quit data only if you isolated voluntary ones.

The seven-step procedure

The procedure is a snapshot-and-count applied to public profiles, then cleaned of the biases that make raw counts lie. It runs about 11 to 19 analyst-hours end to end for one company, most of it in scoping and involuntary-event tagging rather than the math.

One note on the denominator. Sources agree on the formula but differ on the average: most use the start-end average, while some average across pay periods (add each period's headcount, divide by count), which is more accurate for volatile headcount. Use the start-end average as your default and switch to pay-period averaging only when the company is visibly shedding or adding staff fast.

Building the headcount base before you build the rate

Size the denominator per market and per segment first, because the same absolute departure count means a wildly different rate depending on how many people are in the base. A rate computed on a base you have not sized is a coin flip dressed as a number.

The point is easiest to see across borders. In Refolk's index of professional profiles, there are 352,076 people with the title Software Engineer in the United States and 22,621 in Germany - a 15.6x difference in base.

Profiles from Refolk's index; US multiple derived (352,076 / 22,621).

If you observe the same absolute number of departures from a US team and a German team, the German rate will be roughly 15 times higher, entirely because the base is smaller. Never compare rates across markets until you have sized each denominator. This is also why a raw departure count is meaningless as a headline: it only becomes a rate when divided by a base you can defend.

Reconstructing a full current-employee roster by hand is the slowest part of this job. Describing the company, function, and geography in plain English and getting a deduplicated list back is where Refolk removes the most friction - you get the headcount base without stitching together dozens of scraped pages.

Correcting the biases that make the raw count lie

The two biases that move an attrition estimate most are profile-update lag, which always deflates it, and involuntary events, which get miscoded as voluntary attrition. Both have documented corrections. Neither is optional.

Update lag runs one direction, so your estimate is always a floor

LinkedIn concedes its own turnover estimates may run below actual because of the gap between when someone leaves and when they update their profile. The behaviour is predictable: guides advise leavers to change the current role the day after the last day, then post the public job-change announcement two to three weeks into the new role, and some update in deliberate stages. The effect is that the most recent weeks of any window are systematically undercounted.

Because the bias only points one way, every uncorrected public estimate is a floor, never a ceiling. The correction is to end your counting window 4 to 8 weeks before your snapshot date, so late updates have had time to post. Then re-pull six weeks later and confirm the count for the window has stopped moving.

Involuntary exits masquerade as voluntary attrition

A public profile shows a departure, not its reason. The one documented external signal for involuntary cuts is the WARN Act, which requires employers with 100 or more full-time employees to give at least 60 days notice before a mass layoff, generally defined as 50 or more at a single site. Cross-reference departure clusters against WARN filings and dated news, and tag each.

But the visibility floor is real. Trackers miss companies below the 100-employee threshold, cuts under the size trigger, and quiet attrition where roles are simply not backfilled. Rolling layoffs of fewer than 50 people at a time made up 51% of 2025 WARN notices, which means half of documented layoff activity now sits at the edge of what the notices even capture. Acquisitions are easier: they appear as synchronized company-name changes across many profiles on a single date.

Public WARN-based datasets are large - one holds 85,000-plus filings covering 9.03 million workers, another lists 91,635 filings covering 10.5 million. Use them for cross-referencing clusters, not as a complete census of involuntary exits.

Some biases have no single published correction: undated role changes, contractor misclassification, and survivorship (profiles that go dark entirely). Do not pretend otherwise. Handle them with exclusion rules written into your convention in advance, and state in your output that these corrections are not publicly established.

Where the estimate breaks: failure modes and false positives

Most bad attrition reads come from a small set of repeatable mistakes. Each has a tell and a check. This section is the part worth keeping open while you work.

Mixing separation types against the wrong benchmark. A public-profile count captures every departure, voluntary and involuntary. Compare it to a quits benchmark and you inflate the verdict. If you track every separation, compare against total-separation data; if you isolated resignations, compare against quit data. Mixing the two is the single most common reason a benchmark comparison misleads.

Thin-segment noise. Precision is driven by the number of observed events, and the proportion sample-size rule sets the floor: a margin of error of plus or minus 10% needs about 100 events, plus or minus 5% needs about 400, and plus or minus 3% needs roughly 1,000. Segment cuts collapse fastest exactly where the story is most interesting.

Profiles from Refolk's index; share derived (3,358 vs 6, a 560x gap).

In Refolk's index, US Data Engineers listing Rust number 6 against 3,358 listing Python. A "Rust team attrition" claim is statistically empty under the n=100 rule, while the Python cut is robust. One departure in a six-person function reads as roughly 17%, or infinity if the headcount hits zero. Pool thin segments or report the raw count and refuse to publish a percentage.

Internal transfers scored as exits. LinkedIn's own rule excludes internal moves. Naive scraping counts a division rename as a departure. Match by person across the two snapshots, not by role string.

Denominator drift during layoffs. Dividing departures by a shrinking headcount inflates the rate, and using end-of-period rather than average headcount overstates it. Always use the (start plus end) average and show the denominator next to the rate.

Naive annualization. Multiplying a monthly or quarterly figure by twelve overstates true annual turnover, because one seat can turn over more than once a year. If you must annualize a partial-period figure, use compound annualization rather than period times twelve.

Benchmarking and the verdict

Reach a verdict by comparing your like-for-like rate to a named benchmark and stating the window. The verdict is a single word - elevated, normal, or low - with the benchmark it stands on written beside it.

The critical discipline is matching numerator to benchmark. Public counts capture all departures, so the natural home is total-separation data. BLS JOLTS computes the separations rate as separations over employment, times 100, and reports about 3.3% monthly, which annualizes to roughly 40%. Only compare against a quits benchmark once you have stripped involuntary exits.

Compare like-for-like: separations against total data, quits against voluntary data.

Two annualization traps hide in this table. JOLTS reports monthly, so multiplying the 3.3% monthly separations rate by twelve to reach 40% slightly overstates true annual turnover, because a seat can turn over more than once a year. And the quit rate has held between 1.9% and 2.0% monthly, which is voluntary only - do not benchmark a raw all-departure count against it.

[Company] attrition, trailing 12 months ending [window-end date]:
Overall: [X]% (all departures, [N] observed / [H] avg headcount, denominator = (A+B)/2).
By function: Engineering [X]%, Sales [X]%, G&A [X]% (segments under [threshold] shown as raw counts only).
Voluntary/involuntary split: [X]% voluntary after tagging [K] clusters against WARN + news.
Verdict: [Elevated / Normal / Low] vs [benchmark name] of [rate], like-for-like on [total separations / quits].
Known limits: last 4-8 weeks excluded for update lag; sub-50 layoffs may be undercounted.

Compensation context, when you need it: SHRM puts direct cost per non-executive hire at $5,475, and Gallup estimates replacement cost at 0.5 to 2x salary. Those figures turn an attrition rate into a cost story, but only once the rate itself is defensible.

Keeping the estimate honest and current

Before you call the job done, run the checklist. An attrition read is a dated artifact: it is true for one window, computed under one convention, and it decays as profiles update.

To keep the read current, re-run the identical query on a fixed cadence and diff it against your stored rosters. Because the whole method rests on a frozen convention, the only edits you should ever make to that convention are documented and dated, so a future reader can tell a method change from a performance change. When the underlying benchmarks matter to your verdict, re-check the JOLTS separations and quits rates and the current LinkedIn or Mercer figures rather than trusting a value you cached, since those move over time. The mechanism stays fixed; the numbers you feed it do not.