Before Building a Skills Strategy, Decide What Problem You're Trying to Solve

Skills have become one of the most discussed topics in HR. Whether the conversation is about internal mobility, workforce planning, AI, learning, or talent marketplaces, skills almost always find their way into the discussion. It's easy to see why. Organizations are changing quickly, roles continue to evolve, and traditional job descriptions no longer capture everything people can contribute.

At the same time, I've noticed that many organizations start in exactly the same place: they begin building a skills framework.

The more I think about it, the more I wonder whether that's the right starting point.

Defining skills is relatively straightforward. The difficult part is deciding how those skills will actually be used. Will they support hiring? Internal mobility? Learning? Workforce planning? Succession? Career development? The answer matters because each of those decisions requires a different level of detail, different governance, and often a different way of thinking about skills altogether.

I've seen organizations invest a tremendous amount of effort creating comprehensive skills libraries only to discover that very few HR processes actually depend on them. The work itself isn't wasted, but it often happens in isolation. A skills framework becomes another repository that sits alongside job profiles, competency models, and learning catalogs instead of becoming part of how the organization operates.

I think that's because skills rarely create value on their own.

Their value comes from improving decisions.

If managers are expected to make internal mobility decisions, skills should help them identify employees who could be successful in a different role. If workforce planning is the priority, skills should help the organization understand which capabilities are becoming more important and where future gaps are likely to emerge. If the objective is learning, then skills should help employees understand where to focus their development and give leaders a clearer picture of organizational capability.

The framework itself is only one part of the equation.

Another challenge is that skills don't remain static for very long. New technologies emerge, roles change, and organizations evolve. Skills that were highly relevant a few years ago may become less important, while entirely new capabilities appear almost overnight. Maintaining that information requires ownership, governance, and ongoing decisions about how the framework evolves. Without that discipline, even the best-designed skills library gradually becomes less useful.

This is also where I think job architecture plays a much bigger role than it's often given credit for. Skills don't exist independently from work. They become meaningful when they're connected to roles, career paths, and business capabilities. Without that context, it's difficult to understand how a skill should influence hiring, development, mobility, or workforce planning. Defining skills before establishing a consistent way to describe work often creates more complexity than clarity.

Technology is making this conversation even more relevant. AI can help infer skills, identify relationships between them, and recommend learning or career opportunities much faster than we could a few years ago. But the technology still depends on the decisions organizations make about what those skills represent, how they're defined, and how they should be used. AI can process information at scale. It can't establish the business context that gives that information meaning.

Perhaps that's why I think the conversation around skills should begin somewhere else. Before asking how to build a skills strategy, organizations should first decide which decisions they want skills to improve. Everything else—the framework, the technology, the governance, and even AI—becomes much easier to design once that purpose is clear.