This is Part 3, the final post in the series on building a skills-based organization. Part 1 covered what skills-based means and why I think it matters; Part 2 walked through the components.
Now the hardest part: actually trying to build it. Thinking up ideas can be easy. Doing it without trying to do everything everywhere all at once, and without losing your leadership’s patience, is where it gets challenging.
If you’ve read the first two parts, you might be feeling the thing I felt when I first mapped out the full picture: this is enormous. Where do I even start? A taxonomy, competency mapping, assessment, mobility pathways, AI. Honestly, that’s how I ended up writing this series in the first place, trying to make sense of it for myself and, I hope, helping to sketch out a system you can use.
It can feel like a multi-year program, and most of us don’t have a multi-year mandate or a dedicated team.
Here’s the reframe that helps me think it’s doable: you don’t have to build a skills-based organization all at once. You can build a skills-based something, one role family, one critical workflow, one painful gap, and prove it works before you scale it. My sense is that the efforts that struggle are often the ones that try to map ten thousand skills across the whole company in year one. The ones that work seem to pick one place to start and prove it there.
So this post is the playbook I’d want to hand to anyone starting that work.
Step 1: Start With a Business Problem, Not a Skills Project
The biggest mistake I think people make is leading with the framework. Nobody in the C-suite wants to fund “a skills taxonomy.” They want to fund solving a problem they already lose sleep over.
So I’d start there. Find the place where the absence of skills infrastructure is actively costing the business something, and frame your work as the fix. A few patterns that tend to resonate with the groups you’ll need on board:
Maybe you have a critical role you can never fill fast enough, where every vacancy costs you in overtime, contractor spend, or lost revenue. Skills-based mobility could be your pitch: we may have people a skill or two away from this role, and we might be able to develop them faster than we can hire. Maybe you have brutal turnover in a specific population and exit interviews that all say “no path to grow.” Skills-based pathways could be your pitch. Maybe a major change is coming, like a new system, a new line of business, or an AI rollout, and leadership knows the workforce isn’t ready. A skills gap analysis could be your pitch.
The discipline here is the same one I rely on for any L&D initiative, and the same one I wrote about in “Just Build a Course”: start from the business outcome and work backward. Skills-based is the how. The business problem is the why, and in my experience the why is what tends to get funded.
Lead with the framework and I think you’ll often get a polite nod and no budget. Lead with the problem the framework solves and you have a much better shot at a pilot. So much of it comes down to your pitch and the story you tell.
Step 2: Pick a Pilot Narrow Enough to Actually Finish
Once you have a problem, I’d scope a pilot you can realistically complete in a quarter or two, rather than a program you’ll be apologizing for in eighteen months.
A good pilot, as I think about it, is one role family or one career pathway. Pick the critical role from Step 1, plus the one or two roles that feed into it. That’s maybe three to five roles and a few dozen skills, small enough to map carefully, big enough to prove the concept. You’re not trying to cover the org. You’re trying to create one clear success story.
Let me make that concrete with something I lived through. A while back, my team rolled out a new way of logging a particular action at work. During the pilot, we asked employees to record it both on paper and electronically until we could verify the digital records were accurate. Even though they were already used to logging the information on paper, doing both at once was a real strain. Now imagine we’d pushed that to the entire company on day one. It would have been painful for everyone, all at the same time, and the grumbling alone might have sunk it. Because we piloted it instead, only one group was temporarily inconvenienced while we confirmed it actually worked. By the time we expanded, we had proof and a much easier sell.
That’s really what a pilot buys you. You walk the components from Part 2, just at small scale: build a mini-taxonomy for those few roles, map them to skills and proficiency levels, assess the people in the feeder roles (self-assessment plus manager validation is plenty to start), find the gaps, and build targeted development to close them. Then you move a person or two along the path and write down what happens. Time-to-fill before and after. Development cost versus the cost of an outside hire. What the employees actually said. That record is how you turn “skills-based sounds nice” into “here’s what skills-based did for us.”
Step 3: Earn Buy-In From Three Different Audiences
I don’t think skills-based survives without buy-in, and the mistake I see is pitching everyone the same way. You really have three audiences, and they tend to care about pretty different things.
Executives care about business outcomes and risk, so I’d speak in the terms they already use: time-to-fill, attrition, workforce readiness, cost avoidance, return on the investment. Bring the numbers and tie everything to a strategic priority they’ve already named. Don’t explain the taxonomy. Show the result.
Managers are where I think a lot of rollouts quietly stall, because skills-based asks them to do real work: validating assessments, having development conversations, supporting people who move out of their teams. If managers experience this as extra admin with no payoff, they’ll nod in the meeting and quietly ignore it. So I’d try to make it worth their while by showing them, with a real example, how skills visibility helps them: better hiring into their own team, a clearer case for headcount, less guesswork in development conversations. One caution I’d give myself here is to set realistic expectations. Don’t oversell it as an instant win, because the first time a manager doesn’t get the result they were promised, they’ll hold it against you and you’ll lose the buy-in you worked for. And I’d try to protect managers from the “my best person left for another team” problem by making internal mobility something leadership visibly rewards.
Employees need to trust it, and just like with managers, that trust is fragile. Companies talk about change all the time, and too often those changes mean more work and new headaches without employees ever seeing the benefit. That’s exactly why the pilot story above matters: by inconveniencing one small group instead of everyone, we earned trust before we asked for scale. The first time someone games a self-assessment with no consequence, or gets assessed into a box they can’t climb out of, word travels. I’d be transparent about how assessment data is used, and make sure it’s used for development, not punishment. The moment employees believe a skills assessment is really a performance review in disguise, I think honest data starts to disappear.
Executives fund it, employees populate it, but managers are where I think it lives or dies. If the people doing the validating and the development conversations aren’t bought in, you may not have a skills-based organization so much as a database.
Step 4: Measure What Actually Proves Value
Remember the stat from Part 1, that only 8% of L&D professionals are confident they can measure the business impact of learning.1 I’d really try not to become part of that statistic with your skills work. Decide what success looks like before you start, and figure out how you’ll measure it.
And if you don’t have good data today, my advice is simple: start recording something, and record a lot of it. At first you won’t know exactly what matters, but as you start looking at it, the signal tends to surface. You’ll learn what’s worth tracking, refine from there, and build. This, to me, is a big part of what moves L&D from being seen as an expense to being seen as a value-add, something I’ve written about before.
I tend to think about it in three layers. Activity metrics tell you the thing is happening at all: skills mapped, employees assessed, development plans active. They’re necessary but they don’t prove much on their own, so I wouldn’t present them as the headline. Outcome metrics are where I think the real story lives: internal-fill rate, time-to-fill for the pilot roles, percentage of skill gaps closed, retention in the target population, internal mobility rate. Business-impact metrics are the ones executives actually feel: cost saved versus external hiring, productivity or quality gains, reduced contractor spend, revenue protected by filling a critical role faster.
The trap, I think, is drowning leadership in activity metrics because they’re the easiest to collect. “We mapped 4,000 skills” isn’t really an accomplishment; it’s an input. “We cut time-to-fill for our hardest role from 90 days to 35 and saved six figures in contractor costs” is an accomplishment. I’d always try to lead with the layer your audience feels.
Step 5: Treat It as a Living System, Not a Project
The last shift is the one I find hardest to internalize: skills-based doesn’t really have a finish line. Skills change, roles change, your business changes. A taxonomy you build and walk away from gets stale within a year. Assessment data you collect once and never refresh starts to drift from reality. The efforts that seem to last build maintenance into the model from day one: a cadence for reviewing the taxonomy, a rhythm for re-assessment, and an owner who keeps it alive.
This is part of why I keep coming back to the idea that skills-based belongs to L&D as much as HR. We’re the function that already thinks in terms of continuous improvement, iteration, and keeping content current. A living skills system is, in a way, just that discipline applied to the whole workforce.
The Mistakes I’d Try to Avoid
Let me try to save you some pain. These are the failure patterns I’ve seen most often.
Trying to do it all at once. Mapping the entire organization in one go. From what I’ve seen, it tends to collapse under its own weight before it produces a single result. I’ll be honest, I’ve fallen into this one myself, and had to step back and ask how I could narrow the scope to actually get the work done. Start narrow.
Buying a platform and calling it a strategy. A skills tool is plumbing. It doesn’t define your skills, validate your data, build your pathways, or earn your buy-in. Tools can accelerate a strategy; I don’t think they replace one. Early on, you may be better off starting with a spreadsheet or something you already have than spending big on another tool.
Letting it become HR’s secret project. If skills-based lives in an HR system that managers and employees never touch, I think it becomes a compliance exercise rather than an operating model. It has to show up in the actual flow of work. You also need feedback from the people it affects. Too often these efforts become siloed, and that’s a fast track to failure. Communicate, early and often.
Confusing self-assessment with truth. I covered this in Part 2, but it’s worth repeating because it seems so common: unvalidated self-ratings driving real decisions is, I think, how you erode trust in the whole system.
Skipping the “what’s in it for me.” If employees and managers can’t see a personal benefit, you’re leaning on compliance, and compliance tends to produce minimum-effort, low-quality data.
Measuring activity instead of impact. Counting what’s easy instead of proving what matters. In practice that looks like a report full of how many skills you mapped and how many courses people completed, with nothing about whether roles got filled faster or people stayed longer. I think it’s how good skills work quietly loses funding despite doing real good.
Where This Leaves Us
Across this series I’ve tried to make three points. That skills-based may be one of the most significant shifts in how organizations think about talent since eLearning. That it’s a real, buildable practice, not just a buzzword, made of taxonomy, mapping, assessment, mobility, and AI. And that the gap between talking about it and building it is large, which is part of why I think it’s an opportunity for the people willing to do the work.
That last point is the one I want to leave you with. The fact that fewer than one in five organizations have meaningfully done this isn’t discouraging to me; in a way, it’s the whole point.2 I think the early movers will have a real advantage in how they hire, develop, and retain people. And L&D, the function that has quietly held a lot of the relevant skills all along, like needs analysis, instructional design, assessment, and measurement, is in a strong position to help lead.
You don’t need permission to start. You need one business problem, one narrow pilot, and the discipline to prove it before you scale it. From what I’ve seen, that’s how most big shifts in our field actually happen, not with a mandate from on high, but with someone deciding to build the first small thing well.
I don’t think the skills-based organization is coming. I think it’s already here, just unevenly distributed. The question I keep asking myself is whether I’ll be someone who helped build it, or someone who spent two years talking about it.
That’s the series. If you’re starting this work, or stuck in the middle of it, I’d genuinely like to hear where you are. Find me on LinkedIn and let’s compare notes. And if this series was useful, the best thing you can do is share it with the one person in your org who keeps saying “we should really get skills-based.”
References
- TalentLMS. (2026). The 2026 L&D report: The state of workplace learning. https://www.talentlms.com/research/learning-development-report-2026
- Deloitte. (2025). Skills-based organisations: Looking back to move ahead. Deloitte Netherlands Consulting. https://www.deloitte.com/nl/en/services/consulting/perspectives/skillsbased-organisations.html
