Competency framework: what it is, why to build one, and examples

What a competency framework actually is

A competency framework is a structured list of the behaviours, skills, knowledge and attributes a person needs to do a specific role well. The list is usually grouped into a small number of clusters, sometimes layered with proficiency levels, and ideally tied to the decisions the company actually makes about people. That is the plain-English version, and it is the one worth holding on to. Most of the longer definitions on the internet are saying the same thing in more words.

The vocabulary trips people up. "Competence" describes the output - whether the job gets done. "Competency" describes the input - the behaviour that produces the output. Some sources insist on the distinction; others use the words interchangeably. The same artefact also goes by competency model, capability framework, or competency model framework. Treat the labels as background noise. They all answer the same question: what does great look like in this role, in observable terms?

A useful definition that will not embarrass you is the one Indeed and TechTarget converge on - the structured set of skills, knowledge, and behaviours required to perform a role, applied across the company so that the same standard governs hiring, performance reviews, and promotion. The CIPD adds a sharp caveat in their factsheet: a competency framework, done well, can deliver clarity around performance expectations and a clear link between individual and organisational performance. The phrase to underline is "done well".

Because the failure mode is specific, and most readers will recognise it. A competency framework that lives in a SharePoint folder, never opened, never referenced in an interview rubric, never consulted at promotion time, is not a competency framework. It is a document. The artefact only earns its keep when it shows up at the decision points - the interview script, the scorecard, the performance review template, the promotion calibration meeting. The rest of this article is about how to build the kind that does.

Where competency frameworks came from

The intellectual root is the late David McClelland, a Harvard psychologist who argued in 1973 that intelligence tests were systematically missing the things that actually predicted job performance. His remedy was to study what outstanding performers in a role actually did - the operant behaviours, in his language - rather than scoring them against an abstract scale. The Behavioral Event Interview, codified properly by McClelland (1998), is the technique that emerged: a structured conversation in which incumbents describe specific positive and negative episodes at work, in their own words. The transcripts are coded for patterns. The patterns become the competency model.

McClelland's 1998 paper is the one to read if you want to see how rigorous this can get. He coded twelve recurring competencies across more than thirty organisations and showed that they discriminated between outstanding and typical executives well above chance. The consulting industry, McBer chief among them, took the approach commercial. By the late 1990s, large organisations had bought competency dictionaries and turned them into the comprehensive frameworks we now recognise.

A separate idea often gets confused with this one, and it is worth clearing up because Google ranks it on the same page. The four-stages-of-competence learning model from the 1960s describes how a person learns any new skill: unconscious incompetence, conscious incompetence, conscious competence, unconscious competence. It is a learning curve. A competency framework is a behaviour matrix. They are not the same thing, do not solve the same problem, and only get bundled together because both happen to use the word "competence".

Which raises the obvious question. If McBer-style dictionaries already exist, and large organisations have spent thirty years buying them, why does every company still need its own framework? The short answer is that McClelland himself flagged the limit in his data: a competency model that predicts success in one role does not necessarily predict it in another. The work that matters is local. The next section is about what gets put inside.

What goes inside a framework

Most competency frameworks have three working parts. Behavioural competencies describe how people work - how they communicate, decide, influence, deliver. Technical competencies describe what they know - the role-specific knowledge a software engineer or a finance manager needs to do the job. A third layer, sometimes called core or leadership competencies, applies across the whole company and captures the behaviours expected of everyone, regardless of role. Behavioural competencies are the part most readers underestimate. They are also the part that does the work in interviews.

A common search query asks for the five components of competency, as if there were a canonical list. There is not. The components most frameworks share are some combination of skills, knowledge, behaviours, attributes, and sometimes values. The names are less important than the discipline of separating observable behaviour from claimed knowledge. "Communicates clearly under pressure" is a behaviour you can score. "Strong communicator" is a label that moves no one closer to a decision.

Proficiency levels are the next decision. Many frameworks layer foundational, capable, advanced, and expert; others use a numeric one to five. Both work, in principle. McClelland (1998) flagged a useful caution in his Tastyfood data: most competencies do not relate to performance on a smooth gradient. They have tipping points. For Impact and Influence, fifty-five percent of outstanding executives showed a frequency of eight or more, against twenty percent of typical executives. Below the threshold, frequency barely mattered. Above it, it mattered a lot. A framework graded on a 1-5 Likert with no threshold logic is missing the structure of the underlying signal.

A worked example helps. McClelland (1998) coded twelve competencies that recurred across thirty organisations: Achievement Orientation, Analytical Thinking, Conceptual Thinking, Developing Others, Flexibility, Impact and Influence, Information Seeking, Initiative, Interpersonal Understanding, Organisational Awareness, Self-Confidence, and Team Leadership. Each differentiated outstanding from typical executives in roughly forty to seventy percent of comparisons - well above chance, but with enough variability to make the point that no single competency is universal. Campion, Palmer and Campion (1997) reached the structural counterpart: their fifteen components of interview structure are the operational scaffolding that lets behavioural competencies do their work in the interview room.

The point of these examples is not to copy the lists. It is to notice that they were derived from evidence, not from a workshop with sticky notes. A small business does not need thirty organisations of data. It does need to look at its own outstanding people and ask what they actually do.

Why a competency framework actually matters

The strongest argument is unglamorous. A competency framework is what makes a structured interview structured. Without one, your "competency-based interview" is whatever the loudest interviewer in the room remembered to ask. The questions drift, the scoring drifts, and two interviewers leave the same conversation with different impressions of the same candidate. The framework is the spine. Take it away and the interview falls over.

The evidence for structure is not subtle. Levashina, Hartwell, Morgeson and Campion (2013) summarised twenty years of research and twelve meta-analyses, and concluded that "one of the most consistent findings in the history of research on the employment interview is that structured interviews are much more reliable and valid than unstructured interviews." Structured interviews also add validity on top of personality tests and cognitive ability tests, because they measure something different. McClelland (1998) provided the case study that puts a number on it. At one large multinational, executive turnover ran at forty-nine percent under traditional hiring. After the company moved to selection by competency algorithm, turnover dropped to six point three percent. The savings, calculated against the company's own per-executive replacement cost, ran into millions.

Then there is the failure mode, which the reader will recognise. A framework gets built by HR, in isolation, with the best of intentions. It is comprehensive. It has levels. It is reviewed in a kickoff meeting and then never again. The failure mode where frameworks become HR documents nobody opens is the default outcome when the framework is not anchored to a decision. Employees do not experience their work through a competency list. Managers do not consult one before a tough call. The framework becomes paperwork, and the company concludes, wrongly, that frameworks do not work.

The fix is to tie the framework to four decisions and stop there. Hiring, where the competencies become the interview rubric and the scorecard. Onboarding and performance, where they describe what good looks like in the role for the first ninety days and after. Promotion, where the next level is defined by the competencies that change. Learning and development, where the gaps decide where time and money go. A framework that earns its keep is one that you cannot avoid using. Anything broader than those four uses is usually decoration. As a side benefit, candidates and employees finally get something honest to plan against, and retention quietly improves. But the decisions are the point.

Worked examples of competency frameworks in the wild

The fastest way to understand what a competency framework looks like is to look at a few that already exist. None of these is a template to copy. They are reference points - useful for noticing what good frameworks share, and where they differ.

The U.S. Department of Labor publishes a five-tier pyramid covering personal effectiveness through sector-specific specialisations. The bottom layer is generic and applies to every working adult: punctuality, integrity, basic professionalism. The middle layers add academic competencies, then workplace competencies (problem-solving, teamwork, planning), then industry-wide technical skills. The top layer is specific to a single occupation. The structure is heavy, but the logic is clear: the framework gets more specific as you climb. A small business that wanted a starting structure could borrow the pyramid and ignore most of the content.

SHRM, the Society for Human Resource Management, publishes a different shape. Their framework lists SHRM's eight HR-specific competencies - leadership and navigation, ethical practice, business acumen, consultation, critical evaluation, relationship management, communication, and global and cultural effectiveness, with a ninth, analytical aptitude, added more recently. It is flat, not tiered, and oriented around a profession rather than a company. Useful as an off-the-shelf example for an HR leader; not useful as a finished framework for anyone else.

Intercom, the customer-communications company, publishes a tiered competency framework for its customer support team. Roles progress through beginner (post-onboarding), practitioner, and advanced, each with concrete behavioural anchors: a practitioner showcases a thorough understanding of product and technical concepts, consistently tags and categorises issues, and responds well to constructive feedback. The example is worth flagging because it is small, public, and recognisably operational rather than aspirational. The U.K. Civil Service runs a similar shape, with a small core set such as seeing the bigger picture, delivering value for money, and leading and communicating, applied across grade levels.

Look across these examples and the family resemblance is obvious. Strong frameworks have a small number of competencies, rarely more than twelve. Each level has behavioural anchors you could observe in an interview. Each competency is tied to a job family or a role grade rather than floating in the abstract. The "core competency framework" sometimes referred to in HR literature is just the subset that applies to everyone in the organisation; the role-specific layers sit on top.

None of this is a finished product for your company. The work is adapting an example to your roles, your seniority bands, and the behaviours your outstanding people actually show. The good news is that the adaptation is the point. The bad news is that nobody else can do it for you.

How to install a competency framework that earns its keep

By this point the argument is settled. A competency framework matters; the examples exist; the failure mode is well understood. The hard part is not picking a template. The hard part is making sure the framework actually shows up at the decision points - the interview, the scorecard, the performance review, the promotion conversation. A framework that lives anywhere else is an artefact, not a tool.

HireSchool exists to install that bit. It is a self-guided digital programme called the Structured Hiring Method, delivered as video content plus a learning management system. Customers buy access and run it themselves; there is no consultant on the side and no bespoke advisory engagement. Inside the programme, the team learns how to codify a small set of behavioural competencies for each role, write the structured interview questions that test for each one, score the answers consistently across interviewers, and reach a defensible decision at the end. Every interviewer in your business hires to the same standard, because they have all been through the same training and they all use the same kit.

Where a generic competency framework template stops at the list, the Structured Hiring Method walks the team through what to do with it. The codified scorecard is the place the framework lives in the interview. Behavioural interview training is how interviewers learn to ask questions that actually test the competencies, not vague ones that test confidence. Decision management is how the panel consolidates scores into a call without descending into a discussion of who liked the candidate most. Leadership Values sit on top, defining the core competencies expected of everyone, regardless of role. For businesses that can support it, a Quality Assurance module checks that interviewers are running the process the way they were trained. The underlying standard is First Past the Post: the first candidate who clears the bar gets the offer, rather than the panel waiting for the unicorn.

HireSchool is not consultancy. It is not an applicant tracking system. It is not a recruiting agency. The customer learns the method and runs it; HireSchool provides the structure and the kit so the framework stops being a document and starts being part of the operation.

If your competency framework currently lives somewhere other than your interview rubric, the next step is to explore the Structured Hiring Method programme and see how the framework, the questions, the scorecard, and the decision mechanics fit together. The version where HR builds the framework alone, distributes it, and hopes - the version where HR builds the framework alone is the default failure mode that most articles on this topic warn against, including the practical guides that Mindtools and others publish - is precisely the one this is designed to replace.

The fix is consistent across every credible piece of work on the subject. Design the framework and the decision process at the same time. Train the people who will use them. Then run the process the same way every time. That is the whole installation.

The shape of a framework that works

The argument fits in two sentences. A competency framework is the behaviour list that anchors structured hiring and consistent performance management. Done well, it makes decisions easier to defend; done badly, it becomes paperwork. The difference is mostly in whether the framework is tied to anything that the company actually does.

A few practical heuristics fall out of the evidence. Keep the list short - under twelve core competencies for most companies, fewer for small ones. Make every line behavioural rather than aspirational; if you cannot picture an interviewer scoring it, rewrite it. Anchor each level with observable evidence, not adjectives. And connect the framework to at least one decision before you add another. McClelland (1998) demonstrated the power of the approach when it was tied to selection; Levashina, Hartwell, Morgeson and Campion (2013) confirmed that the gain holds across two decades of structured-interview research. Frameworks built without the decision they serve in mind tend to drift back into the SharePoint folder.

Search engines like to ask about the seven core competencies, as if there were a definitive list. There is not. Most companies converge on a handful that cover communication, judgement, ownership, and the role-specific technical bar, with one or two leadership-flavoured items added for senior roles. The number is less important than the discipline of writing each one in a way two interviewers could score the same way.

Which is the test that matters. Pick one role. Write the competencies. Run a structured interview against them next week, with two trained interviewers in the room. If both interviewers reach the same call, the framework is doing its job. If they do not, the framework is what needs fixing - not the candidate, and not the interviewers. Frameworks are made by use, and that is the only place they can be repaired.