I spent years building and selling HR tech. Now I help vendors and enterprises get workforce AI products to work in the real world. Here I write about people and work data as a product, why AI-native companies will need far more of it, and whether that’s a good thing.
Most HR tech vendors promise a path to the skills-based organisation, where people, work and learning are orchestrated to help the business create value for its customers, clients and shareholders. People leaders are understandably drawn towards the mid-term goals: better mobility, more cost-efficient resource allocation, lower hiring costs.
This is all good stuff, but most businesses start from a much lower level of maturity, with legacy systems, patchy data and fragmented taxonomies.
Simply put, even if a platform vendor is appointed to infer the likely skills of people, roles and archetypes, there is still a relatively long commitment involved in refining the skills language of the business and applying the labels appropriately to the real people in an organisation. It's real groundwork.
Why it stays theoretical
In theory the idea is compelling. Match people to work on capability rather than job title. Let people move across traditional boundaries. Deploy scarce expertise where it matters. Build resilience through visible, transferable skills. Reduce reliance on consultants, contractors and freelancers.
Where skills data actually lives
In practice, skills data tends to be spread across many systems (HRIS, LMS, performance tools, CVs, bios, LinkedIn, GitHub and so on) with inconsistent taxonomies and varying currency. Recruiting uses one skills framework, learning another, performance management a third set of competencies. Analytics tries to connect them and finds mostly noise.
It matters most for teams accountable for an outcome. A team responsible for "a fully staffed, capable workforce in region X" needs to know who it has, what they can do, where the gaps are and what is in progress. Recruiting knows who is being hired, learning knows who is in training and performance knows who is ready for new challenges, but the systems can't connect the dots.
Even within one system the questions multiply. Who decides what counts as a skill? Is "Python programming" one skill or twenty, depending on libraries, frameworks and use cases? Is "leadership" a skill or a cluster of separate capabilities? How do you verify that someone has a skill they claim?
Why keeping skills current is so hard
Skills change quickly, technical ones especially. A taxonomy built two years ago may already be out of date. But updating a taxonomy breaks historical data, disrupts matching and takes a lot of coordination.
Who owns skills architecture?
Recruiting could claim it, because they need it for hiring. Learning could, because they develop capability. IT could, because it runs the systems. Business units could, because they know which skills they need. Where several functions each have a claim, I'd expect nobody to run it systematically.
What has to happen before the platform
The platforms will match skills if they are given clean, structured data with a consistent taxonomy that is kept current. The foundational work, covering skills architecture, taxonomy governance, data quality and currency, has to happen before the platform is bought, not after. I think the skills-based organisation is a good destination, and the groundwork decides whether it is reachable. There are exceptional vendors now in the skills intelligence domain, some of whom we are partnering with to build the baseline with enterprises.
My bet is on less software with better data underneath it. Buying more systems and integrating later compounds complexity, because every platform adds IDs to reconcile, definitions to align and data to keep current.
