The skills pilot that tried to cover the entire organization
The pilot began with an understandable ambition: if skills were meant to serve the entire organization, it seemed more efficient to design a solution for everyone from the start. That decision turned a learning exercise into a program that could not get started.
This is a composite case. It brings together decisions and tensions common to change initiatives without describing a particular company or attributing real outcomes to a client.
The promise of solving the problem once and for all
The team wanted to avoid duplication. It therefore convened every area, included every role family, and opened a discussion about a shared architecture. The reasoning seemed sound: a complete foundation would make it possible to assess, develop, and mobilize talent using the same language.
A predictable difficulty emerged in the first sessions. Each area understood skill, level, and role differently. Some described knowledge; others described tasks; still others mixed tools, responsibilities, and personal attributes. Reconciling those differences became a prerequisite for any further progress.
The pilot stopped asking whether the approach helped make a concrete decision. It began asking how to build the definitive model.
Every answer expanded the project
When an exception emerged, the team added a rule. When two areas used different names, it opened a harmonization group. When a leader feared being left out, it added new roles. The architecture grew, but no one was yet using the results to make a decision.
The need for legitimacy also changed form. Instead of validating a small scope with experts close to the work, the team sought organization-wide approval. Every participant could challenge a definition even if they would not use it during the trial. Governance intended to protect consistency ended up giving people the power to block progress without making them equally accountable for the outcome.
Meanwhile, the simplest questions remained unanswered: how much time an assessment required, whether levels were interpreted similarly, what evidence leaders could provide, and what a person would receive at the end.
The project was busy, but the pilot was not learning
There were meetings, inventories, and documents. That activity could be mistaken for progress. A pilot, however, exists to reduce uncertainty about use, feasibility, and value. Until the process is tested with real users and applied to real decisions, it accumulates design work without producing learning.
Implementation literature distinguishes outcomes such as acceptability, adoption, appropriateness, and feasibility before sustainability. The taxonomy developed by Proctor and colleagues was created in health services, so it does not prove what should be measured in talent management. It does offer a useful distinction: implementing something produces outcomes of its own, different from the final effects the intervention seeks to achieve (Proctor et al., 2011 (opens in a new tab)).
The team in this case was trying to answer questions about scale and permanence without having answered the more immediate ones. It did not know whether users understood the language, could complete the task, or found the output useful.
The narrower scope that seemed like a concession
The correction was not to finish the inventory faster. It was to redefine what needed to be learned.
The team chose a track with an upcoming decision, leaders available to contribute evidence, and a manageable number of roles that shared the same skills. The rest of the catalog was left out, not because it lacked importance, but because it was unnecessary for testing the full process.
That reduction created political discomfort. Some areas interpreted nonparticipation as a loss of priority. The team had to explain that a pilot does not distribute final benefits: it buys the learning needed to decide whether, how, and under what conditions to scale.
The difference became visible when the first cohort completed the process. Doubts were no longer hypothetical. Some anchors worked; others mixed autonomy with complexity. Some leaders had sufficient evidence for certain elements and almost none for others. People valued the explanation of their result but needed greater clarity about the next step. For the first time, the remaining work was grounded in actual use.
The architecture changed after encountering reality
Question Which uncertainty the pilot must reduce.
Scope What is left out so the team can complete a real end-to-end process.
Signal Which evidence will determine whether to adjust, repeat, or scale.
The smaller scope did not eliminate the need for consistency. It made it possible to build consistency on observations. Rules that survived could be generalized on firmer ground; those specific to the track could be identified as local. Governance shifted from approving every definition to deciding what needed to be shared, who could change it, and what evidence justified the modification.
The World Economic Forum’s skills framework presents tools, practices, and enablers for moving toward skills-first approaches, but it also makes clear that adoption requires action from employers and the capability to implement, not just taxonomies (WEF, 2023 (opens in a new tab)). More recently, the OECD has warned that these approaches require organizational resources, robust assessments, monitoring, and HR processes; applying them is not a simple administrative substitution (OECD, 2025 (opens in a new tab)).
The original pilot set out to avoid rework. Instead, it postponed the only information that could reduce it. The second accepted that some decisions would be provisional and obtained evidence to improve them.
The organization did not leave the pilot with a complete architecture. It left with something more useful for that stage: a tested process, visible limits, and criteria for choosing the next scope. Scaling stopped meaning including everyone and began to mean reproducing learning without losing control.
Keep exploring
Generalists, specialists, and hybrid roles: what the architecture should decide
Does the organization need breadth, depth, or integration? Generalist, specialist, and hybrid are possible answers, not identities the architecture should fix permanently.
How to tell whether a skills-first initiative creates value after the pilot
To decide what comes after the pilot, examine which decisions changed, which outcomes followed, and what it costs to sustain the mechanism. Participation and coverage do not yet demonstrate value.
Not every critical skill is strategic: importance, scarcity, and advantage are not the same
Although importance, scarcity, and advantage are often compressed into the label “critical skill,” each dimension requires different evidence and investment. Separating them changes what must be protected, sourced, or built as a system.
What must remain common and what can vary across areas
Even when two areas work differently, they can still share an architecture. Adaptation stops being local when it changes meaning, comparability, or the rights attached to use.
Build, hire, move, partner, or automate: five responses to a capability gap
To choose among building, hiring, moving, partnering, or automating, compare the demand, the time horizon, and the dependencies each response creates.
When to split, merge, or retire a skill
Splitting, merging, and retiring a skill correct different failures. Even if the catalog looks tidier after the change, the choice depends on which distinction in the work must be preserved and which decisions will change.