Everyone agrees on the four workstreams
Ask an analyst, a consultancy or an experienced CHRO how to build a skills strategy and you will get back the same four workstreams: identify the skills that matter, manage them as a system, develop them, then acquire and mobilise against them. Every published roadmap runs each workstream from initial activities toward more advanced ones. They differ in wording and almost never in shape.
The shape is right. We would not argue with any of the four. What is worth arguing about is the order inside them, because that is where organisations lose eighteen months.
A skills taxonomy nobody has verified is an org chart with better vocabulary. It looks like progress and it decides nothing.
In most roadmaps, "set your validation strategy" sits well along the maturity axis — something you arrive at after the taxonomy exists, the platform is bought and the programmes are running. That sequencing is the single most expensive convention in the category, and this piece is about why, workstream by workstream.
Where skills programmes actually die
Follow the conventional sequence and here is what happens. You spend two quarters building a taxonomy. You load it with skills data — self-assessments, manager ratings, inferred signals from profiles and job titles. You stand up dashboards. Leadership starts looking at coverage percentages. Somebody proposes a redeployment based on them.
Then a business unit head says the sentence that ends the programme: "I don't believe this data."
And they are right not to. Nothing in that pipeline established that anyone can actually do anything. Every number in it traces back to a claim — a person's own rating of themselves, a manager's impression, a model's guess from a job title. The dashboard is precise and entirely unfounded, and once trust goes, it does not come back by adding a filter.
Identify: start from capability, not from a skills list
The first workstream asks which skills actually differentiate the business, then works down from business capabilities to workforce capabilities to jobs and skills, and finally to a build-buy-borrow plan.
The part organisations get wrong is starting at the bottom. Someone exports a skills library, sends a survey, and ends up with eleven thousand skills, of which perhaps forty matter to anything the company is trying to do. Breadth is cheap and almost worthless. The work is the chain — this business capability requires this workforce capability, which decomposes into these jobs, which require these skills at these levels.
On our side this is the job architecture layer: roles, levels and competencies mapped against a skills graph of roughly thirty-four thousand skills, with a job description resolving against the graph rather than sitting beside it as prose. The graph is the vocabulary; the architecture is the part that makes it mean something. A required skill is attached to a role at a level, so "the gap" is a measured distance rather than an adjective.
Manage: the inference trap
The second workstream covers owning the taxonomy, choosing the technology, setting a validation strategy and governing the whole thing as it drifts. Three of those four we would sign without amendment.
The disagreement is about inference. The common recommendation is to build a stack that can infer skills — derive them from profiles, job titles, project history, adjacency to other skills — and treat that inference as intelligence. It is an understandable recommendation, because inference is the only way to get coverage quickly. We think it is the wrong trade, and we have built against it deliberately.
Our position is that inference can populate a question but never an answer. A skill becomes real on a GoMeasure record when something established it: an adaptive assessment, an AI interview that probed the reasoning, a work simulation, a coding exercise, a structured peer review, or real work evidence. And it carries its provenance permanently — the source that established it, the method used, the date it happened, and whether the session was monitored.
That is also what makes "set your validation strategy" the wrong thing to defer. Validation is not a feature you switch on at maturity level four. It is the property that makes every other number in the system worth looking at.
Governance, concretely
Two mechanisms do most of the governance work in practice. The first is expiry: a verified skill carries a re-verification date, so the system knows when a claim has aged past the point of being trustworthy instead of silently carrying 2023 evidence into a 2026 decision. The second is convergence: when several independent sources speak to the same skill, they are reconciled into one signal rather than stacked as four unrelated scores — and agreement between methods that fail differently counts for more than any single strong result.
Develop: against a named gap, and measure it afterwards
The third workstream is about aligning learning investment to strategic skills, building the delivery infrastructure, scaling it, and — the row most organisations never reach — tracking development against business outcomes.
Almost all of the difficulty is in that last part, and it is downstream of everything above. You cannot measure development against outcomes if you never established a starting point. The honest version of "we improved capability by 30%" requires a defensible before, a defensible after, and the same instrument at both ends. Most L&D reporting has none of the three, which is why it falls back on completion rates.
The loop we run is deliberately boring: measure, develop the specific named gap, then re-measure with comparable rigour. Our coaching agent works against a person's actual measured gaps rather than a generic curriculum, and our course builder takes a brief to a reviewed, published programme in a working session rather than two quarters — but neither of those is the point. The point is the re-measurement at the end, which turns a training spend into either evidence of improvement or evidence that the intervention did not work. Both are useful. A completion rate is neither.
Acquire and mobilise: the same record, pointed outward
The fourth workstream defines hiring needs by the skills that matter, establishes skills-based sourcing and assessment, and mobilises internal people against critical gaps.
This is where a validated record pays for itself, because hiring and mobility are the two places where a wrong call is expensive and visible. Our hiring and workforce layer reads the same record the development side writes to: shortlists built on proven skills rather than keyword matches, internal mobility that can show why an internal candidate is genuinely ready, and succession lists where "ready now" has evidence behind it.
The internal half is the one that gets skipped, and it is usually the cheaper half. Organisations run expensive external searches for capabilities they already have, because nobody can prove internally who has them. That is not a sourcing problem. It is a validation problem wearing a sourcing costume.
We also run this upstream of employment entirely — GoMeasure Campus applies the same measurement to students from their first semester, so a graduate arrives with a record rather than a résumé. If a skills-based organisation is the goal, the pipeline into it may as well be skills-based too.
What is proven, and what is early
The same honesty we are asking for in the data, applied to our own roadmap.
In production: the skills graph and job architecture, adaptive assessment, AI interviews, integrity and proctoring, the hiring, mobility and succession layer, coaching, the course builder, the AI-era capability batteries, multi-tenant delivery, and the compliance posture a security review can be pointed at.
Early access: capability established from real work signals rather than from an exercise. The foundations are shipped — evidence-anchored scoring, a provenance ledger, skill attribution — and the first connectors are running in pilot. The full picture of a workforce measured continuously from its own work is in progress, and we would rather say so than let it sit in a feature grid.
Not on our roadmap at all: presenting an inferred skill as a verified one. If we cannot say what established a skill, we will not show it as established.
Where to start on Monday
If you are at the beginning of this, the sequence we would argue for is narrower and less satisfying than a full roadmap, and it is far more likely to survive contact with a sceptical business unit.
- Pick one critical capability, not a taxonomy. The one where being wrong costs you most this year.
- Decompose it properly — business capability to workforce capability to jobs to skills at levels. Resist the urge to widen.
- Validate it for one population. One department, one job family. Real measurement, provenance attached.
- Make one real decision on it and let people watch — a redeployment, a hiring profile change, a development investment with a measured before.
- Re-measure after the intervention. This is the step that converts a pilot into a mandate, and it is the step that gets cut.
- Then widen, with the credibility you earned rather than the credibility you assumed.
If you want to see where your organisation currently sits against this, the Skills Readiness Diagnostic places you on a claim-to-proof maturity scale in about five minutes. The Proof Engine explains how the verification itself works, the skills graph covers the structural layer this all sits on, and Completed is not capable makes the same argument from the development side.
The whitepaper, the playbooks and new research — by email.
Skills intelligence for HR and business leaders. We'll send the “Jobs to Skills” whitepaper and share new frameworks as we publish them. No noise.
One email now, occasional research later. Unsubscribe anytime.