Five gates to clear before you buy
THE VERDICT
Most skills programmes don't fail on the platform. They fail because the platform was asked to answer a question the organisation never settled. Decide the architecture first. Buy the technology second. The tech is real, and it does things no spreadsheet ever will — it just has to work second.
Evidence base: First-hand — I led this decision inside a live organisation, including the part where we unplugged a capable platform we had already bought. For: HR, people-analytics, and skills leaders evaluating a skills-intelligence platform, or already living with one that isn't landing.
Where this started
I once spent part of a leadership meeting explaining why we needed to unplug a shiny platform we'd bought for skills intelligence. It was a good product. It was not a bad vendor. We had simply bought an answer before we had agreed on the question.
That is the pattern I see again and again. The platform is asked to resolve things that are not technical at all — what a skill is, who owns proficiency, what an employee is told the data is for. Those are decisions, not features. No vendor can make them for you, and every vendor quietly assumes you already have.
Architecture and platform are not the same object
Skills architecture — the decisions only you can make:
-What a skill is here, and at what granularity.
-Which decisions skills data may influence — and which it may not.
-Who owns proficiency, and how it is evidenced.
-How often the picture has to be true, and who refreshes it.
-What the employee experiences, and what they are told it is for.
Tech platform — capability you can buy repeatedly:
-Inference, matching, scale, refresh cadence.
-A starting taxonomy and market signal you don't already have.
-Workflow surfaces inside the tools people already open.
-Integration, permissions, audit.
-Speed — once the questions are settled.
Read those two lists back to back and the point makes itself: the first list is yours to decide, the second is yours to buy. Trouble starts when you buy the second hoping it will decide the first.
The five gates
01 — A named business outcome, with an owner. "Skills visibility" is not an outcome; it is a screenshot. A real outcome has a number, a date, and a business owner who will be asked about it whether or not the programme survives. Cut external hiring for these six roles by a quarter. Shorten redeployment from ninety days to thirty. If you can't name the person who owns that number — and they sit outside HR — the gate is closed.
02 — A mandate, with the awkward functions inside it. Get decision rights written down: who signs off the framework, and who arbitrates when a business unit wants its own taxonomy. Then bring Legal and Employee Relations in at the start. Consultation, transparency, and what you may infer about a person are architecture inputs — not compliance afterthoughts. Discovering them after signature is how a roadmap becomes a redesign.
03 — The design on paper: framework, process, experience. What does a manager see on a Tuesday? What is an employee asked to confirm, and what happens to their answer? Write it down, then let a mixed group — business, HR, UX, technology — try to break it. "Have you captured your requirements, and can you share them?" is not obstruction. It is the gate doing its job.
04 — A data spine you decided on, not one you inherited. One vocabulary. One proficiency scale. Agreed rules for merging what the HCM, the learning platform, and the delivery tools each believe to be true. Decide where it lives and who governs it before a vendor decides for you. Interoperability is not agreement.
05 — The gap, written as requirements, then the RFP. Review what you already own first; a surprising share of your early requirements is already sitting in the stack you pay for. Whatever is left is your gap — and the gap, not the demo, is your requirements document. Now evaluation becomes a comparison, not a beauty contest. Don't sign without a proof of concept run on your data, your roles, your languages.
The trap: five vendor archetypes
Every category of provider is genuinely good at something — and quietly assumes an architecture decision you may not have taken. Naming them helps you see what you're really being sold.
-The taxonomy-in-a-box — a defensible starting vocabulary on day one. Assumes its ontology can carry your business language.
-The inference engine — coverage without asking 40,000 people to fill in a form. Assumes you've decided what you may infer, and who can see it.
-The HCM module that came free — identity, hierarchy, permissions already built. Assumes your ambition fits its data model.
-The marketplace layer — visible mobility, gigs, mentoring people can feel. Assumes manager incentives and release rules that make supply move.
-The job-architecture rebuild in disguise — coherence across roles, levels, and skills. Assumes you've signed up for an 18-month change programme with pay and grading in scope.
If you haven't made the decision, the platform makes it for you — quietly, at configuration time.
The pathway
None of this is anti-technology. Applied to a settled architecture, the tech does things no spreadsheet ever will. The partnership works — it just works second.
A good woodsman facing a big tree spends their time sharpening the axe. That isn't advice about patience; it's advice about sequence. The tree doesn't get easier while you sharpen. You just stop paying for every blow that was never going to land.
So before the demo, before the RFP, before the budget line: which gate are you actually standing at?