Most competency frameworks are abandoned within 18 months of launch, according to Gartner. The typical failure looks like this: six to twelve months of cross-functional workshops, a beautifully formatted document, a launch presentation with genuine enthusiasm, and then nothing. The framework sits on a shared drive, gradually becoming irrelevant as the organization changes around it.
The problem is almost never the data. It is the design.
Why Most Frameworks Fail
Competency frameworks fail for a small number of identifiable, preventable reasons. Understanding them is the first step to avoiding them.
Too generic. Frameworks built from vendor libraries or industry benchmarks describe competencies at a level of abstraction that nobody recognizes in their actual work. "Strategic thinking" and "stakeholder management" mean something different in every role in every organization. Generic competencies cannot guide real development decisions, they just produce more box-ticking.
Disconnected from roles that actually exist. A framework built around idealized role profiles that don't match organizational reality is worse than no framework at all. It produces immediate cognitive dissonance. People know within minutes whether a description matches their job or an aspirational version of it that nobody actually performs.
No manager buy-in. If line managers don't understand how to use the framework in development conversations, performance reviews, or hiring decisions, it will never leave HR. Frameworks are abandoned when they are experienced as administrative overhead rather than practical tools. The people who need to use them daily were usually not involved in building them.
Measurement not designed in. Organizations that build frameworks without specifying how each competency will be observed, demonstrated, and assessed end up with a glossary, not an architecture. If you cannot tell someone what "proficient" looks like in observable terms, you have not finished designing the framework.
Stage 1: Start With Roles, Not Competencies
Before defining a single competency, map the roles in scope. For each role, document: what does strong performance look like in practice? What are the most critical decisions this role makes, and what would good judgment look like in those moments? What separates average performers from excellent ones, not in personality, but in behavior?
This role-based foundation prevents generic frameworks. It forces the framework to be grounded in real work rather than aspirational descriptions copied from a benchmark database. It also surfaces the roles where you genuinely do not know what "excellent" looks like, and that is valuable information on its own.
Stage 2: Work Backwards From Observable Behaviors
For each competency, define the specific behaviors that would make an experienced manager say "yes, this person has it." Not "demonstrates commercial awareness", but "anticipates how a proposed change will affect project margin and surfaces that risk proactively before the decision is made."
Behavioral specificity is the functional difference between a framework people can use and one they cannot. Vague definitions require interpretation at the point of use. That interpretation will be inconsistent, and the framework will produce inconsistent outcomes, in hiring, in development, in calibration.
Stage 3: Co-Design With the People Who Will Use It
The single strongest predictor of whether a framework will be adopted is whether the people it describes were involved in building it. This does not mean endless consultation rounds. It means targeted, structured input from senior practitioners in each role family, validated against line manager experience.
Two well-designed workshops, with the right people in the room, are more valuable than twelve months of steering committee reviews. The goal is not consensus, it is legitimacy. People adopt frameworks they recognize as true.
Stage 4: Define Use Cases Before You Launch
How will this framework be used in hiring? In development conversations? In performance calibration? In succession planning? Each use case has different requirements for specificity and structure. A framework designed to do everything without being tailored to any specific use will do none of them well.
Design for two or three specific, high-value use cases and build from there. The most common starting points are development conversations (high frequency, manager-driven) and hiring criteria (high stakes, cross-functional). Get those right first.
What a Workable Template Looks Like
Effective competency frameworks typically include five elements for each competency:
- A name and definition in two to three sentences, with no jargon and no ambiguity about what domain it covers
- Three to five behavioral indicators at each proficiency level, specific enough for a manager to recognize them in a real situation
- Three proficiency levels at minimum: developing, proficient, and expert, calibrated to what those levels actually mean in this organization, not a generic scale
- Examples of what each level looks like in practice for this specific role family
- How this competency is assessed or observed, the evidence a manager would look for
What to leave out: long sub-competency lists that nobody will remember, abstract definitions that could apply to any job anywhere, and proficiency level descriptors that differ only slightly from each other. If the distinction between "developing" and "proficient" is not immediately clear to a line manager, it will not be used consistently.
Making It Stick After Launch
A framework is not finished at launch. The launch is where most of the actual work begins. Frameworks that survive their first 18 months share a common pattern: they become embedded in processes people already use rather than running parallel to them.
Include framework language in job descriptions when roles are filled. Train managers explicitly on how to use behavioral indicators in development conversations, not as a competency overview session, but as a practiced skill. Build framework competencies into your performance review process, even partially. Frameworks that become vocabulary survive. Frameworks that remain documents do not.
If you're building or rebuilding a competency framework and want to avoid the most common failure modes, talk to Navilo. We have designed skills architecture across sectors and geographies, we know what works and, more usefully, what doesn't.