Developing competency framework: a practical employer guide
A practical guide to building a competency framework that improves hiring, interviews and scorecards - not just HR documentation.
What a competency framework is really for
Developing competency framework work starts badly when the first question is "which competencies should we use?" The better first question is: which decisions are we trying to make less vague? A competency framework is a shared description of the skills, knowledge, attributes and behaviours needed for successful performance in a role. That sounds tidy. It is also the point at which many organisations wander off into a scented fog of "collaboration", "ownership" and "strategic mindset".
The useful version is more practical. It gives managers and candidates a common language for clearer performance expectations. It defines, role by role, what good work looks like and how that work can be recognised in hiring, development and promotion. TechTarget describes it as the structure that defines competencies for each role, which is a decent plain-English starting point.
The hiring angle matters because a framework that cannot shape an interview question, a scoring rubric or a decision rule is mostly decoration. McClelland (1998) treated competencies as observable patterns drawn from real episodes of work, especially the difference between outstanding and typical performers. Campion, Palmer and Campion (1997) made the same demand of selection interviews: start with job analysis, then standardise what is asked and how answers are evaluated.
So a competency framework is not a values statement with better stationery. It is a decision tool. If you are developing a competency framework for hiring, it should tell an interviewer what to ask, what evidence to listen for and how to score that evidence consistently.
The pieces your framework needs
A useful competency framework needs more than a list of attractive words. At minimum, each competency should have a name, a plain definition, behavioural indicators, proficiency levels and examples of evidence. The IAEA's framework defines a competency as a combination of skills, knowledge, attributes and behaviours. The word that does most of the work there is "behaviours".
Behavioural competencies are what make the framework assessable. "Communication" is not enough. "Explains trade-offs to non-specialists without hiding uncertainty" is better. "Leadership" is not enough. "Sets a direction, assigns ownership and follows up when accountability slips" gives an interviewer something to test and a manager something to coach.

Mature competency framework examples usually separate the architecture into a few layers. Core competencies apply to everyone. Functional competencies describe the work of a specific job family. Leadership competencies cover people-management or enterprise-level responsibility. Technical competencies capture domain skills, qualifications or knowledge. SHRM's competency model is useful because it shows the elements inside a mature competency model: title, definition, cluster, subcompetencies, key behaviours and standards.
For a smaller employer, the trick is not to copy the architecture at full weight. Start with the smallest version that will improve decisions: five to seven competencies for a role family, each with three proficiency levels and two or three evidence examples. If the framework cannot fit on a scorecard and be explained in five minutes, it will probably survive in a folder and nowhere else.
Build it from work, not wishful thinking
The best way to build a competency framework is to begin with the work itself. That means role analysis before wordsmithing. The U.S. Office of Personnel Management's structured-interview guide puts job analysis before interview design for a reason: questions and rating scales only make sense once you know which tasks, responsibilities and competencies matter.
A practical sequence looks like this. First, define the purpose. Is the framework for hiring, progression, performance management or learning? Second, gather evidence from job descriptions, performance reviews, high performers, managers, customers and failed hires. Third, draft the competencies in observable language. Fourth, test the draft with people who know the role. Fifth, pilot it in a real hiring or performance cycle and revise it after the decision has been made.

McClelland (1998) gives the sharpest principle: compare outstanding and typical performers. Ask what the best people repeatedly do that the merely acceptable people do not. This keeps the framework from becoming an aspiration catalogue. A company can aspire to "commercial judgement" all day. The useful question is what strong commercial judgement looks like when a candidate is deciding whether to discount, walk away or protect margin.
External guidance says much the same in simpler terms: gather role evidence through analysis and employees before constructing the framework. That is the part usually skipped because a workshop full of nouns feels faster. It is faster, in the same way guessing a postcode is faster than using the address.
Keep version one narrow. If every role gets 18 competencies, every competency becomes unimportant. For hiring, pick the few capabilities that separate acceptable from excellent performance and that can be assessed fairly in the process you actually run.
Turn competencies into interview questions and scorecards
The moment a competency enters a hiring process, it needs to become a question and a scoring rule. Otherwise interviewers will nod at the framework, ask whatever they normally ask and later claim they were "testing judgement". A structured interview prevents that drift by standardising the question, the evidence sought and the rating scale.
Campion, Palmer and Campion (1997) identified the main components that improve interview reliability and validity: basing questions on job analysis, asking the same questions, rating each answer, using anchored rating scales, taking notes and training interviewers. Levashina et al. (2013) later summarised the evidence across 12 meta-analyses and reached the same broad conclusion: structured interviews are more reliable and valid than unstructured interviews.
Take a competency such as stakeholder influence. A weak framework says "influences stakeholders". A useful framework defines it as "secures commitment from people who have different incentives and no obligation to agree". The interview question then becomes: "Tell me about a time you had to win support from a stakeholder who initially disagreed with your recommendation. What did you do, and what changed?"
The scorecard should anchor the ratings. A score of 1 might mean the candidate gives no specific example, describes influence as persuasion by status or cannot show an outcome. A 3 might mean they give a real example, identify the stakeholder's concern and adapt their message, but the outcome is partial. A 5 might mean they diagnose the stakeholder's incentives, adjust the approach, secure a clear commitment and can describe the business result.
OPM's guide follows the same path when it moves from competencies to developing questions and rating scales from competencies. Salgado and Moscoso (2002) explain why behavioural formats matter: they assess job knowledge, job experience and situational judgement more directly than conventional interviews, which often reward polish, self-description and social fluency.
A simple competency framework template
A competency framework template should be boring in the best sense. It should make the next decision easier. Use one row per competency and force each row to connect language, evidence and assessment.
| Field | What to write |
|---|---|
| Competency name | A short label, such as stakeholder influence or analytical judgement. |
| Definition | One sentence describing the work behaviour, not a personality trait. |
| Observable behaviours | Three to five actions a strong performer repeatedly demonstrates. |
| Proficiency levels | What developing, proficient and excellent look like in role context. |
| Evidence sources | Interview question, work sample, reference check or performance example. |
| Scoring anchors | What a weak, acceptable and strong answer contains. |

This template also answers most of the common "what should a competency framework look like?" questions. The four broad types are usually core, functional, leadership and technical. The seven or nine core competencies people ask about online are not universal; they are examples, often including communication, collaboration, problem solving, adaptability, integrity, customer focus and leadership. The five Cs are usually a training mnemonic, not a law of nature. Treat any fixed list with suspicion until you have tested it against the work.
The same goes for competency framework examples. Borrow structure, not content. A healthcare framework, a sales framework and a school-leadership framework can share the same architecture, but the behavioural evidence should differ. "Manages risk" means one thing in safeguarding, another in enterprise sales and another in finance. The template should expose that difference, not sand it smooth.
How to install it without building an HR museum
The hard part is not developing a competency framework. The hard part is getting it used when a busy hiring manager is staring at three candidates, a half-empty calendar and a vacancy that should have been filled last month. This is where many frameworks become HR museum pieces: lovingly labelled, occasionally admired, never touched.
Installation needs an operating system. Each priority role needs a role scorecard. Each scorecard needs the few behavioural competencies that actually matter. Each competency needs a structured interview question and an anchored scale. Interviewers need to score independently before discussion. Hiring teams need a decision rule before the debrief begins, so the loudest opinion does not quietly become the method.
The evidence is not glamorous, but it is consistent. Campion, Palmer and Campion (1997) showed that structure improves the interview through small, concrete controls: job-related questions, common questions, answer-by-answer ratings, notes, training and anchored scales. Levashina et al. (2013) showed that the structured interview literature kept pointing in the same direction over time. The framework only earns its keep when it feeds those mechanics.
This is the problem the Structured Hiring Method programme is built to solve. HireSchool is a self-guided digital programme for small businesses and scale-ups that want consistent, evidence-based hiring without bringing in consultants. It turns the usual loose hiring process into a repeatable system: interview flow, capabilities tested, candidate assessment and decision mechanics, delivered through video content and a learning management system so every interviewer is working from the same method.
That matters because most companies do not fail at hiring through lack of intelligence. They fail because the process relies on private judgement. One manager tests problem solving, another tests likeability, a third asks about career goals and everyone meets afterwards to discuss "fit", that famously elastic word. A competency framework gives the hiring team a common language. Structured hiring turns that language into behaviour.
The aim is not to make interviewing robotic. It is to make it less arbitrary. A candidate should be assessed against the same role evidence as every other candidate. Interviewers should know which behavioural competencies they are testing and why. The debrief should start with scores and evidence, not impressions looking for a place to sit down.
Keep it alive
A competency framework is never finished. Roles change, markets change and the behaviours that predicted success two years ago may now be table stakes. The maintenance rhythm does not need to be elaborate. Review the framework after major hiring rounds, after performance calibration and whenever a role changes materially.
CIPD's warning about balancing detail with flexibility is the right closing caution. Too little detail and managers interpret the words however they like. Too much detail and the framework becomes a compliance object. TechTarget makes the practical point that organisations need to keep revising competencies as roles change.
Watch for three signals that the framework needs work. Interviewers cannot explain the difference between adjacent scores. Candidates are being marked down for style rather than evidence. Hiring teams keep overriding the scorecard because it "misses something". Sometimes that last phrase is just bias wearing a nicer coat. Sometimes it means the framework has not captured the real work.
Developing competency framework discipline is not about producing the perfect model. It is about improving the quality of repeated decisions. If the framework helps people ask better questions, score evidence more consistently and explain decisions without theatrical hindsight, it is doing its job. If it cannot improve a decision, it is decoration.