Reconciling a Headline Talent-Pool Count to a Defensible Number

You pulled a talent-pool size from a tool, and now you need the real addressable number before it goes in a brief. This guide is for strategy, research, and talent-intelligence analysts who have one inflated count and a stakeholder waiting. It carries a single worked example all the way down, with the real intermediate figures, the deductions in order, and the two wrong turns most analysts take before the number holds up.

Other guides treat pool-sizing as a forward playbook or completeness as a standard. This one runs backwards: one headline number, carried to a defensible figure, with a trail you can hand across the desk. Follow along on your own case as you read.

Why a headline pool count is almost never the real number

A headline pool count is a starting estimate, not a census, and the gap between it and a defensible figure is usually several multiples. The number inflates for reasons that are documented and predictable, which is exactly why you can deduct them in order.

Three things conspire. First, the count above a threshold is an approximation: in the recruiter surface, exact counts appear only below 1,000 results, and above that you see approximate counts. Second, the query itself is loose: a search for a term scans the whole profile, including schools and recommendations, so it pulls in students, blog writers, and managers. Third, the population underneath is decaying: job titles change 25-35% per year, so some share of the "current" matches are already wrong.

None of this means the tool is broken. It means the headline answers a different question than your brief asks. The brief wants "how many people can I plausibly reach for this role." The tool answers "how many profiles mention these terms somewhere." Reconciliation is the work of turning the second into the first, deduction by deduction, with a source beside each drop.

The worked example: US Rust engineers

I will carry one case the whole way: software engineers in the United States who use Rust. In Refolk's index of professional profiles, there are 595 US software engineers with Rust. That is the defensible base I am working toward. The teardown below starts from a loose, inflated headline and walks down to a number in that neighbourhood, showing what each deduction removes.

Two comparisons anchor how sensitive these numbers are to the question you ask. Same role, different market: the US Rust pool is 6.4x the German one. Same market, different skill: the US Go pool is 2.3x the US Rust pool. Neither multiple is a rounding error. They tell you that "size the Rust pool" and "size the Go pool" are not the same brief, and that a country swap changes the answer by more than any staleness haircut will.

Counts are from Refolk's index; the multiple is derived from them.

Counts are from Refolk's index; the multiple is derived from them.

Read these two tables together before you touch a deduction. If your headline came from a tool and reads in the tens of thousands for "Rust engineers in the US," the distance between that and 595 is the work. Most of it is title definition, not data quality.

The deduction sequence, from headline to defensible

The frame is standard market sizing, translated into talent terms: the total market is all developers, the serviceable market is those who meet your skills, experience, location, and seniority, and the obtainable market is those also reachable now. Each cut below is a known, documented filter, and the order matters because some cuts remove the same people if you are not careful.

Here are the deduction factors you will apply, each with what it does and where it comes from. Treat the percentages as documented rates, not as the exact answer for your pool; your spot-checks calibrate them.

The title cut usually dwarfs the rest. In a documented keyword case, switching from the exact phrase "computer games" to the synonym set games OR gaming OR game moved results from 150 to 494, roughly 3x, before any staleness or de-dupe. That is the mechanism to respect: whole-profile keyword scans both over-include noise and under-include people who phrase their title differently. Fix the question before you haircut the answer.

Staleness compounds, which trips up analysts who apply a single flat 30%. At 30% annual title decay, data two years old is about 49% valid and three years old about 34%. If the underlying member records are two years stale on average, a one-year haircut understates the problem badly.

Fix the question before you haircut the answer; the title definition swings the count more than the data ever will.

Run it: the step-by-step reconciliation

Work the deductions in this order, logging a count and a source at every step. The goal is not a single perfect number but a trail where every drop has a reason a stakeholder can see.

A note on step two, the title cut: this is where most of your inflation disappears, and it is also where a tool that only matches keywords will fight you. If you can ask for the role in plain language and get title-scoped, de-noised results back, you skip the Boolean tuning entirely.

That is the hard part done in one query. When the role is specified in plain English, Refolk applies the title scoping and the intern, student, and bootcamp exclusions for you, so the number you carry into the staleness and active-share cuts is already the clean base rather than the raw headline.

Where this goes wrong: the failure modes

Most reconciliations fail at one of seven predictable points. Each has a false positive it produces and a cheap check that catches it. This is the section to keep open while you work, because a wrong deduction is harder to spot than a wrong headline.

• Trusting the headline as exact. Above 1,000 the count is an estimate, not a census. The false positive is quoting a rounded approximate number as precise. Check: confirm the count is under the exact-count threshold, or label it estimated.
• Over-excluding with NOT. Stacking NOT intern, junior, student also drops seniors who once held or merely mentioned those terms. Check: compare counts with and without each NOT term, one at a time.
• Loose keyword as title. Whole-profile scans count people who only mention a term, the "data scientist returns students and blog writers" problem. Check: scope to title fields and spot-check 20 profiles by eye.
• Double-counting the coverage gap. Grossing up for the 30% off-platform and then adding a separate developer-account total counts the same engineers twice. Check: define one canonical universe before adding anything back.
• Applying staleness and active-share to the same drop. Stale-title removal and active-versus-total are different cuts; conflating them under-counts. Check: label each deduction by exactly what population it removes.
• Assuming one surface is truth. The same query differs across a product's own surfaces by tens of millions. Check: name the surface beside every number and never mix surfaces in one trail.
• Treating passive as unreachable. The 30% active figure means 30% are actively seeking, not 30% interested in your role. Check: state whether the final number is addressable, reachable, or interested.

Two of these are the wrong turns I see most. The first is the title-as-keyword mistake at the top of the funnel: analysts haircut aggressively for staleness and coverage while leaving a bloated keyword match in place, so they subtract 50% from a number that was 3x too big to begin with. The second is double-counting the coverage gap: grossing up the platform figure by 30% for off-platform engineers, then adding a developer-account total on top, which quietly inflates the market by the exact population you just tried to add back.

Addressable versus reachable: two numbers, not one

A brief usually needs two figures, not one: the addressable pool, meaning everyone who fits, and the reachable-now pool, meaning those you can realistically engage today. Reporting only the larger one oversells the opportunity; reporting only the smaller one hides the market.

The reachable cut is where numbers collapse, because the filters are independent and multiplicative. Start with a platform that misses about 30% of engineers. Of those present, about 30% are active and only 4.1% are actively looking. Stack those and the reachable-now figure can fall under a tenth of the headline. That is not a flaw in the method; it is the honest shape of a talent market.

Be precise about what the active share means. The roughly 30% active figure is misleading at face value: it means 30% are actively seeking a move, not 30% interested in your particular role. So the reachable-now number is an upper bound on engagement, not a demand forecast. Say so in the brief, in one sentence, next to the figure.

For the Rust example, the defensible addressable base is 595 US software engineers in Refolk's index. If the stakeholder asks "how many can we approach this quarter," you apply the active share to that base and report a far smaller reachable figure, clearly labelled, with the deduction shown. The two numbers belong side by side, never collapsed into one.

Verify before you ship: the reconciliation checklist

Run this before the number leaves your desk. Every item is a thing a stakeholder could challenge, so clearing it means the question is already answered when asked.

The deliverable is that table. One row per deduction, four columns, every drop sourced. A stakeholder should be able to read down it and reconstruct your logic without a meeting.

| Step | Count after | % removed | Source / note |
|---|---|---|---|
| Raw headline (surface named) | 0000 | - | tool + surface; estimated above 1,000 |
| Title-scoped match | 0000 | 00% | title fields + synonyms; spot-checked 20 |
| Adjacent populations removed | 0000 | 00% | NOT intern/student/bootcamp; tested each |
| Staleness haircut | 0000 | 00% | titles 25-35%/yr, compounded by data age |
| De-dupe / phantom accounts | 0000 | 00% | duplicate + dormant removal |
| Coverage gross-up (optional) | 0000 | +00% | one source only; universe defined |
| Reachable-now (active share) | 0000 | 00% | ~30% active; label as reachable |

Keeping the number current

A reconciled pool count is a snapshot, not a constant, so date it and set a re-check trigger rather than treating it as settled. The underlying population decays on a schedule you can plan around, and the surfaces you pulled from can shift between runs.

Re-run the reconciliation when any of three things changes: the brief's skill or geography (because the base moves before any deduction, as the 2.3x and 6.4x multiples show), the staleness clock (titles change 25-35% per year, so a figure more than a few quarters old deserves a fresh pull), or the surface (if the tool updates, re-capture rather than trust the old headline). Refresh cadence for pool reports is not published as a fixed interval, so set your own and write it on the brief.

When you re-run, keep the old deduction table beside the new one. If the final number moved, you want to see which row moved it: a bigger base, a steeper staleness cut, or a different active share. That side-by-side is what turns a one-off estimate into a figure you can defend quarter after quarter, and it is the difference between a number someone trusts and a number someone has to redo.