The business does not speak skills

The Translation Problem Nobody Talks About

In 2019, a global consumer goods company launched an ambitious skills-based transformation. The CHRO hired a team of six taxonomists, licensed a leading skills library, and spent fourteen months cataloging over 4,200 distinct skills across the organization. The project was celebrated at an internal HR conference. Posters went up. A newsletter was sent.

Two years later, the CEO asked a simple question during a quarterly business review: “Do we have the people we need to hit our supply chain automation targets next year?” Nobody in the room could answer. The skills taxonomy, meticulously maintained in a standalone system, had no connection to the supply chain roadmap, the capital expenditure plan, or the automation vendor’s implementation timeline.

Priya Narayanan, who led workforce planning at the company, later described the moment as “the day we realized we had been talking to ourselves.”

This is not an isolated story. It is the central failure mode of skills-based transformation as practiced over the past decade.

HR Speaks Skills. The Business Speaks Work.

The fundamental disconnect is linguistic. HR teams have adopted “skills” as the atomic unit of workforce strategy. Business leaders have not. When a VP of Engineering thinks about next quarter, she thinks about shipping features, reducing incident response time, or migrating to a new cloud provider. She thinks about work.

When a plant manager plans for a new production line, he thinks about throughput, defect rates, and shift coverage. He thinks about outcomes.

Neither of them wakes up thinking, “I need 14 more people with the skill labeled SC-2847: Advanced Predictive Maintenance Methodology.” They think about what needs to get done and whether they have enough of the right people to do it.

The table below illustrates how the same workforce challenge gets framed in fundamentally different terms depending on who is speaking:

The pattern is consistent. Business leaders frame problems in terms of deadlines, locations, financial impact, and specific initiatives. HR frames the same problems in terms of skill categories, proficiency levels, and population statistics. Both are describing the same reality, but neither framing translates cleanly into the other.

The Taxonomy Maintenance Nightmare

Even setting aside the language gap, there is a practical problem with how most organizations have approached skills: the taxonomy itself becomes an operational burden that compounds over time.

Marcus Johansson, a workforce analytics director at a Nordic bank, described his team’s experience this way: “We started with 1,800 skills. Within two years we had 3,400. Every business unit wanted their own additions. Every merger brought another taxonomy to reconcile. We had two full-time people whose entire job was taxonomy governance, and we were still falling behind.”

This is the taxonomy maintenance problem, and it follows a predictable pattern:

1. Initial build. The organization invests significant effort to create a comprehensive skills taxonomy, often licensing a third-party library as a starting point.
2. Customization pressure. Business units and functional leaders request additions, modifications, and context-specific skills that the base library does not cover.
3. Proliferation. The taxonomy grows rapidly. Duplicate and near-duplicate entries appear. “Data Analysis,” “Data Analytics,” and “Analytical Data Skills” coexist without clear differentiation.
4. Governance overhead. A governance process is established to manage changes, but it slows down responsiveness and frustrates business stakeholders who need new skills reflected quickly.
5. Drift. The taxonomy gradually falls out of alignment with actual work. New technologies, new methodologies, and new business models outpace the governance cycle. By the time a skill is formally added, it may already be commoditized.
6. Abandonment. Stakeholders lose confidence in the taxonomy’s accuracy. Adoption declines. The taxonomy becomes an artifact maintained by a small team but referenced by almost nobody.

This cycle plays out over three to five years in most organizations. The investment is significant. The return is marginal.

The Atomic Unit Problem

Beneath the maintenance challenge lies a deeper conceptual issue: skills may not be the right atomic unit for workforce strategy in the first place.

Consider the skill “Python programming.” At what level of granularity is that useful? For a hiring manager building a data engineering team, “Python” is far too broad. She needs to know about experience with specific libraries (pandas, PySpark, Airflow), familiarity with particular architectural patterns (event-driven pipelines, batch processing), and comfort with specific infrastructure (Kubernetes, AWS Glue). “Python” as a skill tells her almost nothing.

For a workforce planner looking at the entire technology function, “Python” might be too narrow. She needs to understand whether the organization has sufficient programming capability across multiple languages and paradigms, not whether any single language is adequately represented.

This is the atomic unit problem: the right level of granularity depends entirely on the question being asked, and no single taxonomy can serve all questions equally well.

No single row in that table is wrong. Each level serves a legitimate purpose. The problem is that traditional taxonomies force organizations to pick a level and maintain it uniformly, when what the business actually needs is the ability to zoom in and out fluidly depending on context.

What the Business Actually Needs

When business leaders ask workforce questions, they are rarely asking about skills in isolation. They are asking compound questions that blend capability, capacity, timing, geography, cost, and risk:

• “Can we deliver the SAP migration on time with the people we have, or do we need to bring in contractors?”
• “If we acquire that company in Brazil, how much overlap do we have in R&D capability, and where are the gaps?”
• “Which three facilities are best positioned to adopt the new robotics platform first?”

These questions require skills data, yes, but they also require organizational data, financial data, project timelines, location information, and labor market intelligence. Skills are one input among many. Treating them as the primary lens through which all workforce decisions flow overweights one dimension and underweights everything else.

Fatima El-Amin, a workforce strategy consultant who has advised over 40 enterprises on skills initiatives, summarized it bluntly: “The companies that treated skills as the destination got stuck. The companies that treated skills as one ingredient in a larger intelligence capability moved forward.”

Closing the Gap

The path forward is not to abandon skills. Skills data remains a critical input to workforce intelligence. The path forward is to stop expecting the business to learn HR’s language and instead build systems that translate skills into the language the business already speaks: work to be done, outcomes to be achieved, and risks to be managed.

That translation layer is what separates a skills taxonomy from genuine workforce intelligence. And building it requires a fundamentally different approach to how skills data is structured, maintained, and activated, which is exactly what the next two articles in this module will explore.