When to build a skills-based map
A skills-based map is not an always-on artifact. It's built for a specific decision — and the decision shapes the map. Run this guide when you hit one of these:
- You're hiring for a role that keeps failing. Three rounds of recs and you're still not getting offers out. Decomposing the role into skills almost always reveals you've been hiring for an impossible profile — a unicorn that doesn't exist in the market, or shouldn't.
- You're building build-vs-buy-vs-borrow strategy. Without a skills decomposition, the answer always defaults to "buy" (hire externally). The map exposes where "borrow" (reskill internally, contract, partner) is actually viable.
- You're standing up a new function or role family. Especially in fast-moving areas like AI inference, ML infrastructure, or photonic compute — where job titles haven't standardized but skill stacks have.
- You're planning internal mobility or a talent marketplace. Without a skills layer, internal mobility runs on title-matching, which produces narrow lateral moves. With a skills layer, it surfaces the adjacent moves that actually grow the workforce.
- You're doing M&A due diligence on the talent base. Acquiring a company is partly acquiring a skills portfolio. Mapping the target's skill base against your role architecture reveals integration risk and capability upside.
- You're investing in reskilling. A reskilling investment built around a declining skill wastes money. The skills map identifies which skills are on a sunrise trajectory and which are sunsetting.
What you need before starting
A skills map for a single role takes 8–15 hours done well. A role family takes 3–5x that. These inputs determine whether the analysis actually lands.
A realistic job description — not the aspirational one. The role as it would actually be staffed today, with current expectations of scope and impact.
The hiring manager or a senior IC who'll validate the skills decomposition. The map fails if the SME isn't engaged — usually 2-3 sessions of an hour each.
Why are you building this? Sourcing strategy? Internal mobility? Build-buy-borrow? Different framings produce different maps — and a generic "all uses" map is useful for none.
Lightcast, TalentNeuron, Draup, or LinkedIn Talent Insights for skills inventories and trajectory. O*NET for foundational US gov taxonomy if needed.
HRIS skills data, internal talent marketplace, or skills-tagged ATS. If none exists, flag the gap explicitly — you'll do the external half of the map and call out the internal half as Phase 2.
Pick a skill taxonomy: Draup's root → core → soft → tools, Lightcast's open library, or your own. The choice matters less than picking one and using it consistently.
The seven steps
The order matters. Most failed skills-map projects skip Step 1 (framing) and start with Step 2 (decomposition), which produces a taxonomy with no consumer. Step 3 (criticality) is the most-skipped step, and the reason most skills maps are unusable. Step 5 (internal mapping) is where the build-vs-buy-vs-borrow value actually lives.
Frame what the map is for — decision first, taxonomy second
A skills map without a decision frame becomes a taxonomy. Taxonomies are easy to build and rarely used. Pick the decision the map will serve before you start the decomposition.
- Sourcing strategy — finding non-obvious candidate pools via adjacent skills.
- Internal mobility — surfacing employees with the right skills for an open role even if titles don't match.
- Build-buy-borrow — deciding whether to hire, reskill, or contract per capability.
- Workforce planning — forecasting which skills will be in surplus or deficit at 12–36 months.
- Reskilling investment — choosing which L&D bets to make.
- EVP and role design — crafting a role that's actually hireable in the current market.
Semi/AI example A team trying to hire 6 "Senior AI Inference Engineers" with no progress in 4 months has two very different maps available. A sourcing-strategy map focuses on adjacent skills and unconventional source pools. A build-buy-borrow map asks whether you should reskill 3 internal GPU engineers and hire 3 externals. Same role, different maps. Pick which decision matters more before starting.
Decompose the role into a skills inventory
Break the role down into the actual skills required, structured hierarchically. Don't list 40 skills — list the 8-15 that matter, with levels. Use a consistent framework like Draup's root → core → soft → tools.
The fundamental capabilities the role depends on — the things you'd struggle to teach in under a year. Often domain knowledge or deep technical foundations.
Role-specific skills built on the root layer. The "this is what you do day-to-day" skills. Teachable in 3-9 months with the right foundations.
Cross-cutting capabilities that determine whether the technical work translates into actual delivery. Often underweighted in skills maps but heavily weighted in offer decisions.
The specific tools and platforms. Often the most volatile layer — what was state-of-the-art 18 months ago may already be on the way out.
Why levels matter "Python" is not a skill — "Python at intermediate level for backend services" is. "CUDA" is not a skill — "CUDA at advanced level for production inference kernels at scale" is. Without levels, the map produces over-qualified pool sizes and under-qualified candidates.
Categorize each skill by criticality and trajectory
This is the most-skipped step and the reason most skills maps are unusable. If every skill is equally important, no skill is. Tag each skill on two axes: criticality (foundational, differentiating) and trajectory (emerging, declining).
Table stakes
Abundant in the market. Non-negotiable but not a hiring constraint. Don't over-spec these — they're available.
Rare and decisive
The skills that actually constrain hiring. The 2-4 that are scarce in the market and central to the role.
Sunrise trajectory
Growing in importance. Worth a premium and worth investing in for reskilling. Often where you find non-traditional candidates.
Sunset trajectory
Fading from relevance. Don't over-invest in hiring for or reskilling toward. Tag for retirement from the spec.
- Is this foundational (broadly available) or differentiating (scarce and role-defining)?
- Is this emerging (growing fast in 12-24 mo data), steady, or declining (being supplanted)?
- What's the realistic acquisition path — hire, reskill from adjacent, contract, or partner?
Semi/AI example In a Senior AI Inference Engineer role: CUDA kernel writing is differentiating but steady (it's hard but stable). MLIR / Triton is differentiating and emerging (growing fast, premium pricing). XLA expertise is differentiating but declining (partially supplanted). C++ is foundational. Most "skills map" outputs treat all four equally — which produces a hiring spec optimized for a market that doesn't exist.
For each differentiating and emerging skill, map where the supply actually lives. This step is what turns the skill list into a sourcing strategy.
- Total professionals with the skill at level — from Lightcast, TalentNeuron, LinkedIn TI skills inventories.
- Top 10 employers by headcount in this skill — gives you the realistic sourcing target list.
- Top geographic concentrations — where the skill physically lives (links to Step 3 geo light module).
- University and certification programs producing the skill — leading indicator for early-career and mid-career sources.
- Adjacent communities — open-source repos (GitHub stars/contributors for technical), conferences, professional associations, certification populations.
- Growth trajectory of supply — is the skill being produced faster or slower than demand?
Semi/AI example Mapping external supply for "Triton kernel programming" reveals the supply is dramatically concentrated: ~85% sit at fewer than 12 companies, the GitHub community is small and identifiable (contributors are findable by name), and university coverage is essentially zero. That's a very different sourcing strategy than "CUDA in general" — where the pool is large but extremely contested.
Map internal supply and adjacencies
The build-buy-borrow value of a skills map lives in this step. Without it, the answer always defaults to buy. With it, you can name specific employees and adjacent roles that could be redeployed or reskilled.
- Direct matches — employees with the skill at the required level today.
- One-step adjacencies — employees with 70-80% skill overlap who could move with 3-6 months bridge training.
- Two-step adjacencies — employees with 50-70% overlap who could move with 9-18 months of investment.
- Skill clusters — teams or job families where the skill is concentrated (good for cross-team mobility programs).
- Recent attrition with the skill — leavers from the past 12 months. Boomerang opportunities and competitive intel.
Semi/AI example Mapping internal supply for "AI inference engineering" might reveal: 2 direct matches (currently in your training infrastructure org but who've worked on inference before), 8 one-step adjacencies (HPC engineers and GPU performance engineers with strong CUDA but no inference exposure), and 14 two-step adjacencies (game engine perf engineers and ML compiler engineers). That's 24 people inside the building before you write the first external req — and a credible "borrow" path that the executive sponsor can fund.
Identify skill bridges — the reskilling pathways
Adjacencies are pools. Bridges are paths. For each adjacency you identified, define the concrete reskilling pathway: what does the person actually have to learn, how long does it take, and what's the cost of getting them there.
- The gap — which specific skills are missing or at lower level?
- The learning path — what's the realistic combination of self-study, formal training, on-the-job project, and mentorship?
- The duration — 3 months, 6 months, 12 months? Be honest. Most internal mobility programs fail because the bridge is longer than admitted.
- The cost — training spend, productivity dip during ramp, mentor time. Not always cheaper than hiring; sometimes is.
- The retention upside — internally reskilled employees often have higher retention. Quantify it where you can.
Semi/AI example Bridge from HPC engineer to AI inference engineer: gap is inference-specific tooling (Triton, ONNX, Nsight Compute for inference profiling) and inference-specific patterns (batched dynamic shapes, quantization, KV cache mgmt). Realistic path: 6 months of paired work + 1-2 internal training modules + production inference project ownership. Cost is the productivity dip + ~$15K formal training. Hiring externally would cost $40-80K in agency or sourcing time plus 4-month ramp. The bridge wins on cost and retention — but only when explicit.
Synthesize into a decision-ready map
The deliverable is not a giant skills database. It's a one-page (or short multi-page) map structured by the decision the map serves. Different decisions, different output structures — but the discipline is the same: compress aggressively.
- For sourcing strategy → the top 3 adjacent skill pools and the named source lists for each.
- For internal mobility → the named bridges and the time/cost to traverse each.
- For build-buy-borrow → the explicit comparison of the three paths with costs and timelines.
- For workforce planning → the supply/demand projection per priority skill at 12 and 36 months.
- For reskilling investment → the ranked list of skills worth investing in, with sunrise/sunset tagging.
- For role design → the recommended skill spec rewrite, with what to drop or relax.
See the starter template at the end of this guide for a flexible structure that accommodates any of these. The discipline is finishing with a named recommendation tied to the original decision frame — not a "here's the skills landscape" survey.
"Skills adjacency is a way of opening non-traditional pathways for candidates who don't have the experience doing the exact job needed but have every ounce of capability required."
Jolen Anderson, Global Head of HR, BNY Mellon — quoted in Deepening Talent Pools with Talent Intelligence (SilkRoad, 2023)What good looks like
A skills map that drives decisions has six observable features. A map without these is a taxonomy — interesting, but not operational.
Hierarchical, not flat
Skills are grouped in layers (root, core, soft, tools). A flat list of 40 skills is not a map — it's an unstructured inventory.
Tagged by criticality and trajectory
Every priority skill has a criticality tag (foundational / differentiating) and a trajectory tag (emerging / steady / declining). The pattern visible at a glance.
Has levels, not binaries
Skills are at L2/L3/L4 (or similar), not have/don't-have. The same skill at different levels is functionally different.
Maps both external and internal supply
External supply is mapped from market data. Internal supply is mapped from HRIS or explicitly flagged as a Phase 2 gap.
Names adjacencies and bridges
For each differentiating skill, the 1-step and 2-step adjacent skills are named, with concrete reskilling pathways and durations.
Tied to a decision and a refresh cycle
The map says what decision it serves and when it gets refreshed. Tech skills shift on 12-18 month cycles — older maps mislead.
Common mistakes
- Skills list too long. A 40-skill list is not actionable. 90% accuracy on the top 12 skills beats 60% accuracy on a 50-skill list every time. Compress.
- No skill levels. "Python" and "Python at L4 for distributed ML inference at scale" are functionally different skills. A map without levels overstates pool size and produces under-qualified candidates.
- Skipping the criticality tagging. When every skill looks equally important, the spec becomes a wish list. Hiring against a wish-list spec is why some reqs sit open 9 months.
- No internal mapping. Without the internal half of the map, build-buy-borrow defaults to buy. Even if your HRIS is weak, do the qualitative version with team leaders — it's better than skipping.
- Treating skills as static. Tech skills decay and emerge on 12-18 month cycles. A skills map without a refresh cadence misleads by year-end. Commit to refresh up front.
- Org-wide rather than phased. Big skills-architecture projects almost always fail. Pilot on 1-2 priority role families, prove value, then scale. TalentNeuron and Lightcast both echo this advice.
- Taxonomy without consumer. Building "the skills taxonomy" without a named decision and a named decision-maker produces an academic exercise. Always Step 1 first.
- Ignoring the soft-skills layer. Cross-functional comms, trade-off framing, mentorship — these often determine offer decisions and retention more than the technical skills do. Skip them and the map under-explains the hiring failures.
Starter skills map template
Flexible structure that accommodates the primary use cases (sourcing, mobility, build-buy-borrow, workforce planning, reskilling, role design). One role family per template. Adapt the synthesis section to the decision you're serving.