Skills data is broken. But not for the reason you think

Most organisations don't have a reliable picture of what their workforce can actually do. Skills data is incomplete, outdated, and the people who act on it rarely trust it. Strategic decisions get made on guesswork. Internal talent goes unrecognised. Learning and development investment flows toward problems that may not exist, or away from ones that do.

This is not a controversial observation. According to Gartner, only 8% of organisations have reliable data on the skills their workforce currently possesses. Eight percent. The other 92% are operating in something close to a fog.

The question is why. And more importantly – what actually fixes it.

The prescription the industry keeps writing

The dominant answer, increasingly, is better technology. Specifically: AI inference engines that derive skills signals from existing work systems – emails, project tools, performance histories, learning platforms, job architectures. The logic is clean. If people produce unreliable skills data, the solution is to collect it without asking them. Remove the human variable. Let the system observe behaviour and infer capability.

This approach has genuine analytical credibility behind it. It produces sophisticated outputs. It integrates with the enterprise HR platforms that large organisations already run. And it feels like a serious answer to a serious problem.

But it skips a step; a significant one.

The question nobody is asking

Before accepting that self-reported skills data is unreliable by nature, it's worth asking why it's unreliable. Not as a rhetorical move – as a genuine investigative question.

Here is what makes that question interesting. According to Deloitte's research into skills-based organisations, 79% of employees say they are open to sharing their skills data. Seventy-three percent say skills-based practices would improve their experience at work. The willingness is there. Employees are not, as a rule, hiding or resistant.

Yet only 8% of organisations have reliable skills data.

That gap – between employee willingness and organisational data quality – is worth examining carefully. It points somewhere different than "we need better inference technology." It is the relationship between the human and the tool that is broken – not the human.

What is actually going wrong

There are three specific reasons self-reported skills data fails – at least, these are the ones we keep seeing. None of them are human nature.

The first is that most skills tools are built to serve the organisation, not the employee. They are data capture systems. The employee is the input. There is no visible return – no career clarity, no signal about how their profile affects the work they get matched to, no picture of their own growth path. The rational response to a tool that takes from you and gives nothing back is to do the minimum, or nothing at all.

The second is the absence of social accountability. When a skills profile sits inside an HR system that only HR can see, there is no natural mechanism for self-correction. You can claim expert status in anything. You can leave a profile untouched for a year. Not because people are dishonest, but because honesty has no structural support. There is no consequence to inflation and no reward for accuracy.

The third is that the experience of completing a skills profile has historically been designed for compliance, not engagement. Long taxonomies. Clunky interfaces. No immediate feedback. Skills tools have been built the way expense forms are built – something to be endured, processed, and forgotten.

Fix these three things and the human stops being the problem. And for those who remain sceptical – yes, some people will still inflate. But consider the ceiling on that error. Someone who overstates their Python skills works alongside people who can see them work. The gap becomes visible. The data self-corrects. Compare that to inference errors, which arrive dressed as objective fact, carry no social accountability, and compound quietly over time. The question was never whether self-reported data is perfect. It is whether its errors are the kind you can see and fix – or the kind you can't.

Skills tools have been built the way expense forms are built — something to be endured, processed, and forgotten.

There is a fourth issue – one specific to inference-based approaches – that deserves its own examination.

AI inference works by scanning signals from existing systems: email activity, project tools, learning platforms, job histories, performance records. The implicit assumption is that what is observable in systems reflects what people actually know and can do. It does not.

Here is what inference cannot see. A new employee who joined three months ago has no data trail yet – the system has nothing to infer from. Certifications earned before joining, or outside company systems, stay invisible unless someone manually uploads them. Soft skills, relationship-based judgment, the ability to read a room or navigate a difficult stakeholder – none of this leaves a system trace. Skills that exist but are not currently being used generate no signal at all.

But the sharpest illustration is what inference concludes about two product managers of very different ability. The inexperienced one is highly active in systems. They are firefighting constantly – sending more messages, creating more tickets, logging more issues, communicating more frequently because they are communicating incorrectly and then correcting it. The experienced one does most of their work through conversation, judgment, and relationships. Problems are resolved before they reach the system. They generate less data, not more. An inference engine trained on system activity would likely conclude that the junior product manager has stronger product management skills. It has observed more product management. It has observed the wrong thing.

The talent that leaves the least trace in your systems is often your most expert – because expertise changes the nature of how work gets done.

This is not a calibration problem that better algorithms will fix. It is a structural flaw. The most experienced people in any organisation are often the least legible to systems – precisely because expertise means spending less time fighting fires that show up as data. Some inference systems attempt to address this by pushing suggested skills to employees or managers for validation – a human check on the machine's conclusions. That is a reasonable patch. But it is still asking a human to correct a system that started from the wrong signal. The foundation has not changed.

This has a consequence that most organisations don't anticipate. When you rely on inference to surface capability, you don't just miss what people can do – you systematically underestimate it. The skills that are hardest to observe are often the most valuable. The talent that leaves the least trace in your systems is often your most expert – because expertise changes the nature of how work gets done.

The clearest proof is in the numbers

The most sophisticated inference-based skills systems – deeply integrated with enterprise HR platforms, built on exactly the logic described above – are not solving the adoption problem. Enterprise HR technology adoption rates rarely exceed 20%. The technology functions as designed. The data problem it was meant to solve remains. Because the relationship between employee and system was never fixed, it was engineered around. And engineering around a broken foundation is not the same as fixing it.

Two deployments illustrate what a different foundation produces.

Höegh Autoliners is a global shipping company that runs a highly distributed workforce across vessels, ports, and offices worldwide. When they deployed MuchSkills, they built around the employee-first principle: every employee could see their own skills profile clearly, map themselves against roles they aspired to, and understand the gap between where they were and where they wanted to go. The organisation did not mandate continuous updating – it designed a tool that made updating worth doing. The result was over 90% active adoption across the workforce, sustained over time, in an industry not historically associated with digital enthusiasm. Their skills data is now accurate enough, and trusted enough, to sit in their annual board-level strategy reporting. The board uses it to ask – and answer – whether the organisation has the capabilities to execute on its plans.

Scale proves something different. In late 2025, MuchSkills provided the technology platform for Project PASGA – the Nigerian Federal Government's Personnel Audit and Skills Gap Analysis, delivered on the ground by Phillips Consulting. Nearly 55,000 civil servants across 46 ministries completed a structured skills assessment in three months: 5.1 million skill entries, 4,800 certifications, 19,000 development goals. Average skills recorded per employee: 70. This was a government programme – participation was expected. And yet employees went well beyond the minimum. They set development goals nobody had asked them to set, recorded certifications unprompted, explored features they had never been directed to use. In a civil service of 55,000 people, that does not come from a mandate. It comes from a design that made participation feel worthwhile. One finding from the data stayed with us: skill levels across the workforce were significantly higher than leaders had assumed. Capabilities that had been invisible to the organisation – and to the employees themselves – became visible for the first time when people were given a well-designed way to represent what they actually knew. The problem was never that capability was absent. It was that the methods used to surface it could only see a fraction of what was there.

The difference between sub-20% and 90%+ sustained adoption is not the sophistication of the underlying technology. It is the answer to a prior question: whose tool is this, and who does it serve?

What fixing it looks like

If the problem is design and incentives, the solution looks different too.

Peer visibility functions as a data quality mechanism, not a social feature. When skills profiles are visible to colleagues, self-correction happens naturally. Nobody claims expert status next to a genuine expert. Nobody lets a profile go stale when peers can see it. Independent research across 27,000 employees validates this. Transparency, it turns out, is the most reliable data quality mechanism available — not because it monitors people, but because it removes the conditions under which inaccuracy is comfortable. It is the founding principle behind the MuchSkills methodology.

Capturing motivation alongside capability changes the incentive structure entirely. If a platform records not just what someone can do but what they want to do – the work they find meaningful, the skills they want to develop – then completing a profile is no longer an act of compliance. It is an act of self-advocacy. The employee has skin in the game. Accuracy stops being a favour to the organisation and starts being a service to themselves.

Design that earns adoption rather than demanding it matters more than it sounds. A proficiency scale that takes 15 to 30 minutes to complete, feels honest rather than bureaucratic, and immediately shows employees their own value – their skills relative to the roles they care about, the gaps they might want to close – produces a different kind of engagement. Not because of change management programmes or mandatory completion targets. Because the product deserves it.

The result, when all three are working together, is skills data that is continuously updated not because employees are instructed to update it, but because they want to. That is a fundamentally different foundation to build on.

The deeper philosophical difference

The gap between these two approaches is not really about methodology. It is about who skills data belongs to and who it is designed to serve first.

The dominant framework treats skills as organisational assets. They are to be captured, governed, taxonomised, and integrated into HR systems. The employee is the source. The organisation is the owner. All design effort goes into making capture more efficient and inference more accurate. The employee barely figures in the product experience at all.

You cannot infer your way to data that was never there.

Reverse that relationship and something fundamental changes. When the platform serves the employee first – when it shows them their own capabilities clearly, signals the work they are best placed to do, and reflects back the growth they are achieving – accurate and current data becomes a natural byproduct of their own interest in maintaining it. You do not need to engineer around the human. The human becomes your most motivated and most reliable data source.

This is not a soft claim about culture or values. It is a product design argument with measurable consequences for data quality and adoption. The 79% of employees who say they are willing to share their skills data are not the problem. The question is whether the tools they are given make that willingness worth acting on.

A different starting question

Technology built on the wrong human foundation will always underperform technology built on the right one. The 92% of organisations still without reliable skills intelligence are not all lacking access to better inference engines. Many already have them. What they are missing is a different starting question.

The industry asks: how do we get better skills data?

The more useful question is: why would an employee give us accurate skills data in the first place?

Answer that differently – through design, through transparency, through tools that genuinely serve the person completing them – and everything that follows changes. The data improves. Adoption follows. And the gap between what organisations think their workforce can do and what it actually can do starts, at last, to close.

None of this argues against AI in skills intelligence. AI inference layered on top of high-quality, employee-generated data is a powerful combination. The problem is that most organisations are trying to skip the foundation and go straight to the layer on top. You cannot infer your way to data that was never there.

More technology is not always the answer. Sometimes it is a design problem.

If the argument in this piece resonates, it is because MuchSkills was built on exactly this foundation — employee first, organisation second. Book a demo to see what skills data looks like when the design is right. Or explore the platform and see for yourself.

Frequently asked questions

Isn't AI inference more objective than asking employees to rate themselves?

Inference-based systems appear more objective because they remove the employee from data collection. But they inherit the biases already embedded in the systems they draw signals from – job titles, email patterns, project histories. These reflect what employees have been assigned to do, not necessarily what they are capable of doing or want to do next. Self-reported data, when collected through a well-designed system with social accountability built in, captures a different and often more useful signal: what employees know they can do and are motivated to contribute.

What stops employees from inflating their skills even on a well-designed platform? 

The primary check is peer visibility. When skills profiles are visible to colleagues, claiming expert status in a skill that peers can evaluate is socially uncomfortable in a way that a private HR database is not. Independent research across 27,000 employees found that transparency significantly reduces inflation – not because people are monitored, but because the social context changes the calculation. People are generally more honest when their claims can be seen and assessed by people who know their work.

Does employee-first design mean the organisation loses control of its skills data?

No – it means the organisation gets better data as a result of ceding the pretence of control. When employees own their profiles and find them genuinely useful, they keep them current without being asked. The organisation ends up with a more accurate, more complete, and more trusted picture of workforce capability than any mandated capture system typically produces. Control over data entry does not produce data quality. The right incentive structure does.

How often should skills data be updated? 

In most organisations, annual skills reviews produce data that is already outdated by the time decisions are made against it. The more useful question is what makes employees want to update their profiles continuously: when updating serves them directly. If a skills profile affects the projects someone gets matched to, the development opportunities surfaced to them, or how their growth is visible to their manager, it stays current naturally. Mandatory update cycles are a workaround for a platform that hasn't earned ongoing engagement.

What about AI that infers skills from CVs and performance reviews rather than live system activity? 

Some inference approaches draw from structured documents – CVs, performance reviews, recruiting databases, completed training records – rather than live work system behaviour. The data sources differ but the core limitation is the same: inference can only surface what is already documented. A senior product manager whose expertise is exercised through judgment, relationships, and preventing problems before they arise will be under-documented in both approaches. Their CV reflects their title and tenure. Their performance review reflects what their manager noticed. Neither captures capability that never needed to be written down because it was already working. The inference engine reads what exists. What is most valuable is often what leaves the least trace.

‍