Why I Created the People Capability System
I created the People Capability System because I kept building frameworks that were mapped to strategy rather than derived from it, and I kept watching them die. Not bad frameworks. Good ones, carefully designed, signed off by executives, launched properly, and abandoned within about eighteen months. After enough of those, you stop blaming the framework and start looking at what the framework was built from.
The full argument, with the evidence and the limits, sits at peoplecapabilitysystem.com. This article is the reason it exists.
What is the People Capability System?
The People Capability System is a single architecture with four layers, strategy, capability, competency and skill, that intends the work to the strategy rather than retrofitting the strategy onto work that already exists. It produces a clear and accepted line from a strategic bet down to a discrete task, and it is run continuously rather than launched once.
I did not set out to invent a construct. I set out to explain a repeated failure I could not blame on anyone's design skill.
The pattern I kept seeing
I have been designing capability and competency frameworks since 2012. Across public sector, health, financial services and technology, and across organisations from a few hundred people to thirty-five thousand, the same thing happened often enough that it stopped being coincidence.
The design work was rarely the problem. Domains were coherent. Proficiency levels were distinguished properly. Behavioural indicators were observable rather than aspirational. If you had audited the artefact against any standard of good practice, most of them would have passed.
Then nothing happened. The framework stopped being touched. Position descriptions written from it drifted. A new executive arrived with a different vocabulary. Two years later somebody commissioned a new framework because the old one was out of date, and the cycle started again.
The thing I had been getting wrong
It took me an embarrassingly long time to see what was actually happening.
Every one of those projects started in the same place. We gathered the existing roles, the existing position descriptions, the existing work. We built a framework that described it well. Then, at the end, we produced a slide that mapped the framework to the strategic priorities.
That slide was the whole problem. We had described the work and then justified it against the strategy afterwards. The strategy had not shaped a single line of the framework. It had been retrofitted.
So when the strategy moved, the framework had no reason to move with it, because it had never been derived from it in the first place. There was no line to redraw. There was only a mapping, and a mapping is an annotation rather than a structure. It quietly stops being true and nobody notices for two years.
Intent runs one way
The correction is simple to state and unpopular to do. You intend the work to the strategy, not the strategy to the work.
That means starting with the bets the business is actually making. Deriving the durable human capabilities those bets require, across all roles. Deriving the competencies each role needs to turn those capabilities into delivered work. Deriving the skills underneath. Nothing at any layer is written independently and reconciled later, because there is nothing to reconcile. Each layer exists because the layer above it required it.
Do that and you get a line you can walk in both directions. Point at any skill and name the bet it serves. Point at any bet and name the work that delivers it.
It is unpopular because it means telling leadership their strategy is too vague to derive anything from, which is often true and never welcome. But a vague strategy produces a vague framework, and no amount of design craft rescues it. I have tried.
The line has to be accepted, not just correct
The second thing I got wrong for years was thinking a correct line was enough.
It is not. The line has to be accepted, and by two different groups. Leadership has to own the bets as the real ones rather than as a communications artefact. And the people in the roles have to accept that the line genuinely runs through their work, because if they do not, the whole thing gets quietly ignored the first time it costs someone something.
A technically perfect architecture that nobody in the roles believes is a diagram. I have delivered a few of those and I would rather not deliver another.
Why the language had to be fixed first
I could not make the architecture trace anything until the terminology held still.
Capability was being used to mean competency. Skill was being used to mean capability. Framework, model and matrix were treated as synonyms. When the words are loose, the layers collapse into each other, and a structure that cannot distinguish its layers cannot derive one from the next. That is why I hold a strict definition of competency, a separate one for skills, and why I keep saying the conflation is a structural failure rather than a pedantic complaint.
International bodies are not confused about this. The European Commission's ESCO definitions treat a skill as the applied use of knowledge to complete a task, narrower than competence. The SFIA Foundation levels skills against responsibility and reserves the language of competence for a skill demonstrated in real situations. The precision exists. It is just not being used inside most organisations.
Why now
Artificial intelligence is what turned this from interesting into urgent.
As tasks shift to automation and augmentation, the question of what humans still do, and to what level, becomes an operational question asked at the task layer. It is answerable only if the task connects upward to a role competency, to a durable human capability, and finally to a strategic bet. An architecture that was mapped rather than derived cannot answer it, because there is no line to read.
Every organisation I speak to is now asking that question. Almost none of them can answer it.
What I am not claiming
I did not invent capability, competency or skill. Those belong to McClelland, Boyatzis, Stephenson, Sen and a long line of people who did the hard work. And I have not proven that the assembled system produces the outcomes I say it does in a specific organisation. That proof does not exist yet, which is why the working paper states its propositions so that someone can falsify them.
What I am claiming is narrower. The work in most organisations was never architected to the strategy. It was described, then mapped. Deriving it downward instead, and running it continuously, is the thing that has been missing, and it is a proposition worth testing rather than a product worth selling.
FAQ
Why did you create the People Capability System rather than another capability framework?Because the framework was never what failed. What failed was that the framework was mapped to strategy rather than derived from it, so it had no reason and no route to move when the strategy did.
What is the difference between mapping and intent?A mapping draws lines between structures written independently, and it decays because neither side moves when the other does. Intent derives each layer from the one above, so the line is structural rather than annotated.
Is this based on your consulting work?It is based on framework design work I have done since 2012, across public sector, health, financial services and technology. The pattern of well-designed frameworks being shelved is what the system responds to.
Is it a commercial product?No. It is a working paper. Comments are open on it, including anonymous ones, and disagreement is the point.
What would change your mind about it?A comparative test showing the assembled system produces no better capability-to-performance outcome than the same components deployed separately. That is the central proposition and the one the whole argument should stand or fall on.