Competencies

What competencies are

Competencies are the knowledge, skills and behaviours a role holder needs in order to perform the role at a defined level, described in observable terms rather than as general personal qualities.

The clause about observable terms is not a stylistic preference. It is what separates a competency framework that can be used from one that reads well and cannot be applied to a single decision.

A competency is not a skill

A skill is the ability to perform an act: using a piece of software, preparing a report. A competency is wider. It takes in the skill, the knowledge that supports it, and the behaviour through which it shows up in the work.

So “preparing financial statements” is a skill, while “accuracy under the pressure of a month end close” is a competency: it appears in behaviour that can be observed, not in a certificate. The distinction matters because the two are established by different evidence. A skill can be evidenced by a qualification or a test. A competency can only be evidenced by what somebody did, which is why competency frameworks and interview design are so closely tied.

What makes a competency description usable

A useful description carries three elements, and a description missing any of them will not survive contact with an actual decision:

• An observable behaviour, not a trait. “Documents the assumptions behind the report” works. “Accurate” does not, because two people can hold opposite views about whether somebody is accurate and neither can be shown to be wrong.
• A defined proficiency level. What distinguishes basic from advanced performance in this competency? Without an answer, every rating collapses into a general impression of the person, which is the thing the framework was built to avoid.
• Relevance to the role. A competency whose absence would produce no visible effect on the work has no place on the card. This is the element most often skipped, because adding competencies feels like thoroughness and the cost of a bloated framework is only paid later, by whoever has to rate against it.

The three work together. An observable behaviour with no proficiency levels tells a rater what to look at but not what to conclude. Proficiency levels attached to a trait rather than a behaviour give the appearance of precision to a judgement that remains an impression.

Three things that get written on a competency card and are not competencies

Each of these passes an informal review, because each of them is a real thing about the role or the organisation. What none of them supports is a rating that two people could arrive at separately.

• A value. Integrity, respect, ambition. These belong to the organisation’s statement about itself, and they fail the observable test in a particular way: nobody is ever rated low on one of them in writing, so the level carries no information and the column is filled in at the top for everybody.
• A qualification. A certificate is evidence, sometimes of a skill. Putting it on the card means the rating is settled by a document rather than by anything the person was seen to do, which is the substitution the observable requirement exists to prevent.
• A duty. “Prepares the monthly close” is a line from the job description wearing a competency’s clothes. It states what the role does. The card exists to state what the person needs in order to do it, and the two are the distinction the section below turns on.

Proficiency levels fail in one predictable way

The levels are the element most often written as intensifiers: basic means the behaviour appears sometimes, advanced means it appears consistently and to a high standard. That is a scale of adverbs, and it separates nobody, because two raters watching the same person will disagree about “consistently” and neither of them can be shown to be wrong. The disagreement then gets settled by seniority, which is the outcome the framework was built to remove.

A level that works describes a different behaviour, not the same behaviour performed harder. Basic might be documenting the assumptions when asked; advanced might be documenting the assumptions unprompted and flagging the ones a reader is most likely to challenge. Those are different observable acts, so the rating turns on whether an act occurred rather than on how impressed the rater was, and a rater who has never met the person can still check the evidence.

Where competencies get used

A competency framework is not a document that is written once and filed. Its output is used in four places, and a framework that reaches none of them was not built for a purpose:

• The structured interview, when the questions are derived from it. This is the most direct use, and the one that most quickly exposes a framework written in traits, because a trait does not convert into a question with a defensible scoring scale.
• Performance review, when the review items are built on it.
• Skills gap analysis, when the current level is measured against it.
• Career path design, when what is missing for a move is identified against it.

Each of those uses demands something slightly different from the same description, which is a practical argument for writing the description once and carefully rather than maintaining four overlapping versions that drift apart.

How competencies differ from a job description

A job description answers: what does the role holder do? Duties, responsibilities, scope. Competencies answer: what makes them able to do it? The first describes the work. The second describes what the work requires in the person.

This is why the two documents cannot substitute for each other, and why an organisation that has only the first finds itself unable to explain a hiring or promotion decision in terms of anything except the decision maker’s confidence. The job description establishes what the role is for. It does not establish what to look for in the people considered for it.

The failure mode that is hardest to see

The characteristic way a competency framework fails is not that it is wrong. It is that it is universal. A framework in which every role requires communication, teamwork, ownership and attention to detail is not describing any of those roles: it is describing an employee in general, and it will rate every person about the same because it was never capable of separating them.

The test is to take any two roles in the organisation and read their competency sets side by side. If the sets are close to identical, the framework has not yet done the only job that justifies its existence, which is to say what is different about each role. This shows up most sharply in succession planning, where the whole point is to know precisely what a critical role requires that a candidate to fill it does not yet have. A universal framework answers that question with a universal answer, which is no answer.

Keeping the framework current

Competency descriptions age in a specific way. The behaviours stay plausible while the work behind them changes, so the framework keeps sounding right long after it has stopped describing the role. A description written when a task was manual will still read sensibly once the task is automated, and will quietly be rating people on something that no longer forms part of the job.

The practical guard is to revisit the set whenever the role’s tools, scope or reporting line change materially, rather than on a fixed annual cycle. Those changes are recorded anyway, usually in the employee file and in the job documentation, so the trigger is available without setting up anything new to watch for it.

Related terms

• Succession Planning
• Structured Interview
• Employee File
• Employee Onboarding
• Candidate Experience