Most organisations that say they need a new competency model already have a competency framework sitting unused. Competency model development is the job of turning that framework into something one role can use. Treating it as the same job as building the framework is the first mistake. This article covers the role-level process: what development involves, the four stages and the points where it tends to fail. For the system that sits underneath, see the competency framework development process.
What Is Competency Model Development?
Competency model development is the process of selecting, defining and levelling a specific set of competencies from a competency framework, and packaging them for one role, level, function or job family. The output is a role-level competency model, which I call a competency profile: the competencies the role needs and the level required for each.
A framework is designed once, governed centrally and changes rarely. A role-level model is derived from it, built for a specific audience and revisited whenever the role changes. Development sits between the framework and the matrix, translating a governed inventory into something a manager can use.
Development translates a governed inventory into something a manager can use.
A note on terminology. A competency framework is also called a competency model, especially in the United States. I use competency profile for the competencies and required levels for one role, and competency matrix for the grid of required against current proficiency. Usage varies by region, and I explain the differences in this competency model definition.
Why Competency Model Development Exists
A framework on its own is too broad to use for anything practical. It may define forty or fifty competencies across core, technical and leadership domains, each written to apply across the whole organisation. No manager can hold that in their head or interview against all of it.
Development closes the gap by answering a narrower question: which of these competencies matter for this role, at what level, and how would we recognise them in someone's work? It is the same problem I describe in why most capability frameworks fail: a well-designed structure nobody translates into something usable at the point of application.
How Competency Model Development Works in Practice
The CIPD's factsheet on competency and competency frameworks makes a similar point from the practitioner side: competencies exist to give people a clear indication of the behaviours expected of them. Whatever the organisation's size, development follows four stages.
The same four stages apply whatever the size of the organisation.
Stage 1: Job analysis
Start with the work, not the framework. Interview people who do the role and the managers who assess it, observe the work where you can and read the role documents. The aim is to find what distinguishes strong performance in this role from adequate performance.
Stage 2: Select and draft
Choose a limited set from the framework, six to ten is a practical range, set the level the role requires for each and add a few role-specific examples. Selection is the point. If a competency you need is missing, change the framework through its governance rather than writing a one-off definition in the model.
Stage 3: Validate
Test the draft with the people who do the role and the managers who will assess against it. Ask whether the levels feel right, whether the examples are recognisable and whether two managers would read an indicator the same way.
Stage 4: Publish and maintain
Release it where managers will find it, name an owner and set a review point tied to role change. A model with no owner and no review cycle degrades faster than most other HR artefacts because it is specific enough to go out of date.
Competency Model, Framework, Matrix and Job Description
Scope, purpose and update frequency all differ between the four artefacts.
The four artefacts have different jobs. The framework standardises, the role-level model contextualises, the matrix measures the gap and the job description states accountabilities. Collapsing them into one document makes each of them worse.
Named Frameworks and Standards
Published examples show how development plays out with real structure behind it.
SHRM's competency work for HR professionals is a competency model in the full sense: a defined set of behavioural and technical competencies built through structured research with practitioners and applied to one profession. SFIA, the Skills Framework for the Information Age, takes a related approach for digital roles, defining professional skills against seven levels of responsibility. Its documentation on how the framework works is a useful model of selecting from a large catalogue for one role. Korn Ferry and Lominger offer a large bank of pre-written competencies that organisations select from and adapt, which makes the selection and levelling step the main piece of work.
Common Failure Modes
- Starting from a blank page. Writing new definitions for each role fragments the framework and destroys comparability.
- Skipping job analysis. A model written from a manager's memory describes the manager, not the role.
- Selecting too many competencies. A model nobody can remember is a model nobody uses.
- Setting levels from the person. Required levels describe the role. Setting them at the incumbent's level bakes one person's profile into the standard.
- No owner. Without one, the model drifts as the role changes.
Trade-Offs and Constraints
Development is worth the investment when a role or job family is large enough, stable enough or important enough to justify a defined standard: dozens of people in structured career paths, a role critical to a regulated activity or a function where hiring consistency matters.
It is a poor use of effort for a role held by one or two people, a role likely to be restructured within twelve months or a function still working out its scope. A lighter role profile drawn loosely from the framework does the job there. The constraint most organisations underestimate is ongoing governance, not the initial build.
FAQ
What is competency model development?
It is the process of selecting, defining and levelling competencies from a framework for one role, level or job family, and publishing the result as a competency profile.
How is competency model development different from building a framework?
Building a framework creates the organisation-wide system of definitions, levels and rules. Development applies that system to one role. The first is done once and governed centrally. The second is repeated for each role and revised as roles change.
How many stages does it have?
Four: job analysis, select and draft, validate, and publish and maintain.
How many competencies should a role-level model include?
Six to ten is a practical range. More reduces usability.
Who should own a role-level competency model?
The function that uses it most, such as HR for people roles or a profession lead for specialist roles, with changes to definitions routed through the framework's governance. For the wider context, see what the People Capability System is.
