A competency framework and a job description are not the same document

An HR head at a 700-person manufacturer sent me two documents about the same role. The job description ran to three pages and placed "decision making" at level 2. The competency framework, a separate forty-page file that L&D owned, placed the same competency at level 3 with a paragraph of behavioural anchors underneath it. Both had been revised in the same quarter, by different people, in good faith.

She wanted to know which one was right. The better question was why there were two.

That company had 38 job descriptions and 9 competencies, and 31 of the 38 JDs repeated framework text inside themselves. Every framework revision created 31 manual edits, most of which nobody made. This is the ordinary state of the pair, not a lapse in discipline. Two documents that both describe a person at work will always be written into each other unless someone draws a line and holds it.

Here is where the line goes, why the overlap keeps happening, and how to keep the pair in sync with a reference instead of a copy.

What each document is actually for

A job description is a scope document. It answers: what is this role accountable for, who does it report to, what decisions can it take without asking, what qualifications or licences gate entry, and what conditions of service attach to it. It is the document a hiring manager reads before an interview, the one an auditor asks for, and the one a new joiner is given on day one.

In India part of that content is not optional. The Industrial Employment (Standing Orders) Act, 1946 applies to industrial establishments employing one hundred or more workmen, and the model standing orders under the Central Rules require a written classification of workmen into permanent, probationer, badli, temporary, casual and apprentice, plus hours of work, holidays, leave, misconduct and termination. None of that is a behaviour. No competency framework can discharge it, and a framework that tries will be read by a certifying officer as an evasion.

A competency framework is a measurement instrument. Its unit is a behaviour that two observers can watch in a normal week and rate the same way. Its output is a comparison: this person against that person, this person against last year, this team against that team. That is the whole job, and it is a different job from describing scope.

The confusion is understandable, because the two documents share a subject. Both say something about a role and the person in it. Sharing a subject is not sharing a function.

The overlap is structural, not accidental

Look at how the duplication gets created. Someone writes a job description. A section called "competencies required" gets bolted on, because the template has a field for it and the recruiter wants something to screen against. Into that field goes a list of adjectives: good communicator, team player, result oriented.

Then the framework project starts. The fastest source of behavioural content is the pile of job descriptions, so the consultant harvests the adjective lists, consolidates them into nine competencies, and writes anchors. The framework is now downstream of the JDs. When the framework changes, the JDs are stale. When a JD is rewritten, the framework is stale. Nothing in either document points at the other, so nobody notices for a year.

Buying a classification does not fix this, and the scale of the public ones shows why. ESCO, the EU classification, carries descriptions of 3,039 occupations and 13,939 skills. O*NET in the United States holds over 900 occupation profiles, and its work activities hierarchy alone links more than 19,000 task statements to over 2,000 detailed work activities, which roll up into 325 intermediate activities and 41 generalised ones. Those are dictionaries. A dictionary tells you what words exist. It does not tell you which nine your managers can actually rate.

The test: can it be rated?

Put every line of both documents through one question. If a line can be turned into a scale that two managers score the same way, it is framework content. If it is a yes or no about scope, authority or qualification, it is job-description content. If it is neither, it is decoration and should be deleted.

Three sub-questions make the first one usable in a room full of people:

1. Is the answer binary or graded? A licence is held or not held. "Handles a customer escalation without escalating the relationship" is graded.
2. Can you name a moment from the last month? Not a hypothetical. A specific Tuesday.
3. Would two managers watching the same moment give the same score within one level?

A line that fails question 3 is not a competency, it is an aspiration. A line that fails question 2 is a slogan.

That table settles most arguments in under an hour, because the "neither" column is usually the largest and nobody defends it once it is named.

The method, in the order the work happens

Step one: freeze the JD to four fields. Accountability, authority, entry gates, and conditions. Rename the "competencies required" section to "competencies assessed" and empty it. Nothing else in the JD changes. Do this for all JDs in one pass, because a half-migrated set is worse than none.

Step two: give every competency a stable ID. Not a name, an ID. CF-07 survives a rename; "Collaboration" does not. The ID is the join key between the two documents, and it is the only reason the reference approach works. Your framework build should already have produced these; if not, add them as a column in whatever file the framework lives in.

Step three: put a reference line in the JD, not the behaviour. One sentence near the end: "Behaviours for this role are assessed against CF-03, CF-07 and CF-11; see the framework." Three IDs, no anchors, no levels copied over. The levels for a role belong to the role, not to the competency, so if a role sits at a different level on a shared competency, that belongs in a role-level column in the framework file, keyed by role and competency ID. One place again.

Step four: run the duplicate sweep. Take every JD and search for any phrase longer than six words that also appears in the framework. Delete it from the JD and leave the ID. Expect the sweep to remove most of the "competencies" section and a good deal of the duties section, because duty prose written by a manager tends to drift into behaviour prose.

Step five: audit drift quarterly, on a sample. Five JDs, ten minutes. For each, check that its competency IDs still exist, that its role-level entries still match the framework, and that no behaviour text has crept back in. Record the date and the five roles audited. This is the whole maintenance regime, and it fits in a single line of a recurring calendar entry.

What it looks like when it works

Illustrative, not a benchmark. A 700-person auto components firm: 38 JDs, 9 competencies, 4 levels. Before the split, a framework revision created 31 JD edits and a JD revision created a rework of the framework annexure. After a two-week migration, each JD carried three or four competency IDs, the framework file held a role-by-competency matrix of 38 rows and 9 columns, and the JD bodies lost about 40 percent of their word count. The next framework revision produced 4 edits, all inside one file that one person owned.

The cost was in the argument, not the work. Two of the four levels had to be redefined because, once the anchors sat alone in the framework with no JD prose to lean on, managers realised they could not tell level 2 from level 3. That is the framework improving under pressure, which is what you want. Duplicated text had been hiding the weakness.

The honest limits

This keeps two documents consistent. It does not make the framework valid. Consistency is a documentation property; validity is evidence that the competencies predict something, and that needs a criterion study with an independent outcome. Do not let a tidy migration stand in for that.

It does not help if the framework is used for pay. The moment levels drive salary bands, managers rate to the budget, and the document stops measuring. Job evaluation is a separate exercise with its own method.

It is also not a recruiting win by itself. A 2014 study by Hawkes and Weathington put 258 undergraduate job seekers in front of competency-based and task-based descriptions and found no difference in attraction to the organisation. So do not rewrite job descriptions into competency language in the hope that candidates prefer it. They do not, on that evidence. Write the scope clearly and let the framework do the measuring.

And the migration is a bad fit for one case: a company of under about forty people where one incumbent holds each role. There, the framework is already small and the JD is the only document anyone reads. The split still applies in principle, but the reference line adds a lookup step that buys nothing. The sizing rule for a small company is the better starting point, and the build method for a larger one covers the framework side.

What to do this week

Open your own job description for the role you know best. Highlight every line that is a behaviour. That highlighting is your duplication, and it is probably a third of the page.

Then take one competency that appears in more than three JDs, give it an ID, and replace its text in those JDs with the ID. Three JDs, twenty minutes, one competency. Check in a month whether anyone asks where the text went. Nobody will, and the reference will still be true.

When you are ready to do the full pass, start from what the platform assesses and how levels are recorded, so the ID you insert in the JD points at something that exists rather than at a spreadsheet only one person can find. If your framework already produces clean outputs, map each item to one competency before the data lands and the IDs will hold.