A competency framework that fits on two pages

A business commissioned a competency framework and received forty-two pages: eighteen competencies, five levels each, a matrix mapping every role. It was launched at a town hall and filed. Two years later a manager was asked what the competencies for her role were and named three, two of which were not in the document. The framework had been comprehensive, and comprehensive was the problem — nobody could hold it in their head, so nobody used it in the room where a decision was made.

A framework's value is not in its coverage. It is in whether the interviewer, the appraising manager and the person deciding a promotion are using the same words to mean the same thing.

It exists to answer one question consistently across the business: what does good look like in this role, at this level, in terms somebody can observe. Everything that hangs off it — hiring criteria, appraisal ratings, progression decisions, development plans — is an application of that answer. A framework that does not produce consistent answers to that question, for the roles the business actually has, is not doing its job however many pages it runs to.

Start from the roles that exist, not from a library. Take the six or eight roles that matter most — the ones hired most often, or where a wrong appointment costs most — and for each, ask the people who do it well and the people who manage it what distinguishes good from adequate. The answers cluster quickly into four to six things per role. Those are the competencies. Most will be shared across roles; two or three will be specific.

Resist the temptation to describe five levels. Three is enough for almost every role a growing business has, and five produces distinctions nobody can observe — the difference between a level three and a level four ends up being tenure or the manager's mood. Where a role genuinely spans a wider range, split the role rather than adding levels: a senior engineer and an engineer are two rows on the grid, not one row with five columns.

PAGE 1  Six shared competencies, each with three levels
        described in observable behaviour:
          Level 1  does this with guidance
          Level 2  does this independently
          Level 3  does this and develops others in it

PAGE 2  A grid: roles down the side, competencies across,
        the level expected in each cell. Two or three
        role-specific competencies added where needed.

Anything that will not fit is a sign it is not a
competency but a task, a value or a wish.

The level descriptions are the work, and they are what most frameworks skip. 'Communication: Level 3' means nothing. 'Explains a decision to a team that disagrees with it, and the team leaves knowing why' is something an interviewer can probe for, a manager can observe and a promotion panel can ask for evidence of. Write each level as a thing a person does, and two people rating the same behaviour will land within a level of each other — which is the entire objective.

1. 1

   Hiring

   The interview questions come from the level descriptions for the role. A candidate is asked for an instance of the Level 2 behaviour and scored against it. This is what makes structured interviews structured: the framework supplies the scorecard.

2. 2

   Appraisal

   The rating conversation is held in the framework's words. Instead of 'you need to be more proactive', the manager can say which level was expected and which was observed, with an instance. Disagreement becomes specific and resolvable.

3. 3

   Progression

   A promotion is a move from one row of the grid to another, and the gap between them is visible in advance. People can see what the next role requires, which is most of what makes a career path feel real.

4. 4

   Development

   A development need is a named gap between the observed level and the expected one, which is what a training need assessment is supposed to produce and rarely does.

The framework is the shared vocabulary those four processes have been missing. Without it, each invents its own — the interviewer scores on rapport, the appraisal on effort, the promotion on tenure — and none of them agree.

Level descriptions in observable terms get two raters within a level of each other. They do not get them to the same level, and for a framework that feeds pay or promotion, that gap matters. Calibration closes it: managers in a room, before ratings are final, comparing specific people against the same descriptions and explaining their reasoning to each other.

The first calibration session is where the framework gets tested against reality. A description that three managers read three ways gets rewritten. A level that nobody in the business reaches gets questioned. A competency that turns out to be indistinguishable from another gets merged. The framework that emerges is shorter and sharper than the one that went in, which is the opposite of what happens to frameworks that are launched and never argued over.

That argument, held once a year with the ratings in front of everyone, is what keeps competency and talent management an operating practice rather than a document. It is also the point at which a business discovers whether its managers can actually distinguish good from adequate in observable terms — and where they cannot, that is the development need, before anyone else's.

The pressure to expand is constant. Every function wants its specialism recognised, every value wants to become a competency, every year adds a line. Hold the line with a test: does this thing distinguish good from adequate in a way somebody can observe, and is it missing from what is already there? Most proposed additions are tasks, values or restatements, and belong elsewhere. A framework that grows past what a manager can carry in their head has stopped being a framework and become a document.

• Tasks are not competencies. 'Prepares the monthly report' is a job description line. The competency is whatever makes one person's report worth reading.
• Values are not competencies. 'Integrity' is a value. It becomes a competency only when described as observable behaviour at a level, and usually it is better left in the values statement.
• Review annually, remove before adding. If something is going in, something comparable should be coming out.
• One owner. A framework with no owner accretes. Name someone, by role, who says no.

A framework maps onto roles, so it inherits whatever confusion exists in how roles are defined. Where two people with the same title do different jobs, or a role's accountabilities were never written down, the framework will expose it rather than fix it. That is useful, and it means the framework work often has to be preceded by role design and job descriptions — you cannot say what good looks like in a role until you have said what the role is.

Done in that order, and kept to a size people can hold, a framework becomes the thing hiring, appraisal and progression finally have in common. That shared vocabulary, and the level descriptions that make it observable, are what competency and talent management work produces — and it is worth being suspicious of any version that arrives thicker than a few pages.