A Forensic Analysis: Three Days Inside a Client Organisation Examining Why Their Competency Framework Had Zero Manager Adoption

The brief was straightforward: the organisation wanted to understand why their competency framework, launched eighteen months ago with a significant investment in design, communication, and rollout, had achieved near-zero adoption among line managers. They knew the adoption was low; their HR analytics team had been tracking it. What they did not know was why, specifically, and that specificity was what they needed before deciding whether to revamp the framework, simplify it, or abandon it altogether and take a different approach.

I spent three days inside the organisation, talking with managers across three business units and two corporate functions, attending meetings where the framework might plausibly have been used, and reading through the framework document itself alongside the rollout materials and the manager training that had accompanied the launch. I want to share what I found in some detail, because the findings were specific and the specificity matters. Generic diagnoses of competency framework failure produce generic recommendations that produce the same result again. What I found in those three days was specific to this organisation and instructive about the failure modes that appear most consistently across organisations.

I should say at the outset that the framework itself was good. I am not offering a polite professional qualification; I mean it. The design team had done serious work. The competencies were well-chosen, reflecting the organisation’s strategic direction, the behavioural anchors were genuinely specific, and the language was cleaner and less jargonistic than most corporate competency documents I have read. THE PROBLEM WAS NOT THE FRAMEWORK. The problem was the distance between the framework as a document and the framework as a working tool in the hands of a line manager who is preparing a performance conversation with a direct report on a Monday morning at 9am with a full diary ahead of them.

The first finding, which emerged in almost every manager conversation I had, was a language issue that I had not initially anticipated and that I do not think the organisation had correctly diagnosed when it described the adoption challenge as a “language problem.” The managers were not saying they could not understand the framework’s language; most of them could. They were saying that the framework’s language was not the language they used in the actual performance conversations they had with their teams.

The specific formulation I heard most often was some version of: “When I am talking to one of my team members about their development, I do not use these words. I talk about what I see them doing and not doing. If I were to read this to them, it would feel very formal and a bit strange.” This is a register gap, not a comprehension gap. The framework was written in formal HR register, with consistent use of nominalisations and the kind of elevated professional language that looks appropriate in a corporate document and sounds strange in a one-to-one conversation. The managers had not been given a translation: this is what “demonstrates strategic thinking by anticipating the longer-term implications of decisions” sounds like in the actual language of your team and your function.

The implication was specific. It was not that the framework needed to be rewritten in plainer language at the document level. It was that managers needed a bridge: examples of how each behavioural anchor translates into the conversational language of their specific context. That bridge had not been built, and its absence meant that the framework was only usable by managers who were willing to do the translation work themselves, which in practice meant the managers who were already the most capable people developers and who needed the framework least.

The second finding was about structural complexity rather than content volume. The framework had twelve competencies, which is not an unusually large number for a corporate framework. But its structure, with each competency divided into four levels of proficiency and each level described in a paragraph rather than a bullet, meant that using it required the manager to hold a significant amount of information in their head simultaneously while also having a conversation with a real person in front of them. The cognitive load was too high for the context of use.

Most of the managers I spoke to had the right instinct about this: they described trying to use the framework once or twice after the launch and finding it cumbersome, then setting it aside and falling back on their own language and judgment. They were not resisting the framework; they were responding rationally to a tool that was not designed for its primary context of use. A COMPETENCY FRAMEWORK THAT IS DESIGNED FOR COMPREHENSIVENESS RATHER THAN FOR USE IN A CONVERSATION is a reference document, not a working tool, and reference documents have a predictable use pattern: consulted occasionally, not used daily.

The specific structural change that the managers described, unprompted and with striking consistency, was the need for a single-page summary version of the framework: one that showed the twelve competencies with a single short phrase for each, usable as a checklist or a conversational prompt without requiring the manager to navigate to a specific level descriptor. They wanted to be able to say, in a development conversation, “let’s look at these five areas that matter most in your role right now,” rather than “let’s turn to page four of the competency framework and look at the level two descriptor for collaborative working.” The single-page summary did not exist. Nobody had thought to produce it, because the framework designers had been optimising for comprehensive coverage rather than for the experience of the manager in the room.

The third finding was the most significant and the most difficult to address: a substantial subset of managers did not believe that several of the framework’s competencies were relevant to their role or their team’s work. This was not a perception problem that could be solved by better communication. It was an actual relevance gap, produced by a universal framework that had been designed to cover the full range of roles in the organisation and consequently described leadership at a level of generality that was insufficiently connected to what leadership actually looked like in specific functions and at specific levels.

The specific feedback I received most often was from managers in technical functions: engineering, data science, and research. They described competencies like “builds strategic relationships across the organisation” and “communicates complex ideas to non-specialist audiences” as genuinely relevant aspirations for their teams, but they struggled to see how to apply them in the context of a team whose primary working relationships were internal and technical. The framework had been designed by a team that was predominantly from generalist functions, and its language reflected a generalist’s understanding of leadership behaviour. FOR THE TECHNICAL MANAGERS, IT DESCRIBED A DIFFERENT KIND OF LEADERSHIP from the kind they practised and the kind their teams needed to develop.

This is a solvable problem, but not through the framework redesign that the organisation was initially contemplating. It required the development of functional supplements: short, co-created additions to the universal framework that described how each competency translated into the specific leadership context of each major function. These supplements would be developed with the managers in those functions, in their language, with their examples, and owned by the functional leaders. The universal framework would remain as the shared architecture; the supplements would provide the contextual specificity that universal frameworks cannot.

Based on the three-day diagnostic, my recommendation to the organisation was not to rebuild the framework. The underlying architecture was sound, and the investment in the design work represented real capability that should not be abandoned. The recommendation was to address the three specific failure modes that the diagnostic had identified, each of which was specific and actionable.

For the language problem: develop conversation guides for each major role type, showing managers how to use the framework’s behavioural anchors in the actual conversational language of a development discussion. These guides should be co-created with a small group of managers who are already good people developers, so that they are written in the language that managers recognise as their own.

For the structural complexity problem: produce a single-page summary version of the framework showing the twelve competencies with a two-line descriptor each, usable as a standalone conversational prompt. This should be the primary artefact that managers have to hand, with the full document available as a reference for when they need greater depth. THE SINGLE-PAGE SUMMARY SHOULD BE DESIGNED FOR THE PERFORMANCE CONVERSATION, not for the HR system.

For the relevance problem: design and run co-creation workshops with managers in three to four key functions to develop functional supplements. These workshops serve both a design purpose, producing the supplements, and an adoption purpose: the managers who participate in co-creation become advocates for the framework in their functions, because they have genuine ownership of the content.