Skip to content

Skills

What a Skill Taxonomy Is, and Why Most of Them Fail

The four things a taxonomy needs to do any work, the five ways they usually rot, and why the enterprise-wide launch is the wrong first move.

GaugeSkills Skills 4 min read

Three teams in the same company describe the same ability three different ways. One calls it data storytelling. One calls it business reporting. The third has it on a spreadsheet as “Excel (advanced)”. A staffing manager looking for someone who can turn a messy dataset into something a client can act on searches the skills system, finds nothing, and hires a contractor. Two of the three people she needed were on the floor above her.

A taxonomy is the fix for that. It is also the thing most organizations believe they already have, because they have a list of skills in a spreadsheet, and a list is not a taxonomy.

What a taxonomy actually is

Four things, all of which have to be present for it to do any work:

  • A controlled vocabulary. One preferred name per skill, with every alias mapped to it. “Data storytelling” and “business reporting” resolve to the same entry, so searching either one finds both people.
  • A structure. Families and sub-families, shallow enough that someone can navigate it without a manual. Two levels of nesting is usually enough; four is a sign the model is describing the organization rather than the work.
  • Definitions written as capability. Each entry states what a person can do, in terms that could be observed. Not a topic, not a subject area, not a department name.
  • Rules. Written decisions about what counts as a skill, what is a tool, what is a role, and what is a behaviour. Without rules, every contributor adds entries in their own shape and the structure dissolves within a year.

Levels and evidence then hang off that structure. A taxonomy without levels tells you who has touched something; a taxonomy with levels and evidence tells you who can be trusted with it. That difference is the point of treating skills as measured data rather than as tags on a profile.

Why most of them fail

Imported wholesale

Adopting a public skills library of several thousand entries gives you immediate coverage and almost no meaning. Nothing in it reflects how your organization divides work, which distinctions matter in your domain, or which of those thousands of entries anybody will ever staff against. Public libraries are excellent raw material and a poor finished product. Use one to avoid inventing vocabulary from scratch, then delete ninety per cent of it.

Granularity that does not hold

The most common structural failure is peers that are not peers. A workable rule of thumb: a skill should be something you could meaningfully assess in one sitting and staff a piece of work against. If it would take a decade to acquire, it is a family. If it takes an afternoon, it is a task, and it belongs inside a skill rather than beside it.

Tools mistaken for skills

Tool names are seductive because they are concrete and easy to search. They are also the fastest-decaying part of any taxonomy, and they encourage hiring for the tool rather than the capability. Model the capability — container orchestration, statistical modelling, contract drafting — and carry the specific tools as attributes underneath it. When the tool changes, and it will, the skill survives and so does the history attached to it.

No owner and no change process

Taxonomies rot in a specific way: new work arrives, the vocabulary does not cover it, people improvise in free-text fields, and within two years the free text carries more truth than the structure. The fix is boring. Name an owner, publish a change window, require a short justification for new entries, and merge duplicates on a schedule.

Not connected to evidence or to roles

If the taxonomy is not what assessments measure, and not what role profiles reference, it is a glossary. The connection has to run in both directions: a role states which skills at which levels it needs, and an assessment result writes back to the same entries. Only then can the gap between the two be computed rather than estimated in a workshop.

A smaller thing that works

Pick one job family where staffing is painful right now. Build forty to sixty skills for it, with real definitions and mapped aliases. Attach them to the four or five role profiles in that family. Assess one cohort. Look at what the data cannot answer and fix the vocabulary. Then, and only then, take the second job family.

This is slower to announce and considerably faster to finish. It also produces something defensible at every stage, which matters when the programme has to survive a change of sponsor. The enterprise-wide launch, by contrast, produces its first usable output at the point where the original budget has already been spent.

Education has the same problem, in different clothes

Curriculum outcomes, syllabus topics and the concepts that actually get assessed are three overlapping vocabularies that are rarely reconciled. When a question is tagged with a topic rather than the concept it tests, results can be reported but not diagnosed, which is why a college can know a module has a low pass rate and still not know what to change about it. The discipline required is identical to the enterprise case: one vocabulary, defined as capability, connected to the evidence. Getting that mapping right is most of what makes academic analytics useful rather than decorative.

The test

A taxonomy is working when a question about people can be answered by the system rather than by the longest-serving manager in the room. That is a low bar and very few organizations clear it, largely because they built a comprehensive list when what they needed was a small, governed vocabulary connected to real evidence.

Keep reading

Bring the vocabulary you already have

Most organizations have three overlapping lists. We will show what it takes to reconcile them into something that answers a staffing question.