Competency Framework: How to Build One That Gets Used

What is a competency framework?

A competency framework defines the skills and behaviours a role requires, at what level of proficiency, so hiring, promotion and development decisions can be made against a shared standard rather than individual judgement. At minimum it answers three questions: what does good look like in this role, how does it differ at the next level, and what would someone need to develop to get there.

The version that fails is a 200-page document produced by a consultancy, launched with a webinar, and opened twice in three years. The version that works is smaller than you expect, written in language the people it describes would recognise, and wired into at least two decisions that happen regularly.

Start with the decisions, not the competencies

Before writing a single competency, name the decisions the framework must support. This determines almost everything about its structure.

| Decision it supports | What that requires | |---|---| | Promotion | Clearly differentiated levels with observable behaviours | | Hiring | Interview-assessable criteria per level | | Development planning | Adjacency between levels — what "next" looks like | | Internal mobility | Comparable skills across role families | | Workforce planning | Aggregatable skill data at organisation level |

A framework built for promotion decisions is structured differently from one built for internal mobility. If you try to serve all five from day one you will produce something too abstract to serve any of them.

Pick two. Usually promotion and development, because those are the conversations happening whether or not a framework exists.

Keep it small enough to hold in your head

The strongest single predictor of whether a framework gets used is its size.

Sensible bounds:

• 4–8 competencies per role family, not twenty
• 4–6 proficiency levels across the whole career ladder
• 2–4 observable behaviours per competency per level

If a manager cannot hold the framework in mind during a one-to-one, they will not use it during a one-to-one. Comprehensiveness is the enemy here — every competency added dilutes attention across all the others and increases the maintenance burden that eventually kills the framework.

Structure competencies in three groups:

Core — expected of everyone, regardless of role. Usually three or four. Collaboration, communication, judgement.

Functional — specific to the discipline. Engineering, finance, sales. This is where the real differentiation lives.

Leadership — applies once someone manages people or leads without authority. Introduced at the level where it becomes relevant, not before.

Write levels that actually differentiate

The most common defect is levels that differ only by adverbs. "Communicates effectively" at level 2 and "communicates very effectively" at level 3 is not a framework; it is a scale with words attached.

Real differentiation comes from changing one of four things:

Scope. Own work → team's work → function → organisation.

Autonomy. Needs direction → works independently → sets direction for others.

Complexity. Routine problems → ambiguous problems → problems nobody has framed yet.

Impact. Contributes to outcomes → owns outcomes → shapes what outcomes matter.

A good test: read the level 3 and level 4 descriptions for a competency, cover the labels, and ask a manager which is which. If they cannot tell reliably, the levels are not differentiated and no amount of calibration will rescue the promotion process built on them.

Write behaviours, not traits

Traits are unassessable and invite bias. Behaviours are observable.

| Instead of | Write | |---|---| | "Is a strategic thinker" | "Identifies the second-order effects of a proposed change and raises them before the decision" | | "Has strong communication skills" | "Explains technical trade-offs to non-technical stakeholders such that they can make the decision themselves" | | "Is a team player" | "Offers help on work outside their own objectives when the team's outcome is at risk" | | "Shows leadership" | "Sets direction for an ambiguous piece of work and brings others with them without formal authority" |

The behavioural version can be evidenced in a promotion case. The trait version can only be asserted, and assertions correlate with how much the assessor likes the person.

This matters for equity as much as for accuracy. Trait-based frameworks reliably produce demographic gaps in promotion rate, because "shows leadership" is read differently depending on who is showing it.

Build it with the people it describes

Frameworks written by HR alone get rejected on sight by the functions they describe, usually with the accurate observation that the author has never done the job.

A workable process:

1. HR designs the structure — the level model, the competency groups, the format. This is the part HR is genuinely best placed to own.
2. Practitioners write the functional content — a small group of respected senior people per function, in a couple of workshops, describing what actually distinguishes levels in their discipline.
3. HR normalises across functions — so level 4 means something comparable in engineering and in finance. This is essential for internal mobility and it is the step most often skipped.
4. Test against real people. Take twelve current employees at known levels and check the framework places them where the organisation already believes they sit. If it does not, the framework is wrong — not the people.

That last step is the highest-value hour in the whole exercise, and it is routinely skipped because it risks embarrassing the framework.

Wire it into something that happens anyway

A framework used only at annual review time will be forgotten eleven months of the year. Attach it to processes that already run:

• Job adverts and interview scorecards — hiring against the same criteria you promote against, which also improves quality of hire
• Promotion cases — evidence mapped to specific level behaviours
• One-to-one templates — one competency per month rather than all of them annually
• Development plans — the gap between current and next level is the plan
• Skills gap analysis — the framework is the assessment instrument

The integration point that returns most is the interview scorecard, because it forces the framework to be specific enough to assess in an hour with a stranger. Anything too vague to interview against is too vague to promote against.

Maintain it or it decays

Frameworks rot quietly. Roles change, the language ages, and within about three years the document describes an organisation that no longer exists.

Realistic maintenance:

• Annual light review — which competencies were never referenced in a promotion case this year? Those are candidates for removal.
• Every 2–3 years, a real refresh — with practitioners again, not as a documentation exercise.
• A named owner. Frameworks without one always decay, because maintenance is nobody's priority in a busy quarter.

Removing competencies is as important as adding them. Frameworks only ever grow unless something actively prunes them, and a framework that has grown past what a manager can remember has stopped working regardless of how accurate it is.

Frequently asked questions

How many competencies should a framework have? Four to eight per role family, split across core, functional and leadership groups. Frameworks with twenty-plus competencies are consistently reported as unusable by the managers expected to apply them, and the maintenance burden makes them decay faster.

How many proficiency levels should we use? Four to six across the full career ladder. Fewer than four cannot differentiate meaningfully between an early-career and a senior contributor; more than six produces adjacent levels that nobody can reliably tell apart, which makes promotion decisions contestable.

What is the difference between a competency framework and a skills matrix? A competency framework describes behaviours and proficiency levels for roles, and is used for progression and assessment. A skills matrix maps which specific skills individuals hold, usually for resourcing and gap analysis. The framework defines the standard; the matrix records the current state against it.

Should the framework be the same across every function? The structure and level definitions should be common, so a level 4 is comparable across functions. The functional competencies themselves should be written by each discipline. Common structure with local content is what makes cross-function mobility possible without making the framework meaningless.

Turn the framework into live capability data. PeoplePilot Learning maps your competency framework to assessments and learning paths, so the gap between current and target level becomes a development plan automatically. Try the free skills assessment or start a free trial.