the job description is the wrong unit of analysis
job titles average away the variation that matters, and the decisions enterprises now face need a smaller unit than the job.
Most large enterprises now own a skills taxonomy. Few of them can point to a decision it changed.
Deloitte's skills-based organisation study found that 85 percent of HR executives had skills classification efforts underway, while only 10 percent said they effectively classify skills into a taxonomy. The same research found fewer than one in five organisations adopting skills-based approaches to any significant extent.
The usual reading of that gap is that the work is unfinished. A more useful reading is that the artefact is being asked to do something it was never built to do. A taxonomy is a controlled vocabulary. It resolves naming. It does not resolve meaning.
what a taxonomy is genuinely good for
This is not an argument against taxonomies. Without one, an enterprise cannot count anything. "Python", "Python programming", "Python 3" and "python scripting" are four rows in a spreadsheet and one skill in reality. A taxonomy collapses them, sets parent and child relationships, and gives every downstream system a shared vocabulary.
That is real value, and it is a prerequisite. It is also the entire extent of what a taxonomy delivers on its own. The moment you try to make a workforce decision, three things are missing.
what it cannot tell you
proficiency
A taxonomy says a skill exists and that a person is associated with it. It says nothing about depth. Two people tagged with "financial modelling" may be separated by a decade of practice and a full order of magnitude in output quality.
Depth is where almost all staffing risk sits. Nobody fails a project because a capability was absent from the org chart. They fail because the capability was present at a level below what the work demanded, and nothing in the system distinguished the two.
Proficiency is also the part most self-assessment data gets wrong, in a predictable direction. A skills profile assembled from self-reported tags is a record of confidence, not competence, and the two correlate weakly.
context
The same skill name means different things in different places. "Stakeholder management" in a two-hundred-person business unit and "stakeholder management" across a regulated multinational with matrix reporting share four words and very little else.
A taxonomy is deliberately context-free, because that is what makes it portable. The portability comes at the cost of the specificity you need to decide whether a particular person can do a particular piece of work here.
The practical consequence shows up in internal mobility. Match rates against a taxonomy look strong, hiring managers reject the matches, and everyone concludes the marketplace does not work. What failed was not the marketplace. It was the assumption that a shared skill label implies transferable capability.
currency
Skill records carry no expiry date, and skills do. A taxonomy entry created in 2021 asserts the same thing in 2026 with equal confidence, having learned nothing in between.
how fast the requirement moves
The decay is measurable, and the measurements are less comfortable than most planning assumptions.
Lightcast, working with the Burning Glass Institute and BCG, analysed 15 million job postings and reported in 2022 that the skills requested in the average US job had changed 37 percent since 2016. One in five of those skills was entirely new to the occupation, meaning nobody in that career would have been expected to hold it a few years earlier.
Lightcast's follow-up analysis of the 2021 to 2024 window found the average job saw 32 percent of its skills change over three years, and that one in four jobs experienced 75 percent skill turnover. Their conclusion was that the pace is accelerating: the most recent three years were nearly as disruptive as the five before them.
The World Economic Forum's Future of Jobs Report 2025, based on employers representing more than 14 million workers, reports that 39 percent of workers' core skills are expected to change by 2030. That figure has fallen from 44 percent in the 2023 edition and 57 percent in 2020, which is worth noting honestly. Skill instability is high but no longer accelerating in employer expectations.
Put the two evidence bases together and the operating implication is clear. Roughly a third of the skill requirement in an average role turns over within a three-year cycle, and the turnover is not evenly distributed. Some roles are close to stable. Others are substantially rewritten inside a single planning horizon.
what a market-benchmarked capability model adds
A capability model is a taxonomy with three additional commitments, each of which costs something.
- proficiency scales with observable anchors. Not "beginner to expert" but a description of what a person at each level produces, decides, and escalates. The anchor has to be behavioural, or assessors will silently reinterpret it.
- context binding. Each skill is attached to the tasks it enables inside your specific role architecture. This is what turns a match into a defensible recommendation, because the claim becomes "can do these tasks" rather than "has this tag".
- market reference. The expected skill set for a role is compared against external labour market signal on a set cadence, so drift is detected rather than discovered.
The third commitment is the one most internal projects skip, and it is the one that determines whether the model stays true. Without an external reference, a capability model records what your organisation currently believes a role requires. That belief is itself an artefact of the last time somebody looked.
a grid for deciding how hard to work at this
Not every skill deserves the same governance. Score each skill in your model on two axes.
Volatility: how fast the market definition of this skill is moving. Tool-specific and platform-specific skills are high. Domain judgement, regulatory knowledge and craft skills are usually lower.
Consequence: what breaks if you are wrong about someone's proficiency. A misjudged capability in a safety, financial control or client-facing decision role carries a different cost from a misjudged one in an internal support task.
Four quadrants follow, and each takes a different treatment.
- high volatility, high consequence. Assess directly and re-benchmark against the market quarterly. This is a small set, usually under 30 skills. Spend real money here.
- high volatility, low consequence. Track through activity signal rather than assessment. Refresh the definition annually and accept imprecision on individuals.
- low volatility, high consequence. Assess directly, but re-benchmark rarely. Certification and structured evaluation work well because the target is stable.
- low volatility, low consequence. Leave in the taxonomy. Self-report is sufficient. Do not build assessment infrastructure for this quadrant, however much easier it is than the first.
Most organisations invert this. They build careful assessment for stable, low-stakes skills because those are tractable, and rely on self-report for the volatile, high-stakes ones because those are hard.
what to do on Monday
Take the twenty skills your organisation most often names in workforce plans. For each, write down three things: the behavioural definition of level three, the last date the definition was reviewed, and the external source used to check it.
Count how many rows you can complete. That count, not the size of your taxonomy, is the honest measure of your skills capability today. Most enterprises complete fewer than five.
Then fix the highest-consequence gaps first, using the grid above. Resist the pull toward completeness. A capability model covering 40 skills with real proficiency anchors and a live market reference is worth more than one covering 4,000 without them.
This is the difference entomo drew when building axon around benchmarked role architectures rather than a static skill list, with market benchmarks refreshing monthly rather than at project milestones. The principle holds regardless of what you build on: a taxonomy tells you what to call things, and a capability model tells you what is true.