Setup Considerations: skill taxonomy

What this achieves

Your skill library is the shared vocabulary that job profiles, employee profiles, courses, and gap analysis all speak. Restructuring it after profiles reference it is far harder than getting the shape right at the start.

Decision 1: how granular a skill should be

The commonest failure is a library that is either too coarse to be useful or so fine that nobody can find anything.

Option	Description
Broad skills	Few entries, easy to browse. Everyone appears to have the same skills, so gap analysis says little.
Narrow skills	Precise. The library grows quickly, and two people describing the same ability may pick different entries.

The test is whether you would ever staff, hire, or train against the skill on its own. If you would, it is a skill. If it only ever appears as part of something larger, it belongs inside a competency instead.

Example: HC Corp UK Ltd holds a specific technical capability as a skill because it appears in job profiles and in gap analysis. “Good communicator” is not a skill — it is a competency, assessed differently.

Decision 2: skills or competencies

Both exist and they are not interchangeable.

Option	Description
Skill	A specific, demonstrable ability. Assessed, endorsed, and tracked for freshness on an individual.
Competency	A broader capability, typed as Core, Functional, Leadership, or Technical, built from weighted skills.

A competency maps to skills with a weight from 1 to 10 and a required flag, so it is a structured set rather than a label. Decide which layer a thing belongs to before creating it, because moving it later means recreating it.

Decision 3: categories

Skills and competencies each have their own categories, and category is the main way people navigate a library that has grown past browsing.

Agree the category set before creating many entries. Recategorising later is possible but the habit people form on day one is the one that sticks.

Decision 4: build your own, or import

The global library holds industry-standard skills you can import, filtered by region, industry, and category.

Importing gives you a defensible starting vocabulary quickly and brings terms your own people would not have written. Building by hand gives you exactly your language and nothing else. Most organizations do both: import a base, then add what is specific to them.

Imports skip anything that already exists rather than duplicating it, so importing more than once is safe.

Example: HC Corp UK Ltd imports a base set for its industry, then adds the internal tooling skills no external library would carry.

Decision 5: synonyms are how people actually find things

A skill carries synonyms and tags. These matter more than they look: two teams will call the same ability different things, and without synonyms they will create two entries for it.

Add the alternative names your people genuinely use, not the formal name twice.

Decision 6: deprecating is permanent

A skill can be deprecated, and that cannot be reversed — there is no way to reactivate a deprecated skill. Deleting is also final.

That makes tidying a library a one-way action. Before deprecating, check what references the skill: job profiles, courses that grant it, and employee profiles holding it.

What is expensive to change later

Decision	Cost of changing later
Deprecating a skill in use	Highest. It cannot be undone, and job profiles and employee records reference it.
Splitting one skill into several	High. Assessments and endorsements belong to the original entry.
Moving something between skill and competency	High. It has to be recreated at the other layer.
Recategorising	Medium. Cheap mechanically, disruptive to how people navigate.
Adding synonyms	Low, and worth doing continuously.

What happens next

Define your proficiency scale first, since skills and competencies are rated against one, then build the library. Once skills exist they can be attached to job profiles, granted by courses on completion, assessed on individuals, and compared against requirements in gap analysis.