What is a competency model? The complete guide to competency frameworks and skills matrices

A competency model is a structured description of the knowledge, skills, abilities and behaviours someone needs to perform a role well. It groups those requirements into named competencies, defines proficiency levels for each one, and describes the observable behaviours that show a person has reached each level. Hiring teams use it to decide who to interview, people teams use it to decide who is ready for promotion, and L&D teams use it to decide what to teach.

It is fair to ask whether any of this still matters when AI can draft the code, write the analysis and summarise the customer call. It matters more. When AI handles the first draft of most tasks, the difference between two people in the same role is no longer who can produce the output, but who can judge it: who notices the query is subtly wrong, who knows the proposed architecture will not scale, who can tell a confident answer from a correct one. Those are competencies, not skills, and they are invisible on a CV precisely because AI has made the visible output cheap. A competency model is how you name them, set the level a role needs, and check that a person actually has them. The roles are changing faster than ever, which is an argument for updating the model more often, not for dropping it.

This guide covers what a competency model is, how it differs from a competency framework and a skills matrix, how to build one in seven steps, and how to verify competencies rather than infer them from a CV. It links out to the detailed guides and free templates in this series where you need more depth.

What is a competency model?

A competency model answers one question for one role or role family: what does good look like, and how will you recognise it? It is more specific than a job description, which lists duties and requirements, and more structured than a list of skills, because each competency comes with levels and behavioural indicators you can observe and rate.

The idea traces back to McClelland's 1973 paper in American Psychologist, which argued that testing for demonstrated competence predicts job performance better than testing for intelligence or academic credentials. Fifty years later, the same argument sits behind skills-based hiring: assess what people can do, not what their background implies.

Competency vs skill vs proficiency level

These three terms get used interchangeably, which is where most confusion starts.

• A skill is a discrete, learnable ability: writing SQL queries, running a retrospective, negotiating a contract renewal.
• A competency bundles related skills with the knowledge and behaviour needed to apply them in context. "Data analysis" as a competency includes SQL, but also knowing which question to ask of the data and how to present the answer to a non-technical stakeholder.
• A proficiency level describes how well someone performs a competency, usually on a scale of three to five levels. Level 1 might be "applies the basics with guidance", level 5 "sets the standard others follow and coaches them".

A useful test: if you can learn it from a course in a week, it is probably a skill. If it takes a year of practice in real situations, it is probably a competency.

A competency model example

Here is a cut-down model for a backend software engineer: four competencies, five levels, one behavioural indicator per cell. A full model would carry two to four indicators per level, but the structure is the same.

Notice what makes each cell usable: it describes something you could watch a person do, or ask them about in an interview, and rate. "Good at system design" is not an indicator. "Designs services with clear interfaces and failure modes" is.

Competency model vs competency framework vs skills matrix

These three documents are related but not the same. Mixing them up is why so many competency projects produce a 40-page PDF that nobody opens.

The order matters. Build the framework first so everyone uses the same words and scale. Derive a model per role from it. Then fill a skills matrix for each team from assessed data, not self-reports. The full guide to competency frameworks covers the organisation-wide layer; the skills matrix guide covers the team-level grid.

Why competency models matter

A competency model earns its keep by replacing five separate judgment calls with one shared standard.

• Hiring. Interviewers rate candidates against the same indicators instead of their own mental model of a "strong hire". Scorecards become comparable across panels.
• Promotion readiness. A promotion case becomes "demonstrates L4 on four of five competencies" rather than "manager advocated hard". It also tells the person what to work on before the next cycle.
• Internal mobility. When every role maps to the same framework, you can see that a support engineer at L3 on problem solving and L2 on code quality is two levels, not a career change, away from a backend role.
• Reskilling. The World Economic Forum's Future of Jobs Report 2025 estimates that 39% of workers' current skills will change or become outdated by 2030. You cannot plan reskilling without a baseline of what people can do today.
• Skills gap analysis. Required level minus assessed level, per competency, per person, rolled up by team. The model gives you the required column; assessment gives you the assessed one.

The building blocks of a competency framework

Most frameworks organise competencies into four groups. The groups matter less than being consistent about which competencies sit where, because that is what lets you compare roles.

Proficiency levels and behavioural indicators

Levels are the scale; indicators are the evidence. Use one scale across the whole framework so a "3" means the same thing in engineering and in sales. Four or five levels work for most organisations. Three is too coarse to show progression within a role; seven invites arguments about the difference between a 5 and a 6.

Write each indicator so that a trained observer could rate it from a work sample, an interview answer or a test result. Three checks catch most weak indicators:

• Is it observable? "Understands distributed systems" fails. "Explains the trade-offs of a design choice to a reviewer" passes.
• Does it distinguish levels? If the L2 and L3 indicators could both describe the same person, merge or rewrite them.
• Is it role-neutral at the framework layer? "Writes clean Python" belongs in a role model, not in the shared framework. "Produces work others can maintain without explanation" belongs in the framework.

Types of competency frameworks, with examples

Frameworks differ mainly in scope and in what they are optimised for.

• Organisation-wide frameworks define core and leadership competencies for every employee. Public-sector examples are common because they are published: civil service frameworks typically list a handful of core behaviours with four to six levels each.
• Functional frameworks go deep on one discipline. Engineering ladders are the best-known example: a shared set of technical competencies with levels tied to titles.
• Leadership frameworks describe what is expected of managers at each tier, from first-time lead to executive.
• Role-specific models sit beneath any of these and describe one job in detail.
• Industry or professional-body frameworks are maintained by associations and often double as certification standards. Useful as a starting library, rarely usable as-is.

The guide to competency framework types walks through each with worked examples, and the competency framework examples post shows full models you can adapt.

How to build a competency model in 7 steps

Two of these steps carry most of the risk. Step 5, mapping competencies to roles, is where frameworks become either useful or decorative; the competency mapping guide covers how to set required levels without inflating every role to "expert". Step 6, assessment, is covered below, because it is the step most organisations skip.

From framework to skills matrix

Once competencies are mapped to roles and people have been assessed, you can fill a skills matrix: team members down the side, competencies across the top, assessed level in each cell, required level shown for comparison. Here is a minimal version for a four-person backend team against three of the competencies above.

Three things fall out of this grid immediately. Arjun needs system design exposure before his next review. Meera is ahead on problem solving and could take harder debugging work now. The team has no one above L4 on any competency, which is a succession risk if Dev leaves. None of that is visible in a framework document alone. The skills matrix guide goes deeper on reading and maintaining the grid, the skills gap analysis guide covers turning gaps into a plan, and you can start from the free skills matrix template.

Inferred vs verified: how to assess competencies

Every competency rating comes from one of two places: it is inferred from a signal that stands in for the competency, or it is verified by observing the competency directly. Most organisations run almost entirely on inference and do not realise it.

Inference is cheap and often wrong in both directions. Self-ratings are the clearest case: a meta-analysis of 55 studies by Mabe and West (1982, Journal of Applied Psychology) found that self-evaluations of ability correlated with measured performance at only 0.29 on average. In plain terms, knowing how someone rates themselves tells you a little, but not much, about how they will actually perform. The same study found accuracy improved when people expected their self-rating to be checked against a real measure, which is an argument for pairing self-assessment with verification rather than replacing one with the other.

Verification costs more per person, so target it. Verify the competencies that carry the most weight in a decision: the three or four must-haves in a hiring bar, the competencies a promotion hinges on, the gaps a reskilling budget will be spent on. Infer the rest until it matters.

Two practical notes on verification. First, match test difficulty to the required level; a test pitched at L2 cannot tell you whether someone is L3 or L4. Difficulty levels that map to years of experience make this easier to set up. Second, use interviews for the competencies a test cannot reach: judgment, communication, how someone reasons through an ambiguous problem. AI interviews let you run that conversation consistently across every candidate or employee, with follow-up questions that test depth rather than rehearsed answers.

Using a competency model across the employee lifecycle

Hiring and onboarding

Turn the role model into the hiring bar: pick the must-have competencies and their minimum levels, and build the funnel to verify them in order of cost. CV screening infers; a skills test verifies the technical competencies; an interview verifies judgment and communication. Creating an interview from a job description works better when the JD is already written in competency terms, because each competency becomes a topic the interview can probe. After the hire, the same model becomes the 90-day onboarding plan: where the new hire landed on each competency, and what moves them to the required level.

Promotion readiness and role readiness

Promotion criteria become explicit: the required levels for the next grade, assessed the same way for everyone. This removes most of the "why them and not me" conversations because the answer is visible in the matrix. It also lets you assess readiness for a role change before the role opens, which shortens time-to-fill for internal moves. Running an internal skills assessment against the next grade's required levels gives you that readiness read before the promotion cycle starts.

Internal mobility and succession

Because every role is described in the same competency language, you can search for people whose assessed profile is close to a target role's required profile, even if their title is unrelated. Succession planning becomes a filter on the matrix: who is within one level of the required profile for each critical role, and what would close the gap. This is what an internal mobility programme runs on: assessed profiles for current employees, compared against the requirements of open roles.

Reskilling and skills gap analysis

Gap analysis is the matrix with a subtraction column. Aggregate by team or competency to see where the largest gaps sit, then prioritise by business impact rather than by what is easiest to train. Re-assess after training to confirm the level actually moved; a completed course is inference, a passed test at the new level is verification.

Common mistakes

• Too many competencies. A role model with 15 competencies cannot be assessed or remembered. Cut to the five to eight that predict performance.
• Indicators that describe traits, not behaviour. "Is strategic" cannot be rated. "Chooses between two valid options by stating the trade-off and the deciding factor" can.
• Every role requires "expert". If the required level for most competencies is the top of the scale, the mapping is aspirational rather than real, and the gap analysis will show everyone as deficient.
• Building the framework and skipping assessment. The document is not the asset. The assessed data is. A framework without assessment is a job description with extra steps.
• Relying on self-assessment. See the 0.29 correlation above. Use self-ratings to start a conversation, not to fill the matrix.
• Different scales in different teams. If engineering uses 1 to 5 and sales uses 1 to 4, cross-team mobility and reporting break.
• Never revisiting it. Roles change. A framework that was accurate two years ago now describes work that has partly been automated.

Free templates: competency framework template and skills matrix template

Two templates cover the two documents you need to maintain.

• Competency framework template: a shared competency library with a five-level scale and space for two to four indicators per level, plus a role-mapping sheet for required levels per grade.
• Skills matrix template: a team grid with assessed and required levels per competency, automatic gap flags, and a roll-up by competency.

Both are built to be filled from assessment results rather than from memory. Start with one team and one role family, run one hiring or review cycle on it, and expand from there.

How Equip helps you build and verify a skill competency framework

Equip covers the verification half of this guide. Skill tests from a library of pre-built content or your own custom tests, with difficulty levels that map to experience, measure technical and functional competencies at the level a role requires. One-way and conversational AI interviews cover the competencies a test cannot reach, scoring each answer against the indicators you define. The same tests and interviews work for current employees through internal skills assessment and internal mobility, so the matrix for your existing team is built on the same scale as your hiring bar. Scorecards let human interviewers rate against the same criteria, so every rating in your matrix comes from the same scale. Pricing starts at $1 per candidate per test, so verifying a team or a candidate pool is cheaper than one bad hire.

FAQ

What is an example of a competency model?

A backend engineer model might contain four competencies (system design, code quality, problem solving, collaboration), each with five proficiency levels and two to four behavioural indicators per level. Level 3 on system design, for instance, might read "designs services with clear interfaces and documented failure modes". The full example is in the first section of this guide.

How many competencies should a competency model have?

Five to eight per role. Fewer than five usually means competencies are too broad to assess; more than eight means raters cannot hold the model in their head and ratings become noise. A whole-organisation framework can hold 20 to 30 competencies in its library, but any single role should draw only five to eight from it.

What is the difference between a competency model and a job description?

A job description lists duties, responsibilities and requirements for a role. A competency model describes the capabilities needed to perform those duties well, with levels and observable indicators you can assess. The job description says what the job is; the competency model says what good looks like and how you will recognise it.

How often should a competency model be updated?

Review every 12 to 18 months, and sooner for roles where the work is changing quickly, such as any role where AI tools have changed the day-to-day tasks. Treat indicators as the most volatile part: the competency names stay stable for years, but the behaviour that counts as L3 shifts as tools and expectations change.