Every skills taxonomy project has the same shape.
Week 1, the team is energised. Week 4, the taxonomy has 320 skills across 9 levels. Week 8, they are arguing about whether "stakeholder management" and "executive communication" are the same skill. Week 16, they have built a perfect catalogue that nobody will ever use.
There is a middle path.
What a skills taxonomy is actually for
Before the build, a question: what decisions do you want this taxonomy to enable?
In practice, the useful decisions are:
- Hiring: what skills do I need to find in a candidate for this role?
- Internal mobility: who in the business has skill X, Y and Z?
- Capability investment: where do we have the biggest skill gaps against the strategy?
- Role design: are we asking too much of one role, and should we split it?
A taxonomy that cannot cleanly answer those four questions is not finished. A taxonomy that tries to answer more than those four questions is over-built.
The 4 rules
Rule 1: Fewer, bigger skills. Aim for 80 to 120 skills at most, across the whole organisation. If "written communication" and "executive summary writing" are both skills in your taxonomy, you are already too granular for the decisions you actually need to make.
Rule 2: Two or three levels, not five. Most taxonomies use five proficiency levels (Novice, Advanced Beginner, Competent, Proficient, Expert) because one academic paper from 1980 said so. For almost every business decision, three levels is sharper:
- Foundational: can do the task under supervision
- Proficient: can do the task independently and well
- Deep: can teach, unblock others, and design new approaches in the space
You will find three levels much easier to calibrate, and they map more cleanly to hiring, development, and succession.
Rule 3: Tag skills to role families and strategic priorities, not individuals. An individual's profile is the output of the system, what skills they have, at what level. Not the starting point. Do not start by building profiles of every role. Start by naming the skills and the role families that need them.
Rule 4: Ship v1. Iterate in production. Publish at week 6 even if you are embarrassed by it. Tag 20 to 30 roles. Have 10 to 20 managers use it in a real calibration conversation. Watch where it breaks. Fix those parts. Release v2 at week 12.
Do not publish v1 to the whole organisation. You do not need it perfect. You need it tested.
The six-week build
Week 1: Interviews and strategic framing. Talk to 8 to 12 senior leaders. Ask: "if this taxonomy existed and was useful, what decisions would it help you make?" And: "What skills do our highest-performing people have that our average-performing people do not?"
Week 2: Draft the skill list. Cluster what you heard. You will end up with around 100 skills. Ruthlessly collapse overlapping ones. If two skills cannot be meaningfully distinguished in a hiring conversation, they are one skill.
Week 3: Draft the level descriptors. For each skill, write Foundational / Proficient / Deep descriptors in the first person. ("I can… on my own" is clearer than "demonstrates the ability to…"). If you cannot write clear first-person descriptors, the skill is probably two skills.
Week 4: Role family mapping. Cluster roles into 6 to 10 families. For each family, pick the 10 to 15 skills that matter most and the expected level for each career stage. Ignore the other skills, they are still in the taxonomy, just not core to this family.
Week 5: Pilot calibration. Run the taxonomy through real calibration conversations in 2 or 3 teams. Watch what works and what does not. Particularly watch where managers struggle to distinguish levels.
Week 6: Ship v1. Publish internally. Be explicit that this is v1. Commit to a v2 date, 6 to 12 weeks out.
The pitfalls
Pitfall 1: Adopting an industry taxonomy wholesale. Industry taxonomies (SFIA, O*NET) are useful reference material. Using one as-is misses the capabilities that actually differentiate your business. Cherry-pick, do not copy.
Pitfall 2: Trying to serve HR, learning, and workforce planning systems simultaneously. Each of these systems wants slightly different granularity. Pick one primary use case and design around it. The others will benefit from the same v1.
Pitfall 3: Using the taxonomy as a stick. If the first visible use of the taxonomy is "you are rated Foundational, now you are on a performance plan", the whole system becomes defensive and the data quality collapses. Lead with development and mobility, not ranking.
Pitfall 4: Maintaining the taxonomy by committee. Assign a named owner. They can consult widely, but one person is accountable for what is in and what is out. Committees produce 320-skill taxonomies.
How a good taxonomy shows up in practice
Six months after a good skills taxonomy lands, you should see some of these:
- Hiring briefs start citing 3 to 5 target skills at named levels, replacing the "all-rounder" job spec
- A meaningful portion of internal moves (20%+) are sourced from the taxonomy rather than the manager's network
- Learning investment shifts from generic programs to skill-specific interventions tied to the gaps
- The exec team can have a 30-minute conversation about capability risk using the taxonomy as shared language
If none of those things have happened, your taxonomy is ornamental. That is a rework signal.
A template to start from
The Capability Framework Template has a lightweight skills taxonomy structure built in, role families, proficiency levels, and the calibration guide we use with clients. It is a starting point, not a finished product.
Welcome to better.