Ben Satchwell argues that capability frameworks fail when treated as a design deliverable instead of a change programme. The document is only the opening move. Prioritise sponsorship, manager enablement, behaviour change and reinforcement before taxonomy perfection. Budget for adoption first, run communication as a campaign, and plan beyond go live.
Most capability frameworks are commissioned as documents. Someone signs off a project to define the capabilities the organisation needs, a team spends three or four months drafting them, and the deliverable is a polished artefact: levels, descriptors, a taxonomy that maps neatly onto job families. It launches, and within a year almost nobody is using it. The framework was good, but the project still failed.
A capability framework is not a document you publish. It is a change programme you run
This happens because learning and development scopes a capability framework as a design task and treats adoption as the thing that happens afterwards, once the real work is done. That order is backwards. A capability framework is not a document you publish. It is a change programme you run, and the document is only its opening move.
The same is true of competency frameworks and skills taxonomies. Whatever label you use, the moment you ask an organisation to describe its people differently and then act on that description, you are asking thousands of individuals to change how they think about their own development. That is a behavioural shift, and behavioural shifts are not delivered by publishing a file.
The myth that taught us the wrong lesson
Consider the most-quoted number in change management. The claim that 70% of change programmes fail is repeated everywhere, usually pinned on John Kotter, yet there is almost no evidence behind it. The figure traces back through a chain of sources that each cite the one before. I don’t quote it to frighten anyone. I quote it because the myth has done real damage: it trained L&D to expect change to be hard while saying nothing about why. The why is the useful part. Prosci’s research into why change management fails keeps landing on the same culprits:
- No active sponsorship
- No reinforcement
- Communication that explains what is changing but never why
None of those are design flaws. They are programme flaws.
Now look at where the budget goes. On a typical framework project, the overwhelming majority of effort is spent on creation: workshops to define capabilities, drafting and redrafting descriptors, validation, formatting for the system. Adoption gets whatever time and money is left over, which is usually a launch email and a slot in a town hall. We spend the budget on the half of the job that is easiest to do well, and starve the half that decides whether any of it survives.
Budget for the human half first
What would it look like to budget for the human half first? You would decide, before drafting a single capability, who the sponsor is and what they will personally do. You would identify the managers who have to carry this into their teams, and plan how to equip them. You would work out the one behaviour you expect to change, and how you will know it has. You would treat communication as a campaign with a beginning, a middle and a reinforcement phase, not a single announcement. Only then would you start designing the content.
This reframing changes who is in the room. A document can be written by a small expert team. A change programme cannot. It needs the people who will live with the framework involved early enough to feel some ownership of it, a sponsor who can explain the rationale without reading from a slide, and managers who understand it well enough to discuss it rather than forward it.
It also changes the timeline. Design is finite: you can finish a taxonomy. Adoption is not. Reinforcement is the phase most organisations neglect, precisely because it comes after launch, when attention has moved to the next initiative. If your plan ends on go-live day, you have planned for the document and not the change.
Inversion for absorption
I am not arguing that design quality is optional. A confused, bloated framework will fail on its own terms. But construct precision is the price of entry, not the prize. Plenty of well-built frameworks sit unused, and almost none of them died because a descriptor was slightly wrong. They died because nobody planned for the slow, unglamorous work of helping an organisation absorb them.
So before you scope your next capability framework as a design project with an adoption tail, invert it. Budget for the human half before the design half. Decide how you will earn attention, sponsorship and use before you decide how many proficiency levels you need. The document is the easy part. The change is the job.
Ben Satchwell is Head of Capabilities at Acorn PLMS
