TL;DR
- The core decision: whether you're describing qualities or behaviours, because only one of them can be assessed.
- When doing nothing is right: when managers already apply similar standards and nobody has questioned an assessment.
- What has to be true: two managers reading the same description would recognise the same thing in the same person.
- How the options split: by where the content comes from, which determines whether anybody recognises it.
- Decision rule: if you can't say what somebody would be observed doing, you've written a quality, and it will be applied inconsistently forever.
- Outcome to expect: a shorter framework, less flattering language, and assessments two managers would agree on.
The Document That Describes Everybody
Somebody is asked to build a competency framework. The reasoning is sound: assessments vary between managers, promotion decisions are hard to explain, and nobody can say precisely what separates one level from the next.
So examples get gathered, and they're remarkably consistent. Communication, collaboration, problem solving, strategic thinking, ownership, adaptability. Each has descriptions at several levels, and the descriptions are written in language that sounds authoritative: communicates effectively with a range of stakeholders, demonstrates strategic awareness, takes ownership of outcomes.
The framework gets published. It's used once, in the next assessment round, and two things become apparent. Managers apply it differently, because the descriptions permit that. And nobody can find the boundary between levels, because the difference between communicates effectively and communicates highly effectively isn't a difference anybody can observe. By the following cycle it's an attachment nobody opens.
Best tools for Performance Management
The real problem isn't that the framework was badly written. It's that it describes qualities rather than behaviours, and a quality can't be assessed. Two managers looking at the same person and the same description will reach different conclusions, not because one is wrong but because the words don't constrain the judgement. The test that matters is whether two people would recognise the same thing, and most frameworks fail it on the day they're published.
When You Genuinely Do Not Need to Act Yet
Your current setup is genuinely fine. Managers apply similar standards, promotion decisions can be explained to the person who didn't get one, and nobody has asked what the difference between two levels is. A framework built for a problem you don't have is a document that will be ignored, at some expense.
Friction is starting to show. Two managers have assessed similar people differently, or somebody has asked what they'd need to demonstrate to progress and nobody could answer specifically. Both point at the same gap. The cheapest check is to describe a real person's work to two managers and ask them to place it.
It has become a real cost. Promotion decisions are being contested, or you're losing people who say they couldn't see a path, or every manager has developed a private standard. At this point the absence of a shared description is producing unfairness, and something written would help.
The edge case that forces it. Competencies are being used to make decisions about pay, promotion or continued employment, and those decisions are being questioned. Requirements around fairness, consistency and discrimination in employment decisions differ sharply by jurisdiction, and subjective criteria applied inconsistently are exactly what gets examined. Establish what applies where you operate and take local advice.
Five Questions This Reader Asks at 11pm
What should actually be in it? Descriptions of what somebody would be observed doing, at a level of specificity where two people would agree whether they'd seen it. That's the whole requirement. Everything else, the number of competencies, the structure, the levels, follows from whether you can satisfy it.
How many competencies should we have? Few. A framework with a dozen is describing a job rather than distinguishing performance, and nobody assesses against twelve dimensions honestly, so they'll pick three and ignore the rest. Four or five that genuinely differentiate beat a comprehensive set that gets skimmed. The pressure always runs the other way, because leaving something out feels like saying it does not matter, and every stakeholder has one more to add. Deciding in advance how many there will be, before anybody proposes content, is the only thing that reliably holds the number down.
How is this different from job levels? Levels describe seniority and usually pay. Competencies describe what good looks like in a particular skill, which may apply across several levels. They interact, since expectations rise with seniority, and conflating them produces a framework that's really a levelling document with skill words attached.
Who should write them? People who can describe what strong performers actually do, which means practitioners rather than a committee. Frameworks written centrally tend towards the general, because general language is the only kind that fits every function, and general language is the thing that can't be assessed.
How do we stop it being ignored? Attach it to a decision somebody cares about. A framework that's referenced in promotion decisions gets read; one that exists to inform development conversations gets read once. That's not cynicism about people, it's a fact about which documents get consulted.
Three Honest Categories the Approaches Split Into
Borrowed, adopted from an existing set. You take a published framework and adapt the wording. It's right as raw material when nobody knows where to start, and it's fast. It fails because somebody else's framework encodes their priorities, their structure and their kind of work, and the adaptation usually amounts to changing the company name. The deeper failure is that borrowed language is general by necessity, since it was written to apply widely, and general language is precisely what produces inconsistent assessment.
Prescribed, written from what leadership values. A senior group decides what good looks like and writes it down. It's right when there's a genuine intention to shift behaviour and the leadership team is willing to be held to it too, and it has real authority behind it, which matters for adoption. It fails when what's written describes aspiration rather than observation. A framework describing behaviours nobody in the organisation currently exhibits will be recognised as a wish list, and managers will assess against what they actually see instead.
Derived, built from what strong performers do. You look at people who are genuinely good at the work and describe specifically what they do that others don't. It's right almost always, and it produces the only framework people recognise, because it describes things that exist. It fails on effort, since it requires real observation rather than a workshop, and it fails if the sample is chosen badly: deriving competencies from your current strong performers reproduces whatever selection you've already made, including any narrowness in it.
Five Diagnostic Questions You Can Self-Assess Against
Give two managers the same described person and ask them to place them. This is the whole test and it takes twenty minutes. If they disagree, the framework isn't doing its job, and the disagreement will show up in every real assessment. Do this before publishing rather than after.
For each description, ask what you'd see somebody doing. Go line by line. Where the answer is a general impression rather than an observable action, that entry can't be assessed, and it's the entry that will be applied according to whether the manager likes the person.
Can somebody tell what to do next from reading it? Give it to a person one level below and ask what they'd need to demonstrate. Vague answers mean the framework can describe but not direct, which removes most of its value: the main thing people want from one is a route.
Does it describe anybody in your organisation? Read the top level and ask who it fits. If the honest answer is nobody, you've written an aspiration, and managers will quietly assess against reality instead, which means you have two standards and only one is written down.
Which competencies actually differentiate? Look at your strongest and weakest performers against each dimension. Some will separate them clearly and others won't distinguish anybody, and the second group is generating assessment work for no information.
Five Ways Frameworks Get Built
Adopting a generic set from elsewhere
Taking a published framework and adapting it. It earns its place as a starting point when nobody knows what a framework looks like, and reading a well-constructed one teaches more about structure than any amount of theorising. It's also fast, which matters when the alternative is a project nobody has time for.
Where it falls short is that the generality which makes it portable is the same property that makes it unusable. A description written to apply across industries has to avoid anything specific, and specificity is the entire mechanism by which a framework produces consistency. What you inherit is a structure and a vocabulary, neither of which is the hard part.
Use one to see what a framework looks like, then write your own descriptions. Keep the shape if it helps and replace every word that describes behaviour.
There's a tell that the borrowing went too far, and it's easy to check. Read the framework and ask whether it would need changing if your organisation did something completely different for a living. Where the answer is no, you have a document about being a competent professional rather than about being good at the work you actually do, and it will be applied accordingly.
Writing them from the leadership team's view
A senior group defines what good looks like. It earns its place through authority and speed. The people who'll make the decisions the framework informs are the ones defining it, which matters for adoption, and a small group in a room can settle things a wide consultation can't.
It falls short in two predictable ways. Senior people describe the work as they remember it, which may be several years out of date, and they describe what they value, which drifts towards the qualities that got them promoted. The second failure is aspiration: it's difficult to sit in that room and write down what actually happens rather than what should, so the framework describes a better organisation than the one it's for.
Add one constraint to the room: for every description, somebody must name a person who currently does this and what they were observed doing.
That constraint does two things at once. It forces the language towards the observable, because naming what somebody was seen doing is hard to do in abstractions. And it surfaces the aspirational entries immediately, since those are the ones where nobody can name anybody, which is a much easier conversation to have in the drafting room than a year later when managers are assessing against them.
Deriving them from what strong performers do
Observing people who are genuinely good at the work and describing what distinguishes them. It earns its place because it produces descriptions of things that exist, which is the only reliable route to a framework people recognise. The findings are also usually surprising: what separates strong performers is frequently not what leadership assumed, and that's worth knowing independently of the framework.
It falls short on effort and on sampling. It requires actual observation and conversations rather than a workshop, which is a real cost. And the sample matters: if your current strong performers are similar to each other in ways unrelated to capability, deriving competencies from them will encode that similarity as a requirement, which is both unfair and likely to be examined if a decision is challenged.
Derive from a deliberately varied group, and check what you've written for anything that describes a background rather than a capability.
The check worth running is whether a description could only be satisfied by somebody who has had a particular kind of career. Descriptions referring to experience of a certain scale, or to having worked in a particular type of organisation, look like capability statements and function as background requirements. Where the underlying capability can be demonstrated another way, say so explicitly, because otherwise the framework quietly narrows who can progress.
Building them per function with no common core
Each function writes its own, with nothing shared. It earns its place on accuracy. What good looks like in one discipline genuinely differs from another, and forcing a common vocabulary across them produces language so general it stops meaning anything.
It falls short on comparability, which is usually why the framework was commissioned. If every function has its own, you can't compare across them, so promotion decisions at an organisational level are back to being judgement calls. It also multiplies maintenance: several frameworks, each decaying at its own rate, and nobody owning the whole.
The workable middle is a small common core, three or four things that genuinely apply everywhere, plus function-specific detail underneath. The core has to be genuinely universal or it'll be ignored by whichever function it fits worst.
Getting the core genuinely universal is harder than it sounds, and the usual failure is that it gets written from the largest function's perspective. Whoever has the most people in the room shapes the language, and everybody else recognises it as somebody else's framework with their function bolted underneath. Drafting the core with the smallest function present, and checking it fits them before anybody else, produces something more likely to survive.
Having no framework at all
Relying on manager judgement, with nothing written. It earns its place in small organisations where managers talk to each other enough to calibrate informally, and it avoids the substantial cost of building and maintaining something that may not be used.
It falls short as soon as decisions need explaining. Without a shared description, promotion rests on the assessing manager's private standard, which varies, favours people who are visible, and can't be defended when somebody asks why they weren't selected. That's a fairness problem first and a documentation problem second, and it's the reason most frameworks get commissioned.
If you have nothing, the cheapest useful step isn't a framework. It's writing down what separates the strongest person in each role from the average one, which takes an afternoon and answers most of the same questions.
That exercise also tells you whether a framework would help at all. If managers doing it independently produce similar answers, you already have a shared standard and simply haven't written it down, which is a documentation job. If they produce different answers, you've found the real problem, and it's one a published document only solves if the disagreement gets resolved rather than papered over.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Managers apply similar standards already | Under thirty | Single site | None | Do not build one |
| Two managers place the same person differently | Any | Any | Descriptions permit disagreement | Rewrite as observable behaviour |
| Nobody can say what the next level requires | Any | Any | The framework describes but does not direct | Add what somebody would be seen doing |
| Framework exists, nobody opens it | Any | Any | Not attached to any decision | Attach it to promotion, or retire it |
| Top level describes nobody who works here | Any | Any | Aspiration rather than description | Derive from actual strong performers |
| Twelve competencies, three actually used | Any | Any | Comprehensiveness defeats assessment | Cut to four or five that differentiate |
| Each function has its own, nothing compares | Over two hundred | Multi-function | Comparability was the original point | Small common core plus local detail |
| Framework reproduces one kind of background | Any | Any | Sampling encoded similarity as requirement | Check wording, take local advice |
| Decisions being contested | Any | Any | Subjective criteria applied inconsistently | Establish local requirements first |
The second row is the test everything else depends on, and almost nobody runs it before publishing. Twenty minutes with two managers and one described person will tell you whether the document works, and it's considerably cheaper than discovering it during an assessment round.
Quality Versus Observable Behaviour
The single distinction that determines whether a framework functions. A quality is a property somebody has; a behaviour is something they'd be seen doing. Only the second can be assessed consistently. The conversion is mechanical once you have the habit: take the quality, ask what somebody doing it well was observed doing last month, and write that down instead.
| The common wording | Why it cannot be assessed | The behavioural version |
|---|---|---|
| Communicates effectively | Effective according to whom, and in what situation | Tells people who depend on a change before it happens, not after |
| Demonstrates ownership | Ownership is a feeling nobody can observe | Follows a problem past their own part of it until somebody has it |
| Strategic thinker | The word means something different to everybody | Raises the consequence nobody has mentioned before a decision is made |
| Collaborates well | Describes the absence of friction, not a contribution | Brings the person who will be affected into the discussion early |
| Adaptable | Indistinguishable from compliant, from outside | Changes approach when evidence arrives, and says what changed |
| Attention to detail | A trait, and one that reads as a criticism of character | Checks the specific things that have gone wrong before |
| Leadership potential | Potential is a prediction, not an observation | Others seek their view before committing to an approach |
| Customer focused | Everybody believes they are | Changes a decision because of something a customer said |
The third row is worth dwelling on because strategic is the most requested and least useful word in this whole subject. It's used to mean thinking further ahead, considering wider consequences, understanding the commercial context, or simply operating at a more senior level, and those are four different things. A framework using the word without unpacking it has passed the problem to whoever applies it.
The seventh row carries a specific risk. Potential is a prediction about somebody rather than an observation of them, which means it's assessed largely on how familiar and confident somebody seems. Patterns in who gets identified as having potential are worth examining rather than assuming, and where those assessments feed promotion decisions, the requirements differ by jurisdiction and are worth advice.
Where a Framework Earns Its Keep
A framework survives only if it's load-bearing in a decision somebody cares about. Otherwise it decays into an attachment, and no amount of launch effort prevents that.
The strongest use is promotion. Where a framework defines what the next level requires and promotion decisions reference it explicitly, people read it carefully, because it answers a question they genuinely have. It also makes decisions explainable, which is the second thing people want: being told why somebody else was selected is tolerable when there's a stated standard and intolerable when it rests on a manager's impression. That explanation has to be given, though. A stated standard nobody refers to when delivering the decision provides none of the benefit, and the person is left in exactly the position the framework was built to prevent.
The second use is hiring, and it's underexploited. A framework that describes observable behaviour is exactly what an interview should be assessing, and using the same descriptions in hiring and in progression means somebody joins knowing what good looks like here. Where the two are disconnected, people are hired against one standard and assessed against another.
That disconnection is more common than it looks, because hiring criteria and progression criteria are usually written by different people at different times for different reasons. The symptom is somebody who interviewed well and is assessed as mediocre within a year, without anything having changed about them. Reading the two documents side by side is a short exercise that occasionally explains a persistent problem nobody had traced.
The third is the development conversation, and this is where frameworks are usually aimed and least effective. A person asking what to work on next needs something specific, and a framework that only describes the destination without naming what they'd be seen doing differently can't provide it. That's a solvable design problem and it's why the behavioural wording matters.
What doesn't work is attaching it to the rating. Frameworks used to justify a score become a compliance exercise: managers work backwards from the rating they've decided to the descriptions that support it, which produces documents that look rigorous and contain no independent information. If you use it in assessment, use it to structure the evidence rather than to derive the number. The difference shows in what a completed assessment contains. One built to structure evidence has specific instances under each heading and is readable on its own. One built to justify a score has a paragraph under each heading that restates the score in different words, which is a document nobody learns anything from.
One maintenance point. Frameworks decay, because the work changes and the descriptions don't. A behavioural description written against how a job was done three years ago can be actively misleading now, and nobody notices because the document still reads plausibly. Reviewing a small number of descriptions each year against what people actually do keeps it alive at a cost of a few hours.
The descriptions most likely to have decayed are the ones about tools, processes or ways of working, since those change fastest. The ones about judgement and how somebody works with others tend to age well. If you're reviewing selectively rather than comprehensively, start with anything that mentions a specific method, because that's where the framework will have quietly drifted out of date.
What to Put in Writing
The framework is the artefact, and a few things around it determine whether it works.
| Artefact | Who owns it | When it is written | What it prevents |
|---|---|---|---|
| What somebody would be observed doing, per level | Practitioners, not a committee | At the point of drafting | Descriptions that permit any interpretation |
| The two-manager test result | Whoever builds it | Before publishing | Publishing a document that cannot be applied |
| Which decisions reference this framework | HR | Before launch | A document nobody has a reason to open |
| Who the descriptions were derived from | Whoever built it | At the point of drafting | Encoding a background as a requirement |
| What changed at the last review, and why | The framework owner | Annually | Descriptions that quietly stop matching the work |
| Local requirements on criteria used in decisions | HR, with local advice | Before it feeds any decision | Subjective criteria applied inconsistently |
The second row is the cheapest quality gate available and it's almost never used. Testing the framework on two managers and one real described person, before publication, catches the problem that otherwise surfaces a year later across dozens of assessments.
Questions to Ask Before You Commit
On observability. For each line, what would you see somebody doing? A bad answer restates the quality in different words.
On agreement. Would two managers place the same person the same way? A bad answer is that they'd be close.
On existence. Who currently does what your top level describes? A bad answer is nobody yet.
On use. Which decision references this? A bad answer is that it informs development.
On count. How many of these actually differentiate anybody? A bad answer is all of them.
On derivation. Who did you look at, and were they varied? A bad answer is that it came from a workshop.
What Getting This Wrong Costs
The first cost is a document that consumes a project and then nothing. Building a framework takes months of somebody's time plus a good deal of senior attention, and where the result can't be applied consistently it becomes an attachment that appears in templates and informs no decision. That's expensive, and it has a second-order effect: after one failed framework, the next attempt is harder to fund and harder to get engagement for.
The second cost is that it legitimises inconsistency rather than fixing it. A framework of unassessable qualities gives managers a document to point at while continuing to apply their private standards, which is worse than having nothing, because the inconsistency now has an official-looking justification behind it. Somebody told they didn't demonstrate strategic thinking has been given a reason that cannot be examined. They cannot dispute it, because there is nothing specific to dispute, and they cannot act on it, because there is nothing specific to act on. What they usually take from the conversation is that the decision was made on something else and the framework was the language it arrived in.
The third cost is where this subject becomes more than an administrative matter. Subjective criteria applied inconsistently are exactly what gets scrutinised when a promotion or pay decision is challenged, and words like potential, executive presence and cultural fit are the ones that attract attention, because assessments of them track familiarity and confidence more than capability. What that exposes an organisation to differs by jurisdiction, and it's worth advice rather than assumption, particularly where the framework feeds decisions about who advances.
So before you build anything, work out which of three problems you have. A consistency problem means managers apply different standards, and observable descriptions plus calibration will genuinely help. A clarity problem means people don't know what the next level requires, and what's needed is a route rather than a description of the destination. A defensibility problem means decisions are being questioned and judgement isn't holding up, and that requires evidence of what people actually did, which a framework supports but does not supply.
When You Are Ready to Go Further
None of this needs a project to start. It needs one competency rewritten as observable behaviour, tested on two managers with a real person described to them, and a decision about which actual decision the framework will inform.
The step beyond building it is keeping it alive, which is where most frameworks are lost. Attach it to promotion so people have a reason to read it, use the same descriptions in hiring so the standard is consistent from the first day, and review a handful of descriptions each year against what the work has become. A framework that isn't load-bearing in some decision will be ignored regardless of how well it was written.
HROpsLab publishes independent comparison work across HR tooling, applicant tracking and payroll. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is looking at what your current tooling assumes about competency structures, our comparison work is one place to start.
Frequently Asked Questions
What is a competency framework?
It's a written description of what good looks like in the skills an organisation considers important, usually broken into levels so that progression is visible. The purpose is consistency: two managers assessing similar people should reach similar conclusions, and somebody should be able to see what the next level requires. Whether a framework achieves that depends almost entirely on one property, which is whether the descriptions name observable behaviour rather than qualities. A description of what somebody is like can be applied any way a manager wishes, and a description of what they'd be seen doing cannot.
What should be included in a competency framework?
Descriptions of specific things somebody would be observed doing, at each level, written so that two people watching the same person would agree on what they'd seen. That's the entire requirement, and everything else follows from it. What to leave out is more useful guidance: qualities like adaptable, collaborative or detail-oriented, which cannot be assessed consistently, and anything that describes a personality rather than an action. If a line can't be converted into an observation, it will be applied according to whether the assessor likes the person.
How many competencies should a framework have?
Four or five that genuinely differentiate performance, rather than a comprehensive set covering everything a job involves. Twelve competencies describe a role rather than distinguish between people doing it, and nobody assesses honestly against twelve dimensions, so managers pick the three they find meaningful and ignore the rest. That means the framework has effectively chosen its own criteria by accident. A useful test is to check your strongest and weakest performers against each dimension: the ones that don't separate them are generating assessment work and no information.
How is a competency framework different from job levels?
Job levels describe seniority and usually attach to pay bands, answering the question of where somebody sits in the structure. Competencies describe what good looks like in a particular skill, which may apply across several levels with rising expectations. They interact, and conflating them is common: many organisations end up with a levelling document wearing competency language, which does neither job well. The practical difference is what each answers. A level tells somebody what they're paid and where they sit. A competency tells them what they'd need to be seen doing.
Who should write a competency framework?
People who can describe specifically what strong performers actually do, which usually means practitioners in each discipline rather than a central committee. Centrally written frameworks drift towards general language because general language is the only kind that fits every function, and generality is precisely the property that produces inconsistent assessment. The most reliable method is to look at people who are genuinely good at the work and describe what distinguishes them, which is more effort than a workshop and produces descriptions of things that actually exist rather than things somebody wishes existed.
How do you make competencies assessable?
Convert every quality into an observation. Instead of demonstrates ownership, write that they follow a problem past their own part of it until somebody has clearly taken it on. Instead of communicates effectively, write that they tell the people affected by a change before it happens rather than after. Then run the test that matters: describe a real person's work to two managers and ask them to place them against the framework. If they disagree, the wording still permits interpretation, and no amount of training will close that gap because the document itself is the problem.
How often should a competency framework be reviewed?
Lightly each year, reviewing a handful of descriptions rather than the whole thing. Frameworks decay quietly, because the work changes and the document doesn't, and a behavioural description written against how a job was done a few years ago can be actively misleading while still reading plausibly. The specific thing to check is whether the described behaviours are still what distinguishes strong performance now. Full rewrites are disruptive and usually unnecessary, and they tend to happen only when a framework has decayed so far that people have stopped using it.
Does a small company need a competency framework?
Usually not. Where managers talk to each other enough to calibrate informally and decisions can be explained without a document, a framework adds maintenance for a problem you don't have. The point at which it starts earning its place is when assessments visibly vary between managers, or when somebody asks what they'd need to demonstrate to progress and nobody can answer specifically. Even then, the cheapest useful step isn't a framework: it's writing down what separates the strongest person in each role from an average one, which takes an afternoon and answers most of the same questions.
A competency two managers would read differently isn't a standard. It's a document that lets inconsistency look official.
