The Transfer-Distance Score: Ranking Adjacent Talent Pools

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 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.

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.

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.

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.

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.

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 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.

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

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.

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.

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.

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.

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.

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.

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.

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.