This is Part 2 of 3 on skills-based learning in organizations. In Part 1 I looked at what skills-based means, where it came from, and why most companies are still just talking about it. In this post, I want to get into what it can actually look like when an organization builds the practice. (Part 3 is what I hope can be your playbook.)
In Part 1, I expressed my belief that the gap between talking about skills-based and building skills-based is where almost every organization is sitting right now. I want to use this post to try to make that gap a little more visible, to walk through the pieces of a skills-based organization so you can look at your own and ask, honestly, which of these do we have, and which do we not?
Here’s something I’ve come to believe as I’ve read and thought about this: skills-based isn’t one initiative. From what I can tell, it’s really five or six interlocking pieces that have to talk to each other. You can’t just buy it. You build it. And whether you like it or not, you’re going to have to get a lot of people on board and working together. But it can be done, and I believe the order you build it in matters as much as the tools you choose.
So let me walk through the pieces as I understand them.
1. The Skills Taxonomy, Your Shared Language
I believe it actually starts with identifying the skills your organization needs: the skills behind the tasks your employees are already completing, and the ones rooted in your values, mission, vision, and your customer. Once you start there, what you’re really building is a skills taxonomy: a single, structured library of the skills that matter to your organization, defined clearly enough that two different managers would describe the same skill the same way. This sounds boring. I’ve come to believe it might be the most important thing on this list.
Here’s why. If your sales team calls it “client management,” your services team calls it “account ownership,” and your support team calls it “customer relationship handling,” you have three names for what might be the same skill, and you’ll have a hard time seeing across your workforce. A taxonomy is the shared dictionary that lets the whole organization speak one language about capability. We already do this with key terms in other parts of our organizations. I think it’s time we bring that same consistency to HR and Learning and Development.
A usable taxonomy seems to have a few common properties. It’s tiered: broad skill families (communication, data analysis, clinical care) that break down into specific, observable skills. It defines proficiency levels, what “beginner” versus “expert” actually looks like in behavior, not just adjectives. And critically, it distinguishes between durable skills (the human capabilities that transfer across roles, like communication, problem-solving, and de-escalation) and perishable skills (the technical, tool-specific ones that go stale fast, like a particular software version or a specific compliance protocol). One way I’ve found helpful to think about it: can someone learn a tool, or do they simply know a tool? Those aren’t the same thing, and knowing a tool today doesn’t guarantee someone can pick up the next one.
That durable-versus-perishable distinction is one of the more useful mental models I’ve picked up. Durable skills are where I think you get mobility; they’re the foundation that lets an employee at the register grow into a role driving a company delivery truck, to use the example from Part 1. Perishable skills are where you get obsolescence; they’re the delta you have to keep closing. My sense is that a lot of organizations over-invest in perishable training and under-invest in durable development, which feels backwards if you care about long-term adaptability.
The good news is you don’t have to build a taxonomy from a blank page. Public frameworks already exist, like O*NET in the U.S.,1 the EU’s ESCO,2 and Lightcast’s Open Skills library,3 and most modern talent platforms ship with a starter taxonomy you can adapt. The thing I’d caution against is treating someone else’s taxonomy as gospel. Your version has to reflect the actual work your people do, just like the terms you use day to day are your organization’s terms.
A skills taxonomy isn’t a document you finish. I think of it more as a living dictionary you maintain, and the organizations that treat it as a one-time project may be the ones whose “skills strategy” quietly stalls out in year two.
2. Competency Mapping, Connecting Skills to Work
A taxonomy tells you what skills exist. Competency mapping connects those skills to the actual work, to roles, tasks, and outcomes. This is where you try to answer the question every skills-based decision seems to depend on: what does it actually take to do this job?
In a traditional model, a job is a title plus a list of responsibilities plus “5+ years of experience.” In a skills-based model, a role becomes a profile of skills at specific proficiency levels. A registered nurse role isn’t “BSN plus two years,” it’s clinical assessment at an advanced level, patient communication at an advanced level, documentation at a proficient level, medication administration at an expert level, and so on. Now the role is something you can measure people against instead of just hire into. (Yes, I know there are some real technicalities here. I think I’ll save tuition reimbursement, subsidies, and the education collaborations you can build with different programs for another post.)
Once roles are mapped this way, a couple of things become possible that I don’t think are really available in a title-based world. First, you can do a real gap analysis, comparing the skills a person has against the skills a role requires and seeing the exact delta. Second, you can start to find adjacencies, roles that share enough skill overlap that movement between them is realistic. That’s the engine behind internal mobility, and it’s why I keep coming back to it: adjacency is nearly invisible in a title-based org and much more obvious in a skills-based one.
This is also where I think instructional designers earn their seat at the table. Competency mapping is, at its core, a needs analysis problem, the same discipline good instructional design work has always been built on. We’re trained to look at a performance outcome and work backward to the capabilities that produce it. That’s essentially what mapping a role to skills requires. If you’ve ever built a curriculum from learning objectives, I’d argue you can do this.
3. Skills Assessment, the Part I Think Gets Hardest
This is where, from what I’ve seen and read, a lot of skills-based efforts struggle. You can have a beautiful taxonomy and perfectly mapped roles, but if you can’t accurately answer who actually has which skills, at what level, you have a filing system rather than a strategy.
Skills assessment is how you try to populate the model with reality. And it’s genuinely hard, because the easy methods tend to be the least reliable and the reliable methods tend to be the most expensive.
The most common approach is self-assessment, asking people to rate their own skills. It’s cheap, fast, and scales instantly. It’s also distorted by the Dunning-Kruger effect in both directions: the least skilled tend to overrate themselves, and some of the most skilled underrate themselves.4 So I’d treat self-assessment as a fine starting signal, but a poor final answer.
Better signals seem to come from manager validation (someone who observes the work confirms the level), peer review, and best of all, evidence-based assessment: demonstrations, work samples, simulations, scenario-based evaluation, or actual performance data. And a fun tip: this is a great place to bring in a little gamification. If you tie a skill to a badge, people can earn that badge once they’ve demonstrated they’re competent, which makes progress visible and a little more motivating.
It also helps to remember that different skills call for different kinds of proof. In the world I come from, a clinician’s skill is usually best confirmed through observed competency check-offs, where someone qualified watches them perform the procedure and signs off. A call center agent’s de-escalation skill, on the other hand, is probably far better measured by reviewing real call recordings than by asking them to rate it one through five. Same idea, very different evidence, because the work itself is different.
I believe the most practical answer for most organizations is some kind of layered model: start with self-assessment for breadth and speed, validate critical skills through manager sign-off and evidence, and reserve rigorous, evidence-based assessment for the high-stakes skills where being wrong is costly, like safety, compliance, clinical care, anything regulated. You probably don’t need expert-level rigor on every skill. You need it on the ones that matter to your customers and your business goals, vision, and mission.
I’ve come to believe the quality of your entire skills-based system is capped by the quality of your assessment data. Garbage in, garbage out is something we hear a lot in Learning and Development, and I think we’ll keep hearing it as we feed more data into more systems, except now that garbage may be driving promotion, hiring, and workforce-planning decisions.
4. Career Mobility and Pathways, Where I Think It Pays Off
This is the part employees actually feel, and the part that, done well, I’ve experienced can really help with retention. I’ve worked for companies who do this well, and it shows up everywhere: in tenure, in retained knowledge, in customer base growth and retention, and in continued profits and expansion. Once you have a taxonomy, mapped roles, and assessment data, you can start to build career pathways based on skills instead of ladders based on tenure.
In a traditional org, career growth often looks like a ladder: you wait for the person above you to leave. In a skills-based org, it can look more like a lattice, where you can move up, but you can also move sideways into an adjacent role, or diagonally into a function you have transferable skills for. At its best, the system can show an employee: here are the roles you’re close to, here’s the specific skill gap between you and each one, and here’s a development path to close it.
I also think this helps people find their passion in their role. And we all know what they say about people who find passion in the work they do: it doesn’t quite feel like work. That’s honestly why I’m writing this blog right now, and hopefully part of why you’re reading it. We love this stuff.
That kind of visibility is, I think, the real retention play. People don’t leave only for money; sometimes they leave because they can’t see a future where they are. A skills-based pathway can make that future feel more legible. And it shifts the development conversation from “what training is available” to “what skill am I building, toward what role, by when,” which feels like a more motivating frame. There’s also a learning angle here worth naming: when people are genuinely motivated to learn something, they tend to learn it more easily. Pointing development at a role someone actually wants taps into exactly that kind of motivation.
It also reframes internal mobility as a sourcing strategy. When a role opens, the first question can stop being “who do we recruit?” and become “who’s a skill or two away, and could we close that gap faster than we could hire and onboard externally?” Given that internal moves tend to fill roles faster and retain institutional knowledge, that’s often a strong option, but only if the skills infrastructure actually exists.
5. Where AI Might Fit
I’ve written before about trying to be honest about what AI can and can’t do, so let me try to be careful here rather than hand-wavy. I think skills-based and AI are closely connected, not because AI is magic, but because the skills-based model produces exactly the kind of structured data AI tends to be good with, and AI can remove some of the manual bottlenecks that used to make skills-based feel impractical at scale.
A few places AI seems genuinely useful today. First, skills inference: modern platforms can read job descriptions, project histories, and work artifacts and suggest the skills they imply, which can lower the cost of the taxonomy and mapping work. Second, gap analysis and recommendations at scale: matching many employees against many role requirements and surfacing personalized development suggestions is the kind of pattern-matching AI does well. Third, keeping the taxonomy alive: AI can flag emerging skills showing up in your job reqs and industry data so your library doesn’t quietly go stale.
And one honest caution. AI-inferred skills are suggestions, not verified capability. The fact that a model reads “managed a CRM migration” and infers “project management” doesn’t mean that person can do it at the level your open role needs. I believe AI can be very helpful at building the map, but it’s not the right tool to be the final word on who’s standing where on it. The human in the loop, manager validation, evidence, judgment, isn’t a nice-to-have. I think it’s the thing that keeps the whole system trustworthy and verified.
The way I see it, AI can make a skills-based organization more feasible at scale. It doesn’t make it real. The data still has to be true, and truth still seems to require human judgment.
How I Think the Pieces Fit Together
Step back and the system has a logic to it. The taxonomy gives you a shared language. Competency mapping connects that language to real work. Assessment tries to populate it with the truth about your people. Mobility and pathways turn all of that into something employees can act on. And AI can help make the whole thing workable at a scale where manual effort alone would either cause you to pause or take far too long.
Pull any one piece out and I think it starts to break down. A taxonomy with no assessment is a dictionary nobody uses. Assessment with no pathways is measurement with no payoff; you’ve told people where they stand and given them nowhere to go. Pathways with no honest assessment are a promise you may not be able to keep. This, to me, is why skills-based is so much harder than it sounds, and why “we bought a skills platform” isn’t the same sentence as “we are a skills-based organization.”
It’s also why I keep saying this is as much an L&D and instructional design challenge as an HR one. Defining observable proficiency, mapping roles to capabilities, designing valid assessment, building development paths to close gaps: these are things our discipline has been doing all along, just at the level of a single course. Skills-based seems to ask us to do it at the level of the whole organization.
What’s Coming in Part 3
Knowing the components is one thing. Figuring out how to actually stand them up, without trying to do everything everywhere all at once, without losing your leadership’s patience, and without building something that falls over the moment you stop pushing, is another. That’s what I want to get into in Part 3: a practical playbook for where you might start, how you might earn buy-in, what to measure first, and some of the common mistakes I’ve read others make.
Because the components are knowable. The execution is where I think it really gets tested.
Which of these five pieces does your organization have, and which are you missing? I’m genuinely curious where people are landing. Come tell me on LinkedIn.
References
- U.S. Department of Labor. (n.d.). O*NET OnLine. https://www.onetonline.org/
- European Commission. (n.d.). ESCO: European Skills, Competences, Qualifications and Occupations. https://esco.ec.europa.eu/en
- Lightcast. (2024). Open Skills: An open-source library of skills. https://lightcast.io/open-skills
- Kruger, J., & Dunning, D. (1999). Unskilled and unaware of it: How difficulties in recognizing one’s own incompetence lead to inflated self-assessments. Journal of Personality and Social Psychology, 77(6), 1121–1134. https://doi.org/10.1037/0022-3514.77.6.1121
