Why Most Capability Frameworks Fail
Capability frameworks fail for two reasons, and neither of them is the quality of the framework. They are built from the work that already exists and mapped to the strategy afterwards, so there is no real line to strategy. And they are launched rather than operated, so nothing keeps them alive. I have seen sound frameworks die inside eighteen months and mediocre ones survive. The document was never the variable.
This is one of the central arguments in the working paper at peoplecapabilitysystem.com, and it is worth stating on its own.
Why do most capability frameworks fail?
Most capability frameworks fail because the work was never architected to the strategy, and because the framework is built and never run. It is derived from the roles that already exist, mapped to the strategic priorities at the end, launched, admired, and then left, because nobody designed the operation that was meant to keep it alive.
Everything below is a version of one of those two failures.
Failure one: the framework was mapped, not derived
Watch how most capability framework projects actually run.
The team gathers the existing roles, the existing position descriptions, the existing work. They interview people about what they do. They synthesise it into domains and capabilities. It is careful work and the output is usually good. Then, at the end, somebody produces a slide mapping the framework to the strategic priorities.
That slide is where the framework dies, and nobody notices for two years.
The framework was derived from the current state of the work. The strategy was laid over the top afterwards as an annotation. So when the strategy moves, the framework has no reason and no route to move with it. There is no derivation to revisit, only a mapping to redraw, and redrawing a mapping changes nothing about the framework underneath it.
Here is the test. If your capability framework would look substantially the same regardless of what the strategy said, it was not derived from the strategy. Most would not change a line.
Failure two: no run loop
A framework is not a system. It is one artefact inside a system that has to be operated.
Operating it means checking whether skills are present at the level roles need, evidencing whether competencies are held rather than claimed, reading whether capability is deep enough across the workforce, and rolling that into a view of whether the strategy is executable by the people you have. That work is continuous and has no completion date.
Build is a project with an end date. Run is business as usual with no end date. Almost every failed framework I have examined shipped the build and called it the system.
Failure three: no named owner
Ask who owns the framework and you will usually get the name of a committee.
A committee that meets and disperses is not an owner. An owner is a named capability lead in human resources or organisation development who maintains the frameworks and calls the assessment cycle. Without one, nothing is maintained when strategy moves, local versions proliferate, and within two years there are eleven versions in eleven decks and no way of telling which one governs.
Decide who owns the run before you start the build. A framework with no operational owner becomes a shelved artefact, and that outcome is close to determined at the moment the project starts.
Failure four: the line was never accepted
A framework can be technically correct and still fail, because correctness is not acceptance.
Leadership has to own the bets as the actual bets rather than as a communications artefact. And the people in the roles have to accept that the line genuinely runs through their work. A framework nobody in the role believes gets quietly ignored the first time it costs someone something, and it will not survive the next reorganisation.
I have delivered frameworks I would defend on every methodological point that produced nothing, because acceptance was treated as a communications task at the end rather than as a design constraint from the start.
Failure five: the language collapses
A framework that cannot distinguish its own layers cannot derive one from the next.
Capability gets used to mean competency. Skill gets used to mean capability. Framework, model and matrix get treated as the same thing when they describe three different things. Once the words blur, the layers merge, and a merged structure cannot roll up. I have written about why this semantic drift is a structural failure rather than a pedantic complaint, and framework failure is where the cost lands.
The international bodies are not confused about this. The SFIA Foundation levels skills against responsibility and reserves the language of competence for a skill demonstrated in real situations. The European Commission's ESCO definitions treat a skill as narrower than competence. The precision is available. It is not being applied.
Failure six: position descriptions written by hand
This looks like an administrative detail and is actually structural.
In most organisations position descriptions are authored role by role, in a document, by whoever had the vacancy. Within a year they have drifted from the work and from the framework. And because the position description is the artefact people, managers and recruiters actually touch, its drift is the framework's death by a thousand cuts. The framework says one thing. The document in front of the hiring manager says another. The document wins.
In a working system a position description is not authored at all. It is a composite generated from the competency framework and the skills taxonomy. Change the competency framework and the position descriptions move with it.
Failure seven: adoption, which is bigger than the rest
The framework is the easy part. The hard part is behavioural and political.
Managers do not assess honestly. People do not engage with the result. The read is never used in a real decision, so the whole thing decays into form filling within a cycle. A sound design adopted badly produces nothing, and anyone weighing a capability effort should weigh the change effort rather than only the design of the framework.
A few things move it. Make the system useful to the individual before it is useful to the organisation, as a route to development and internal moves and a career path a person can see, so they have a reason to give honest evidence rather than to game it. Calibrate and moderate, so a rating means the same thing in different teams and does not drift upward to keep everyone comfortable. And make leadership use the read in decisions about staffing, development spend and succession, because a system that visibly changes nothing gets filled in carelessly.
What this means
None of this is an argument against capability frameworks. I build them and I think they are necessary. It is an argument that a framework built the wrong way round, and never operated, will fail no matter how good the artefact is.
The competency-based management tradition is instructive. Boyatzis, and Spencer and Spencer, produced constructs that hold up perfectly well. What that tradition never produced was an operating model, and its frameworks shelved for exactly the reasons above. The construct was sound. The direction and the operation were missing.
Derive the work from the strategy. Run it forever. The framework is one artefact inside that, and it is worth exactly as much as the line it sits on and the operation you build around it.
FAQ
Why do capability frameworks fail so often?Because they are derived from the work that already exists and mapped to strategy afterwards, and because they are launched rather than operated. Neither of those is fixed by writing a better framework.
Is the framework itself usually the problem?Rarely. Most of the frameworks I have seen fail were competently designed. What was missing was a real derivation from strategy, an owner, a cadence, and a run loop.
How do I tell if my framework was derived or mapped?Ask whether it would look substantially different if the strategy said something else. If the answer is no, it was described from the current work and mapped afterwards.
What is the single biggest predictor of failure?No named owner for the run. If ownership sits with a committee rather than a person, the framework will not be maintained when the strategy moves.
How do position descriptions cause framework failure?When they are written by hand, they drift from the work and from the framework. Because they are the artefact people actually use, their version of reality wins over the framework's.