# The Transfer-Distance Score: Ranking Adjacent Talent Pools

*You will score each adjacent talent pool for a scarce role as source-now, source-with-a-filter, or no-go, and defend the ranking to a hiring manager.*

- Canonical URL: https://www.refolk.ai/guides/transfer-distance-score-adjacent-pools
- Pillar: Market and talent intelligence
- Format: Framework
- Published: 2026-09-01
- Last reviewed: 2026-09-01
- Reading time: 17 min

You have a role you cannot fill with exact-match candidates, and you need to decide which adjacent roles, industries, or companies to source from, and in what order. This guide is for strategy and research teams, talent-intelligence analysts, and sourcers who have to defend that decision to a hiring manager. It gives you a directional, evidence-weighted score - the Transfer-Distance Score - that turns "let's try DevOps people" into a ranked, labelled list of pools: source-now, source-with-a-filter, or no-go.

Every public guide on skill adjacency is about internal employee reskilling and learning-and-development pathways. Those assume you already employ the people. This one scores external pools for a sourcer deciding where to look, using overlap, direction of transfer, and public evidence rather than a hunch.

## What the Transfer-Distance Score measures

The Transfer-Distance Score rates how safe and how productive it is to source a scarce role from a given adjacent talent pool. It is a composite of three things: how much the pool's skills overlap the role, which direction the move runs (up into a harder job or down into an easier one), and how much public evidence proves the transferable skill was actually exercised. The output is a label a hiring manager can act on and argue with.

Overlap alone is the trap. Two pools can share the same skill footprint and still behave completely differently once a candidate moves. That is why direction and evidence are load-bearing, not decoration. The score exists to stop you from ranking pools by similarity and then being surprised when the highest-overlap hire quits inside a year.

#### The three layers of a Transfer-Distance Score

1. **Overlap** - How much the pool's skills match the role, scored 0 to 1
2. **Direction** - Whether the move is upskilling or downskilling, from an asymmetric measure
3. **Evidence** - Whether the transferable skill shows up in public work, not just a title

*Overlap tells you who could do the job; direction and evidence tell you whether they will stay and whether they really can.*

The stakes justify the effort. Robert Half reports that 93% of managers struggle to find the talent they need, and nearly 50% of new hires are terminated or quit within their first 18 months. A scoring model that shaves even a fraction off wrong-pool bets pays for itself, because the counterfactual is close to a coin-flip.

**~50% - New hires terminated or quit within 18 months**

The mis-hire base rate is why picking the wrong pool is expensive, and why a defensible score beats a hunch.

## Why overlap alone gives you a false read

Overlap answers "who could do this job," and nothing more. It is necessary and badly insufficient, because the highest-overlap pool can still be a no-go once you mark the direction of the move.

There are several documented ways to quantify skill overlap between two occupations, and they disagree in ways that matter. O*NET-based mapping binarizes continuous importance ratings into a required/not-required matrix - commonly treating a skill as required when its rating exceeds 3 on a 1-to-5 scale - and then builds an occupation-skill adjacency matrix. Canada's OaSIS Skills Match does it differently: a weighted Euclidean distance across descriptor ratings, where a smaller distance means greater similarity, run over 900 occupations. Job-ad approaches weight skills by how distinctive they are to a job before computing pairwise similarity.

The choice is not cosmetic. Binarizing at a threshold throws away the difference between a skill that is barely required and one that is central. Keeping continuous ratings preserves that but makes your scores harder to explain to a hiring manager. Pick one, apply it to every pool, and write down which you used, because a mixed method produces scores you cannot compare.

> **Rule:** One overlap method, applied to every pool
>
> Decide whether you binarize skills at a threshold or keep continuous ratings before you score anything, and use the same choice for all pools. Mixed methods produce scores that cannot be ranked against each other.

The overlap threshold question comes up constantly: what number separates a near-adjacent pool from a stretch one? The popular "70/30" framing - who already has 70% of the skills, and what would it take to close the remaining 30% - is real, but it is documented for internal reskilling, not external pool scoring. No peer-reviewed source fixes 70% as a validated cut-line. It is a heuristic. Use it to structure the conversation, not to make the decision.

## Direction of transfer: the part overlap hides

Direction of transfer is whether the candidate is moving up into a more skill-demanding job or down into a less demanding one, and it predicts retention risk better than overlap does. This is the single most important addition to a naive similarity score.

The evidence comes from the Nedelkoska, Neffke and Wiederhold study of job displacement. They built directed occupational skill profiles - task, education, and training content for 263 occupations, from a survey of 20,000 German employees - and separated "skill shortage" (moving up into a more demanding job) from "skill redundancy" (downskilling). The finding is stark: moving to more skill-demanding jobs helps workers eventually return to their counterfactual earnings, while skill redundancy sets displaced workers on paths with permanently lower earnings. Across roughly 1.6 million displaced workers whose histories ran from 1975 to 2010, earnings losses ranged from 4% to 16.5% ten years after displacement.

Translate that to sourcing. A downskilling hire lands in a role beneath their peak, and lower earnings correlate with flight risk. A high-overlap pool can still be a no-go if the move is downward. The measure that makes this visible is directional by design: workers switching from occupation A to B experience a different skill mismatch than workers going the opposite way. Most off-the-shelf similarity measures are symmetric and cannot see it.

> A high-overlap pool can still be a no-go if the move runs downhill.

Does directionality actually improve predictions? A skills-based transition recommender that accounted for asymmetric difficulty reported 76% accuracy in predicting real occupational transitions. Symmetric distance alone cannot tell a hiring manager which direction is safe, which is exactly the judgement they are paying you to make.

#### Overlap against direction of transfer

Horizontal axis runs from Low overlap to High overlap. Vertical axis runs from Downskilling (redundancy) to Upskilling (shortage).

| Quadrant | What it means |
| --- | --- |
| Stretch, upward | Source-with-a-filter; overlap is thin but the direction is safe |
| Best pool | Source-now; strong match and an upward, retentive move |
| No-go | Skip; weak match and a downward move that predicts flight |
| Overlap trap | Downgrade despite the match; downward move drives attrition |

*Direction splits high-overlap pools into a clear source-now and a clear no-go.*

## Prove the skill was used, not just claimed

Public evidence is what turns a claimed skill into a scored one, and it is also the weakest-supported part of this method. Be honest about that with anyone who reads your ranking.

There is no validated public taxonomy of proof-signals - repository commits, shipped projects, patents - tied to transfer scoring. This is a genuine gap, not something I am hiding. The best documented guidance is directional: validate against project history and manager input rather than trusting self-assessment as the sole source, evaluate actual skill signals rather than relying only on job-title history, and probe with situational questions asking candidates to describe scenarios where they applied a skill outside their main role.

For a sourcer working from public data, that means ranking evidence by how hard it is to fake. A title is the weakest signal. Self-reported skills sit just above it. Public work - a repository with observability tooling activity, a shipped project, a patent - is the strongest, because someone had to do the thing to leave the trace. The point of the evidence layer is to move a pool up when the work is visible and down when all you have is a job title.

> **Watch out:** A self-reported skill is not proof
>
> A claimed skill with no work behind it is the most common false positive in adjacency scoring. Validate with project history, shipped work, and manager or reference input before you let a claim raise a pool's score.

This is where the search itself becomes the bottleneck. Finding backend engineers who actually held on-call and incident-response responsibility, or DevOps engineers whose public work shows Kubernetes rather than a keyword on a profile, is slow to do by hand across GitHub, LinkedIn, and the open web. Describing the exercised skill in plain language and getting back people whose public work supports it is the difference between an evidence-weighted score and a title-matched guess.

I ran this search: `Find US DevOps engineers who use Kubernetes and Terraform but have never held an SRE title.` - [see the full result list](https://www.refolk.ai/s/jpr61abrhf).

*Returns an adjacent pool defined by exercised tools rather than title, which is exactly the source-with-a-filter shortlist this method calls for.*

## Size the pools with real counts

A pool's overlap and direction mean nothing until you attach a headcount, and the count has to be a reachable one, not a market size. This is where Refolk's index figures anchor the whole method.

Take Site Reliability Engineer as the worked example. In [Refolk](/)'s index, 6,512 profiles hold that exact title in the United States. The obvious adjacent pool is DevOps engineers with Kubernetes, and there are 3,604 of those in the US - equal to about 55% of the SRE exact-match pool. Scoring one adjacent pool expands your reachable supply by more than half without lowering the skill bar.

| Pool | Definition | Pool size | Size vs exact-match SRE |
|---|---|---|---|
| Exact-match | Title = Site Reliability Engineer | 6,512 | 100% |
| Adjacent | Title = DevOps Engineer + Kubernetes | 3,604 | 55% |
| Combined reach | Exact + adjacent | 10,116 | +55% candidates |

Pool sizes come from Refolk's index; the percentages and combined reach are derived from those counts.

Geography can flip the entire strategy. The same exact-match SRE pool is 11.1 times thinner in Germany than in the US - 585 profiles against 6,512. In a market that thin, adjacency is not a nice-to-have. It is the only route to enough candidates, and the top employers shift too: Google, JPMorganChase, and Apple lead in the US, while in Germany the leaders are Google, Apple, and Helsing.

| Role (exact title) | Country | Pool size | US-to-country ratio |
|---|---|---|---|
| Site Reliability Engineer | United States | 6,512 | 1.0x |
| Site Reliability Engineer | Germany | 585 | 11.1x |

Pool sizes are from Refolk's index; the ratio is derived from the two counts.

**11.1x - How much thinner the exact-match SRE pool is in Germany vs the US**

585 profiles against 6,512 in Refolk's index - the reason adjacency becomes mandatory in thin markets.

One hard warning on these numbers: a national count is a market size, not a sourcing funnel. The 6,512 US SREs include passive and unreachable candidates. Discount by reachability before you label a pool source-now, or you will promise a hiring manager a funnel you cannot deliver.

## Score a pool: the procedure

Run these eight steps in order for one role. The output is a labelled, ranked list of pools with a ramp estimate attached to each. Steps 1 through 4 are analyst work, step 5 is sourcing, and steps 6 through 8 close the loop with the hiring manager.

#### Scoring adjacent pools for one scarce role

1. **Define the role as skills, not a title** - Convert the job description into a ranked list of capabilities and agree it with the hiring manager, whose input makes the profile significantly more accurate. Done when you have a ranked capability list, not a resume checklist.
2. **Enumerate candidate adjacent pools** - List every adjacent role, industry, and company that plausibly holds the skills, with a name and rough headcount for each. Done when each pool is named and roughly sized.
3. **Score overlap for each pool** - Apply one method - binarized O*NET-style match or continuous OaSIS-style similarity - to give every pool a 0 to 1 overlap score. Done when every pool carries an overlap score from the same method.
4. **Assign direction of transfer** - Mark each move as upskilling or downskilling using a directed, asymmetric measure, and flag downward moves as higher retention risk. Done when direction is labelled and redundancy-heavy pools are flagged.
5. **Weight by public evidence** - Confirm the transferable skill was exercised through project history and public work, then nudge each score up or down by evidence quality. Done when each score is annotated with the evidence behind it.
6. **Size each pool with real counts** - Attach a headcount and discount it by reachability, because a national count is a market size, not a funnel. Done when source-now pools are ranked by reachable size.
7. **Classify each pool** - Label every pool source-now, source-with-a-filter, or no-go, write one line of rationale, and get the hiring manager to sign off. Done when every pool has a label and a defensible reason.
8. **Estimate ramp cost per pool** - Apply a role-type ramp range as a bound and note the structured-onboarding discount, labelling any adjacent premium as unverified. Done when each pool carries a time-to-productivity range.

The three labels map cleanly to the matrix. Source-now is high overlap plus an upward or lateral move plus visible evidence. Source-with-a-filter is a good pool that needs one qualifier applied - the DevOps pool only counts when Kubernetes is present, for instance. No-go is a downward move, thin evidence, or an overlap so low the ramp cost outweighs the supply gain.

**One-line pool rationale for a hiring manager**

```
Pool: DevOps + Kubernetes (US) | Overlap: 0.7 | Direction: lateral/up | Evidence: public repos w/ K8s | Reachable size: ~3,604 (discount for passives) | Label: SOURCE-NOW | Because: near-exact-match skills, safe direction, 55% supply lift over exact-match alone.
```

*Fill one per pool. Keep it to a sentence so it survives being pasted into a decision doc.*

## Estimate the ramp cost of going adjacent

Ramp cost is the last input, and the honest answer is that no public benchmark compares adjacent-pool hires against exact-match hires directly. So use general role-type ranges as bounds, never as point estimates, and label the adjacent premium as unverified.

The available benchmarks are useful even without an adjacent-specific number. Gallup 2024 puts median time to full productivity at 8.2 months for mid-level professionals. AllenComm reports entry-level roles reaching productivity within about 30 days and technical or senior roles taking 60 to 90 days or more. Enterprise account executives are slower still, averaging 5.3 months to a first deal and 12 to 18 months to full quota per Bridge Group.

| Role type | Time to productivity | Source |
|---|---|---|
| Entry-level | ~30 days | AllenComm 2026 |
| Technical / senior | 60-90 days+ | AllenComm 2026 |
| Mid-level professional | 8.2 months median | Gallup 2024 |
| Enterprise sales AE (full quota) | 12-18 months | Bridge Group |

None of these is adjacent-specific; treat them as bounds for cost-of-adjacency modelling.

The lever that makes source-with-a-filter defensible is onboarding structure. Brandon Hall data cited alongside these benchmarks shows structured onboarding reduces time-to-productivity by 30% to 50% versus unstructured approaches. An adjacent hire paired with structured onboarding can plausibly close the ramp gap to an exact-match hire. You cannot prove the gap exists from public data, but you can show that the tool to close it is real and quantified. Present both honestly: the adjacent premium is unverified, and the discount that offsets it is well-documented.

#### From national count to a ramped adjacent hire

| Stage | Figure | Note |
| --- | --- | --- |
| US DevOps + Kubernetes profiles | 3,604 | Refolk index count, market size |
| Reachable after passive discount | fewer | Discount before labelling source-now |
| Evidence-confirmed transferable skill | fewer | Public work proves the skill |
| Ramped with structured onboarding | hires | 30-50% faster time-to-productivity |

*Each stage narrows the number, which is why a national count is never the funnel.*

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

Most bad rankings come from a handful of repeatable mistakes. Each one has a check that catches it. Work through these before you present a ranking, because a wrong pool that looks defensible is worse than an obvious gap.

- **Title-matching instead of skill-matching.** A DevOps engineer with no Kubernetes counted in the adjacent pool is a false positive. The US DevOps pool only qualifies as adjacent when Kubernetes is present. Filter on the exercised skill, not the title.
- **Ignoring direction of transfer.** A high overlap score can hide a downskilling move that predicts permanently lower earnings and flight risk. Label every move up or down before you score it.
- **Treating symmetric similarity as directional.** Most off-the-shelf measures are symmetric; the Nedelkoska approach is explicitly not. Confirm whether your metric row-normalizes, which makes it asymmetric, before trusting a direction read.
- **Self-reported skills as proof.** A claimed skill with no work behind it inflates a pool. Validate with project history, public work, and manager input rather than self-assessment.
- **Borrowing the 70/30 line as a hard cutoff.** It is an internal-reskilling heuristic, not a validated external threshold. State it as a heuristic and calibrate against your own hire outcomes.
- **Using a national pool count as a reachable pool.** The 6,512 US SREs is a market size; passive and unreachable candidates inflate it. Discount by reachability before labelling source-now.
- **Assuming ramp cost is uniform.** Adjacent hires plausibly ramp slower, but no benchmark proves the gap. Apply role-type ranges as bounds and label the adjacent premium unverified.
- **Geography blindness.** An 11.1x thinner exact-match pool in Germany means adjacency is not optional there. Re-run pool sizing per country before ranking.

> **Tip:** The two-question sanity check
>
> Before you present a ranking, ask two things of every source-now pool: does the direction run up or lateral, and is the count reachable rather than national? If either answer is no, the label is wrong.

## Verify before you hand over the ranking

Run this checklist before the ranking leaves your hands. It catches the failure modes above and forces you to state the method's limits out loud, which is what makes the score defensible rather than just tidy.

#### Before you deliver the pool ranking

- [ ] The role is defined as ranked skills, agreed with the hiring manager, not as a title.
- [ ] Every pool was scored with the same overlap method, binarized or continuous, stated in writing.
- [ ] Direction of transfer is labelled for each pool, and downward moves are flagged as higher risk.
- [ ] Each pool's score is annotated with the public evidence that raised or lowered it.
- [ ] Pool sizes are reachability-discounted, not raw national counts.
- [ ] Every pool carries a source-now, source-with-a-filter, or no-go label with a one-line rationale.
- [ ] Ramp ranges are stated as bounds, and any adjacent premium is labelled unverified.
- [ ] Pool sizing was re-run per country if the search spans more than one geography.

## Keeping the score current

The method is evergreen, but the inputs are not. Pool counts move as people change roles, and the adjacent-versus-exact-match ratio drifts with them, so re-pull the headcounts each time you open a new search rather than reusing last quarter's numbers. The 55% adjacent ratio and the 11.1x geography gap are snapshots of Refolk's index, not constants.

Two calibrations will make your next ranking better than this one. First, log the outcome of each pool you sourced from - who was hired, who ramped, who stayed past 18 months - and back-test your labels against it. That is how you turn the 70/30 heuristic into a threshold that fits your own roles. Second, watch the load-bearing gaps: there is still no validated proof-signal taxonomy and no adjacent-specific ramp benchmark. If a credible one appears, fold it in and drop the "unverified" caveat. Until then, the honest score is the one that names its own limits and still gives the hiring manager a ranked list they can act on.

## Frequently asked questions

### What overlap percentage makes a pool worth sourcing from?

There is no validated public cut-line for external sourcing. The popular 70/30 framing, asking who already has 70% of the skills and what it takes to close the last 30%, is documented for internal reskilling, not pool scoring. Treat any percentage as a heuristic and calibrate it against your own hire outcomes rather than importing it as a hard threshold.

### How do I tell an upskilling move from a downskilling one?

Use a directed measure rather than a symmetric distance. Upskilling (skill shortage) means the candidate is moving into a more demanding job; downskilling (skill redundancy) means the reverse. The Nedelkoska, Neffke and Wiederhold method builds asymmetric skill profiles from 263 occupations so that a move from occupation A to B scores differently than B to A. Downward moves correlate with permanently lower earnings and higher flight risk.

### Do adjacent-pool hires take longer to ramp than exact-match hires?

That specific comparison is not established publicly, so treat any adjacent premium as unverified. Use role-type ranges as bounds: mid-level professionals reach full productivity at a median of 8.2 months (Gallup 2024), technical or senior roles at 60 to 90 days or more. Structured onboarding cuts time-to-productivity by 30% to 50%, which can plausibly close the gap for an adjacent hire.

### What proves a transferable skill was actually used and not just claimed?

No validated public taxonomy of proof-signals exists tied to transfer scoring, so this is a known gap. The directional guidance is to validate against project history, shipped work, and manager input rather than self-assessment, and to probe with situational questions about scenarios where the candidate applied skills outside their main role. Public work such as repository activity or shipped projects is stronger evidence than a title.

### How is scoring external pools different from an internal mobility matrix?

Internal mobility matrices assume you already employ the people and can see their full skill history and performance. External pool scoring works from public evidence and market counts, cannot rely on internal records, and must discount raw pool sizes by reachability. It also has to weight direction of transfer for retention risk, because you cannot manage an external candidate's fit before they join.

---

*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/transfer-distance-score-adjacent-pools*