Creating a Competency Framework: Steps, Structure and Design
Most organisations that set out to build a competency framework end up with something that does not hold. They gather a working group, produce a list of competencies, and then wonder why nobody uses it two years later. The problem is almost never the competencies themselves. It is the design process that preceded them.
Creating a competency framework is not a documentation exercise. It is an architecture decision. What you build will shape how roles are defined, how performance is assessed, how development is prioritised, and how talent decisions are made. Getting the foundations right matters far more than getting the language polished.
What Is a Competency Framework
A competency framework is a structured set of competencies that define the knowledge, skills, and behaviours required to perform effectively in a role, function, or organisation. It provides a shared language for performance expectations and development discussions across the workforce.
At its core, a competency framework describes what good looks like, at different levels of seniority, in terms that are observable and assessable. Not aspirational values. Not role-specific task lists. Observable, assessable patterns of behaviour tied to performance outcomes.
Why Organisations Need a Competency Framework
Performance management without a competency framework is largely subjective. Managers assess people based on their own instincts about what good looks like. Development conversations lack structure. Hiring decisions rely on individual judgment rather than shared criteria.
A well-designed framework creates consistency. It allows an organisation to evaluate performance, make promotion decisions, and identify development needs using a common standard rather than individual interpretation. The CIPD's guidance on competency frameworks notes that frameworks are most effective when they are integrated across HR processes rather than used as a standalone tool.
That integration is the point. A competency framework is only useful if it connects to something real: a performance cycle, a promotion process, a hiring rubric, a development plan.
How to Create a Competency Framework
The design process for a competency framework follows a logical sequence. The stages below reflect established practice, informed by peer-reviewed research on competency framework methodology and applied across a range of organisational contexts.
Define the Purpose and Scope
Before identifying a single competency, establish what the framework is for. Is it organisation-wide, covering all roles? Is it function-specific, covering a single competency area? Is it designed for recruitment, performance management, succession planning, or some combination?
The answer shapes every subsequent design decision. An organisation-wide framework needs to work at a level of abstraction that applies across very different roles. A function-specific framework can be more precise and role-relevant.
Scope also includes who the framework covers. A framework designed for individual contributors will look different from one designed for people managers or senior leaders. Many organisations maintain separate frameworks for these populations rather than trying to make one framework stretch across all of them.
Gather Evidence Before Writing Competencies
Competencies must be grounded in evidence about what actually drives performance, not assumptions about what should. The most common source of evidence is structured conversations with high performers and their managers, supplemented by role documentation, existing frameworks, and sector-specific standards.
This is not a consensus exercise. You are not asking people what they value or what they think is important. You are asking them to describe, specifically, what effective performance looks like in practice. What does someone do, say, or decide that distinguishes a strong performer from an adequate one?
Methodologies for competency framework development consistently identify this evidence-gathering stage as the most consequential part of the process. Frameworks built without it tend to be generic, aspirational, and disconnected from actual performance reality.
Define and Structure the Competencies
Once the evidence is gathered, the competencies themselves are drafted. Each competency should have a name, a definition, and a set of behavioural indicators at each proficiency level.
The name should be descriptive and self-explanatory. "Communication" is too broad. "Stakeholder Influence" is more precise. The definition should explain what the competency covers and what it does not.
The behavioural indicators are where the real design work happens. These describe what the competency looks like in practice at different levels, typically from foundation through to expert or senior leader. They must be written at the right level of specificity: concrete enough to be meaningful, abstract enough to apply across different roles at that level.
Deciding what behaviours are worth including, and how to distinguish them from skills or knowledge, is a recurring design question. Behaviours describe how someone does something. Skills describe whether they can do it. A competency framework should primarily describe behaviours, with skills referenced where they are genuinely role-defining.
Set the Proficiency Architecture
Most frameworks use a proficiency scale from three to six levels. The naming conventions vary, but the logic is consistent: each level should describe a meaningful step up in competency, not just more experience doing the same thing.
Common proficiency architectures distinguish between applying a competency under supervision, applying it independently, applying it in complex or ambiguous situations, and modelling or building competency in others. Senior leader populations may require additional layers that reflect strategic rather than operational application.
The proficiency architecture should align with the organisation's broader job architecture. If the framework will support a leadership competency model, the proficiency levels at the leadership tier should reflect the specific demands placed on leaders in that organisation.
Validate Against Real Roles
Once the draft framework is built, test it against actual roles and actual people. Does a strong performer at Level 3 match the Level 3 descriptors? Do the descriptors make sense to the managers who would apply them?
This validation stage is not about getting buy-in. It is about finding where the framework breaks down before it is deployed at scale. Pay particular attention to whether the behavioural indicators are specific enough to support consistent judgment across different managers. If two managers would apply the same indicator differently to the same person, it needs to be rewritten.
Integrate Into Existing Processes
A competency framework that sits outside the organisation's core HR processes will not survive. It will be completed as a one-off exercise, filed, and forgotten.
Integration means embedding the framework into performance review templates, hiring scorecards, promotion criteria, development planning conversations, and succession frameworks. It also means building manager competency to apply the framework consistently, which is often underestimated.
Where an organisation also operates a capability framework design process, the competency framework needs to be designed to sit alongside it rather than duplicate it. Competency frameworks and capability frameworks serve different purposes and should be built as complementary rather than competing tools.
What a Competency Framework Is Not
A competency framework is not a values statement. Organisational values describe what the organisation believes in. A competency framework describes how people behave. These are related but not the same thing.
It is not a job description. A job description outlines accountabilities and tasks. A competency framework describes the competencies required to discharge those accountabilities well.
It is not a skills inventory. Skills inventories catalogue what people can do and whether the organisation has the skills it needs. A competency framework describes how people apply those skills in ways that drive effective performance.
The conflation of these concepts is common, and it creates frameworks that try to do too many things and end up doing none of them well.
Common Failure Modes
The most common failure is starting with the competencies rather than the purpose. When organisations begin by listing what they think people should have, they produce frameworks that reflect assumptions rather than evidence.
The second most common failure is producing a framework that is too long. Frameworks with twenty or more competencies are unusable in practice. Most of the value in a competency framework comes from five to eight core competencies that genuinely differentiate performance. Everything else is noise.
The third failure is building for design rather than use. A framework that looks comprehensive but cannot be applied consistently by managers in real performance conversations has failed its primary purpose.
Trade-offs and Constraints
Creating a competency framework takes time to do properly. The evidence-gathering stage alone typically takes four to eight weeks in organisations of any scale. Cutting this stage short produces frameworks that feel generic, because they are.
There is also a trade-off between breadth and precision. An organisation-wide framework will be more abstract than a function-specific one. The decision to build one framework or many has significant downstream implications for maintenance, consistency, and adoption.
Finally, any competency framework requires ongoing maintenance. Organisations change. The behaviours that drive performance in a high-growth environment are not the same as those needed in a consolidation phase. A framework that is not reviewed every two to three years will drift out of alignment with the organisation's actual needs.
Frequently Asked Questions
How long does it take to create a competency framework?
For a function-specific framework, expect four to ten weeks. For an organisation-wide framework, six to twelve months is realistic if the design process is done properly, including evidence gathering, drafting, validation, and integration planning.
How many competencies should a framework include?
Most effective frameworks include five to eight core competencies. Some include a small number of role or function-specific competencies on top of that base. Frameworks with more than twelve competencies are rarely used effectively in practice.
What is the difference between a competency and a behaviour?
A competency is a cluster of related behaviours, knowledge, and skills that enables effective performance. A behaviour is a specific, observable action or pattern of action. Behaviours are the evidence that a competency is present. The competency is the label for that cluster.
Do we need a different framework for leaders?
Usually yes. Leadership roles require a different set of behavioural expectations, particularly around direction-setting, building organisational competency, and operating in ambiguous or strategic contexts. Many organisations maintain a separate leadership competency framework rather than stretching a general framework to cover these populations.
How do we know if our competency framework is working?
The clearest sign a framework is working is consistent application by managers without prompting. If managers are using the framework in real conversations, referencing it in performance reviews, and citing it in promotion decisions, it is embedded. If it only surfaces at the annual review cycle and then disappears, it has not been integrated effectively.
Should we build our own framework or adapt an existing model?
Both are valid starting points. Established models such as those from Korn Ferry or CIPD provide a well-researched baseline. Building from scratch gives you a framework that is more precisely calibrated to your organisation's context. Most organisations use an existing model as a reference point and adapt it rather than starting from a blank page.