Is a skills taxonomy the same as a skills library?

Nearly. The taxonomy is the design: the names, definitions, and groupings. The library is the taxonomy implemented in a system where roles and assessments can use it. A taxonomy in a spreadsheet is a plan; a library is the working version.

How many skills should a taxonomy contain?

Enough to differentiate the work the organization actually does, and no more. Most organizations land between one hundred and a few hundred skills in active use. A list is too long when teams cannot find their skills in it, and too short when two different jobs look identical.

Should we start from an industry standard?

Borrow from one, do not adopt one. Standards are useful for definitions and for checking coverage, but the skills that get assessed have to be named in the words the organization uses, or managers will not recognize their own work in the list.

Who owns the taxonomy?

One person or a small group with the authority to add, merge, rename, and archive skills, usually in L&D or HR operations. Ownership matters more than the initial design, because a taxonomy without a steward accumulates duplicates within a year.

How does a skills taxonomy relate to a competency framework?

The taxonomy supplies the vocabulary; the framework states which skills each role requires and at what level. You can have a taxonomy without a framework, but not a framework without a taxonomy.

Learn · Skills

Skills Taxonomy

A skills taxonomy is the controlled, organized vocabulary of skills an organization uses to describe work, grouped so that every role, assessment, and report draws from the same named list rather than from free text.

By Samantha, SkillsDB|Published Jul 10, 2026|Updated Sep 18, 2026

What It Is

A skills taxonomy answers one question before any other skills work can begin: what are the words? Without a controlled list, two managers describe the same capability three ways, a search for "welding" misses "MIG welding," and no two teams can be compared. The taxonomy fixes the names, attaches a definition to each, and groups them so that a library of several hundred skills stays navigable. Three layers do the work. The skill itself is the unit that gets assessed. Groupings, whether called categories, sections, or labels, collect related skills for browsing and reporting. Roles then draw the skills they require from the library, so the taxonomy and the job architecture stay connected rather than maintained twice. The recurring mistake is importing a large industry taxonomy and expecting adoption. Those lists look complete in a demo and stall in use because they describe work in someone else's language. Two hundred skills the organization named itself outperform ten thousand it never will.

Key Facts

A taxonomy is a controlled vocabulary: each skill has one canonical name, one definition, and one place in the structure.
The three layers are the skill, the grouping (category, section, or label), and the role that requires the skill.
Groupings are for navigation and reporting; assessment happens at the skill level only.
A skill can appear in many roles, each with its own required level; the definition stays the same everywhere.
Renaming a skill in the library should update every role, assessment, and report that uses it; if it does not, the taxonomy is a document, not a system.
Taxonomies drift without an owner; new skills arrive as requests, duplicates get merged, and retired skills are archived rather than deleted.

Custom vs. Pre-Built Taxonomies

Question	Pre-built industry taxonomy	Custom, organization-language taxonomy
Whose words	A standards body's or a vendor's	The people who do and manage the work
Starting size	Thousands of skills, most irrelevant to any one team	Dozens to a few hundred, all in use
Time to first assessment	Long; teams first argue about which imported skills apply	Short; the skills were named by the teams being assessed
Adoption pattern	Strong at launch, then abandoned as shelfware	Grows by request as teams add what they are missing
Best use	A reference to borrow definitions from, not a list to adopt whole	The live library roles, assessments, and matrices run on

How SkillsDB Models It

In SkillsDB the taxonomy is the Skills Library, the single catalog every skill originates from, plus two organizing layers on top of it. Labels form a hierarchical tree with a color per label, so Compliance can hold Safety, which holds OSHA Certification, and the library can be grouped or filtered by any of them; Careers then arrange the skills they require into Sections such as Programming Languages or System Design. A skill named Root Cause Analysis exists once, carries one description, and appears in the Quality Engineer career at Level 1 with a benchmark of 2 and in the Plant Manager career at Level 3 with a benchmark of 4. Rename it in the library and every career, assessment, and matrix updates. Employees browse the library and select Add Skill to put a skill on their own profile, or submit a skill request that an administrator approves, edits, or rejects at Manage → Skill Requests, so the vocabulary grows from the work. See the Skills Library and Career Frameworks.

Read the full guide

What Are Skills? Types, Skill Sets, and How Organizations Map Them

What Is a Skill?

the unit the taxonomy organizes

Skills Inventory

the per-person record built on the taxonomy

Competency Framework

the required levels that sit on top of the vocabulary

Job Roles and Job Architecture

the roles that draw their skills from the library

Skills Library

the SkillsDB feature