What is a skills taxonomy – and how to build one people actually use

Most organisations have a rough idea of what their people can do. It lives in job titles, CVs that were last updated for a bid two years ago, and a manager's memory of who handled what on the last big project. That works until someone needs a precise answer. Do we have three engineers with cloud migration experience and an AWS certification available in Q3? Can we staff this tender without hiring? Which teams could lead our AI rollout?

The rough idea falls apart at that point, because nobody is using the same words for the same skills. What is missing is a shared language for skills, which is what a skills taxonomy is.

Few organisations can answer questions like these with confidence. According to Gartner's 2024 HR research, only 8% of organisations have reliable data on the skills their workforce has. Many HR teams already have a taxonomy project that died in workshops, and each failure makes the next one harder to get approved.

What is a skills taxonomy?

A skills taxonomy is the structured vocabulary of skills your organisation recognises, grouped into categories, with a short description of each skill. It is the shared framework every skills decision builds on, and it makes sure that "project management" means one thing everywhere, so that two people with the same ability pick the same skill, and a search for it finds both of them.

Without a shared vocabulary, "Advanced Excel" covers everything from pivot tables to financial modelling, one team's "stakeholder management" is another team's "client relations", and every report quietly adds up different things.

Several public frameworks exist as reference points. O*NET covers the US workforce, ESCO covers the European Union and SFIA covers digital and IT skills. The World Economic Forum's Global Skills Taxonomy, published in 2021 to give employers a common language for skills, is another. They are useful for checking names and coverage: Look up a role in O*NET, for example, and you see the skills it typically needs, in wording you can borrow. But they describe the labour market as a whole, so they still need adapting to the work your people do.

Skills taxonomy, ontology or competency framework?

The three terms get mixed up, and the difference decides what you build. A skills taxonomy organises skills into categories and levels. It tells you what exists. A skills ontology goes further and maps the relationships between skills, roles and tasks in a network, capturing links such as "machine learning requires both mathematics and Python". Many AI-driven matching systems are built on ontologies, and they need significant data infrastructure to deliver on their promise. A competency framework sets out how people are expected to behave and perform at each level of a role or grade, and is used for progression and assessment.

For most organisations a well-built taxonomy is the right starting point and often the right long-term tool: Get the data right first, and the sophistication can follow. In MuchSkills, role profiles combine the taxonomy with the framework idea: skills from the taxonomy, with the level each role requires. There is more on the distinction in our skills taxonomy FAQ.

Why it matters: Every skills decision rests on it

A skills taxonomy sounds like an HR admin task, but every workforce process that follows depends on it. A skills gap analysis needs it to define what a gap is. Strategic workforce planning needs it to compare the skills you will need with the skills you have. Learning budgets need it to connect a course to a skill rather than to a completion certificate. And in consulting, where people are the product, it is what lets a resource manager search with confidence instead of relying on whoever they already know.

A taxonomy that does this well is rare. According to Deloitte's research on the skills-based organisation, only 10% of HR executives say they effectively classify and organise skills into a taxonomy. When the classification underneath is weak, every gap analysis, development plan and workforce strategy built on it inherits the same weakness.

For more of the evidence, see our workforce skills statistics.

Don't start from a blank page

The most common way to stall a skills project is to build the taxonomy from scratch first. A company-wide workshop is booked, every department sends a list, and a quarter later the group is still debating whether "Agile" and "Scrum" are one skill or two. Managers who know the work well stall when asked to write their team's skills from nothing. Hand them a draft that is roughly right and the task changes from writing to editing. Deleting a wrong skill takes seconds, while inventing the right one takes an afternoon nobody has.

So start from a finished taxonomy and make it yours. To make that easy, we publish a complete example for a fictional company, Acme Inc. It has 12 categories and 371 skills, each with a one-sentence description, and it works in any spreadsheet as well as in MuchSkills, where each category sheet is already in the upload format.

Download the example skills taxonomy (Excel, 371 skills)

Here is what it covers:

• Essential human skills (48): How people work with others and themselves, such as teamwork, active listening and accountability. Used for every role.
• Global skills (38): Business skills that apply across functions, such as analytics, facilitation and project management.
• AI (15): Using AI tools well and responsibly in everyday work.
• Methodology & frameworks (22): Ways of working and standards such as Lean, Scrum, ITIL and ISO 27001.
• Dev & tech (30): Software engineering: design, build, test and run.
• Cloud & infrastructure (48): Networks, cloud platforms, security and operations.
• Data (17): Data engineering, analysis, governance and machine learning.
• Design & product (36): Product management, UX, UI and research.
• Sales (22): Finding, winning and growing customers.
• HR (29): People strategy, talent, performance, learning and employment law.
• Engineering (47): Engineering disciplines used in client projects.
• Inspection & testing (19): Non-destructive testing, welding inspection, rope access and asbestos surveying.

Acme does engineering and IT client work, so swap its specialisations for your own, and treat its AI category as a placeholder for the AI tools your people use (see Step 4). Tools, programming languages and certifications are left out on purpose: MuchSkills keeps them in built-in categories. If you're working in a spreadsheet, add the ones your roles need.

How to make the example yours

Turning the example into your organisation's taxonomy is a matter of cutting, adding and agreeing who decides. The five steps below are the order that works in practice.

Step 1: Agree what it's for and who owns it

Before you change a single skill, agree what the taxonomy needs to do. Staffing projects, closing skills gaps, planning learning and tracking certifications for compliance each shape what goes in and how detailed it gets. Some uses are easy to miss. Mapping the tools people use shows whether expensive software is being adopted, and mapping how well people know your own products shows whether, say, your support team really knows the software it supports.

Then decide who has the final say. We recommend one or two named owners, or a small group, who know how the whole structure fits together, listen to the people who use the data and settle disputes. Without them, every department adds its own version of the same skill, and nobody can compare teams any more.

Who those owners are depends on where the pressure comes from. In a consulting firm it is usually the head of delivery or resourcing, together with bid leads, because the taxonomy has to match the words in client requirements, RFPs and tenders. Without a shared taxonomy, staffing defaults to whoever the delivery lead already knows, and quieter consultants and remote team members get overlooked. In a technology company it often sits with HR or L&D and, increasingly, with engineering leadership, who otherwise plan what to build next without knowing whether the team can build it. In a large enterprise going through a major change programme it often needs a sponsor at board level, since you cannot credibly report on a strategy's skills if you cannot describe the skills you have. If you run one taxonomy across several countries, the same owners keep the core list global and let local teams add only what they need, such as languages, local certifications and regulations. Agree the shared core first, and leave local variation for the edges.

Step 2: Start with one team and the roles you need to fill

Start where you need answers now: one team of 10 to 15 people, the roles you are trying to staff or develop, and the 10 to 30 skills that matter most for them, which grow into full role profiles later. Good places to start are an area that is underperforming, a talent gap you already know about, or a long-term change such as an AI rollout. Within that area, map the best performers in the most critical roles first, because their profiles show what good looks like. Check that against what the role really needs. A scope that small is enough to answer a real question at the end, such as who could lead the next cloud project, and the result convinces the next team far better than a plan does.

Cut the categories in the example you will never use, and add the vocabulary that is specific to you. Include the skills your plans will need, not only the ones people have today. Common additions are client experience, so planners can staff people who know the account, and languages. Consulting firms often add a service-line category, so planners can see each consultant's specialty, and need more depth in methodologies such as PRINCE2 and Scrum, in cloud platforms and in the industries they serve. The entries under a service line should still pass the offering test in Step 4.

Step 3: Build role profiles of 30 to 40 skills

A taxonomy becomes useful when you connect it to roles. A role profile picks the skills a role needs from the taxonomy and sets the level required for each. For each role, ask three questions and give every answer a level: Which tools and methods does the role depend on, which people skills does it need every day, and which job-specific skills does the work require? The answers map neatly onto the categories in the example, plus the tools you add. Aim for 30 to 40 skills per profile. Technical roles can go up to about 60, since every technology in the stack is a skill of its own. Mark 10 to 15 of them, or up to 20 in some roles, as prioritised: the ones the role can't do without.

Keep an eye on the total. Every skill on a profile is a judgement someone has to make about themselves, and a list of 250 that nobody finishes produces little data you can use. Count the load per person across every profile that applies to them, because "optional" extra profiles soon feel compulsory.

To decide what goes in, use one question, which we call the resourcing test. If you searched for this skill and ranked people by it, would you find the right person for the project? The test removes sales language, and it removes skills so generic that they cannot tell two candidates apart. Apply it strictly to skills you staff on, and more loosely to skills used for development.

Step 4: Keep the taxonomy clean

The usual problems are the same ability ending up under several names, and entries creeping in that are not skills. Four rules prevent most of them:

• Build around stable competencies. Separate lists per team feel logical, but organisations restructure, teams merge and roles change. Build around skill areas that survive a reorganisation.
• What you sell is not a skill. Services firms tend to write their offerings into the taxonomy. "AWS Assessment" is a line on a quote; the skill underneath it is cloud architecture. A quick test: If the entry appears in no vendor career framework, no technical skills library and no job posting, it is probably an offering. Offering-shaped entries split the people who hold the real skill, and they age badly when products are renamed.
• A tool is not a capability, and one skill gets one name. "JavaScript programming" is the technical skill JavaScript, and "Technical mentorship" duplicates "Coaching and mentoring". Both split one ability across two names, so every search returns half the people while looking complete. The same skill can sit in two categories, as long as it is spelled exactly the same.
• For AI, name the tools. Abstract entries such as "AI literacy" or "Working with AI" fail because nobody can rate themselves on them in a way that tells colleagues apart. AI is in nearly every tool now, so asking people to rate themselves on "AI" in the abstract is a strange question. Track the tools people use, such as Microsoft Copilot, Claude or GitHub Copilot, and you get a concrete answer to the question your board is asking: who uses what, and how well.

Write a one-sentence description for every skill as you go. Vague descriptions produce inconsistent data. "Advanced communication skills" tells you almost nothing, while "able to lead client workshops and present technical findings to non-technical audiences" tells people exactly what they are rating. A good test: Two people reading the same description should rate themselves the same way.

Step 5: Rate, validate and connect it to gap analysis

Once the taxonomy is in place, people map themselves against it. Levels need to be precise enough to be useful: MuchSkills uses a 1 to 9 scale, where 1 to 3 is beginner, 4 to 6 intermediate and 7 to 9 expert. Three points inside each band separate "intermediate" from "intermediate and nearly ready to lead this", a distinction that tends to disappear on a five-point scale, where ratings drift to the middle.

Accuracy is the next worry. If people rate themselves, won't some inflate their ratings? Some will. Others, often the most capable, under-rate themselves. "Transparency is the best data quality mechanism," says Daniel Nilsson, co-founder of MuchSkills. When profiles are visible to colleagues, people rate themselves more carefully, because no one wants to claim expert status next to a genuine expert. Managers can add their own assessment next to the employee's without overwriting it. Organisations that switch colleague visibility off lean more on manager assessment.

Not every skill needs the same rigour, and checking them all isn't realistic: People add on average 50 skills each, so a manager with 10 people has around 500 ratings to look at. Put validation effort into the skills and certificates that carry consequences, such as those critical to client delivery or compliance, and use certification tracking with expiry alerts and an audit trail for those. Development skills can be self-reported with lighter oversight, because the goal is a picture useful enough to act on. Mapping is also a moment of self-reflection for each person, and a reason for managers and employees to talk about where they are heading.

A taxonomy and the ratings against it, together a skills inventory, are what make a meaningful skills gap analysis possible. This is the point where the taxonomy stops being an HR project and becomes a business tool. It is also what skills-based organisations run on, and Deloitte's research on the skills-based organisation found that they are 107% more likely to place talent effectively and 98% more likely to retain high performers. The gap analysis shows where to put the learning budget, where client delivery is exposed and where you need to hire. In our experience, many of those gaps can be closed with people you already have, through development or internal mobility, once you can see what they already know.

A taxonomy nobody maintains stops being trusted

A taxonomy built once and left alone degrades quickly, because skills keep moving. Lightcast's analysis of job postings found that 32% of the skills in the average job changed in just three years, and the World Economic Forum's Future of Jobs Report 2025 expects 39% of workers' existing skill sets to be reshaped or become outdated by 2030.

Keeping up is less work than most people fear: a few hours a month for the owners. Most of that time goes on three jobs. They fold near-duplicates into one skill, add skills that new client work or technology brings in, and retire skills nobody has picked in a year, unless you will need them soon. When a manager wants a new skill, the request goes to the owners, so the structure stays in one piece. Let the upkeep slide for a year and people stop trusting the taxonomy, the same way they stopped trusting the spreadsheet before it.

That raises the question of whether a spreadsheet is enough. For a team of fewer than about 50 people with simple, stable skill needs, it can be. Spreadsheets break in three predictable ways as you grow: one person owns the file, certificates expire without anyone noticing, and the person who needs an answer is not the person who maintains the sheet. At that point the spreadsheet is just a document, and what you need is a live system, which also makes it possible to plan ahead. Planning ahead pays: BCG's Creating People Advantage 2026 found that organisations strong in strategic workforce planning tend to fill critical roles in 38 days, against 55 days for the rest.

How MuchSkills helps you build and keep a skills taxonomy

In MuchSkills you never start from a blank page. Every workspace opens with a suggested set of categories (essential human skills, global skills, specialisations, and methodologies and frameworks) that you rename, cut and extend, next to four built-in categories: job focus, technical skills, soft skills and certifications. Behind them is a database of 20,000 industry-specific skills, plus 12,000+ technical skills and 9,700+ certifications curated and maintained since 2020. MuchSkills keeps that database current, so your owners only look after your organisation's own additions. You choose which departments see each skill, so nobody scrolls past hundreds that don't apply to them, and you can change what the nine levels mean for a category, for example to describe language proficiency.

When you name a role, AI suggests its skills from your own taxonomy, and an administrator reviews, accepts or rejects each one. Role profiles then feed straight into the skills matrix, gap analysis, the Team Builder and search across the organisation. That is what turns a list of skills into skills intelligence for workforce decisions.

If you would rather not do it alone, professional onboarding designs the taxonomy and role profiles with you, one role at a time. The platform is live in days, and full onboarding takes two to twelve weeks, depending on the number of users and how complex the setup is. The step-by-step guide to loading a taxonomy into MuchSkills is in Build your skills taxonomy.

Start with the example and an owner

If you run a consulting or professional services firm, start with the roles you staff most often and the words your clients use in tenders; see how MuchSkills works for consulting firms. If you lead HR or L&D, start with one team and the roles you most need to develop. Either way, download the example, cut it down and name an owner this week. The skills you map first matter less than the discipline of mapping them well.

When you want to see a taxonomy working on live data, with search, gap analysis and role profiles built on it, book a demo.