Skills taxonomy versus job architecture
A job architecture defines roles, levels and reporting lines; a skills taxonomy defines the capabilities inside those roles, independent of title. Job architecture answers where someone sits; skills taxonomy answers what they can do. Building a skills taxonomy before job architecture is settled tends to produce lists that nobody can map back to real work.
| Job architecture | Skills taxonomy | |
|---|---|---|
| Answers | Where does this role sit | What can this person do |
| Unit | Role, level, family | Skill, proficiency level |
| Changes how often | Slowly, with restructures | Continuously, as work changes |
Job architecture and skills taxonomy get bundled together in vendor pitches, but they answer different questions and depend on each other in a specific order.
What each one is
Job architecture is the structure of roles: titles, levels, families, and how they relate to each other. A skills taxonomy is the structure of capabilities: what a person can do, independent of their job title.
Why order matters
A skills taxonomy built without a reference job structure tends to sprawl: hundreds of skills with no anchor to real work, hard to maintain and harder to act on for planning.
- Job architecture first, or in the same project
- Anchor each skill cluster to specific roles or families
- Review both together at the same cadence, not separately
Organisations that get workforce planning value from skills data almost always did the structural work on roles first, even if the skills project ran only slightly behind it.
Underlag
- Our assessment
Skills taxonomies built without a reference job structure are harder to keep current.
Common questions
- Can we build a skills taxonomy without job architecture?
- It is possible but risky; without a role structure to anchor it, the taxonomy tends to sprawl and lose relevance.
- Which should be updated more often?
- The skills taxonomy, since capabilities shift faster than formal role structures.