Ben Satchwell challenges the default diagnosis when capability frameworks sit unused after twelve months. Low usage often signals a failed launch, not flawed content. Before expensive redesigns, audit sponsorship, manager understanding, communication and reinforcement. Distinguish neglect from design issues, fix sustainment, and resist rewriting artefacts that were never truly introduced.
A capability framework that nobody uses at the twelve-month mark gets a predictable diagnosis: the content was wrong. The levels were too granular, or not granular enough. The language didn’t fit. The capabilities missed something important. So the organisation commissions a redesign, and a year after that, the second version is sitting just as unused as the first.
Redesigning the content is the most expensive possible way to avoid the real problem
I want to offer a different diagnosis. In most of these cases the framework didn’t fail, the rollout did. And redesigning the content is the most expensive possible way to avoid the real problem. Here is the test I would apply before anyone reopens the design. Did the framework ever actually launch, in the sense that matters? Not “was it published”, because publishing is easy. Did it get active sponsorship from someone senior who used it themselves? Did managers understand it well enough to talk about it with their teams? Was there a plan to reinforce it after week one? If the honest answer to those is no, then the framework was never really tried. It was posted.
This applies just as much if your artefact is a competency framework or a skills taxonomy. The construct you chose is almost never the reason adoption stalls. The absence of a launch is.
Change dies after launch, not at it
Change initiatives rarely fail at the moment of launch. They fail in the months after, when the energy that went into building and announcing them quietly evaporates. Prosci calls this the sustainment problem, and it is the most under-resourced phase of any change. People have a natural pull back to how they worked before. Without deliberate reinforcement, the change simply doesn’t stick, and the organisation drifts back to its old habits while the new framework gathers dust.
Notice what that means. A framework can be perfectly designed and still die, because death by neglect looks identical to death by bad design from the outside. In both cases you get the same symptom: low usage at twelve months. The symptom tells you nothing about the cause. And if you read every case of non-adoption as a content problem, you will redesign forever.
So why does L&D reach for redesign first? Partly because content is the part we control and understand. Redrafting descriptors is familiar, comfortable work. Diagnosing a failed rollout means asking harder questions about sponsorship, manager capability and our own communication, and some of those answers implicate us. It is easier to blame the artefact than the programme.
There is also a measurement trap. If the only thing you tracked was completion or log-ins, you have no way to tell a content failure from an adoption failure, so you guess, and the guess flatters the bits you can change. Activity data was never built to tell you why something didn’t land, only that it happened.
Audit the launch, not the content
Before you rebuild, do the cheaper thing: audit the launch, not the content. Ask whether the sponsor ever explained the why in their own words. Ask a sample of managers to describe the framework back to you, and see whether they can. Ask whether anything reinforced it after the first fortnight. Ask whether you ever told people why this mattered to them, individually, rather than to the organisation in the abstract. If those come back thin, you have found your problem, and it is far cheaper to fix than a redesign.
Sometimes the content genuinely is the issue. If managers understood it, sponsors backed it, the why landed, and people still rejected it, that is a real signal worth acting on. But that is the exception, and you can only see it clearly once you have ruled out the rollout. Redesigning before you have checked the launch is like rewriting a speech nobody was in the room to hear.
The uncomfortable version of this is that the second framework will probably fail the same way the first did, because nothing about how it was introduced has changed. New content, same silent launch, same result. You will have spent another year and another budget proving that the problem was never the document.
So when your framework is unused at twelve months, resist the redesign reflex. Ask first whether you ever truly launched it. Most of the time, that question is the whole answer.
Ben Satchwell is Head of Capabilities at Acorn PLMS
