Two competencies overlap: merge them without losing history

The HR analyst sent the revised framework on a Friday. Fourteen competencies became twelve. "Customer focus" and "Communication" were merged into "Customer communication", because the two had overlapped. Sensible. Cheaper to assess. Easier for managers.

On Monday the plant head opened his talent review and found every manager in his unit had dropped about a third of a level. Nobody had changed. The framework had. Because the old scores lived only as competency averages, there was no way to show the drop was arithmetic, and no way to tell whether the two people below the line were worse than last year or just measured differently. The merge had deleted its own evidence.

That is the failure this article is about. Not whether to merge two overlapping competencies. You will have to. The question is how to do it so the numbers on either side can still be compared and audited.

Overlap lives in the item bank, not the definitions

Most teams diagnose overlap by reading definitions side by side and deciding they sound similar. That test is close to worthless, because competency definitions are written to be broad. A definition narrow enough to be mutually exclusive with its neighbour is also narrow enough to be hard to observe.

The overlap that causes trouble sits one layer down, in the items. The same behaviour gets written into two competency maps, both ratings are collected, and the same evidence is counted twice. That is not a flaw unique to your framework. Campion and colleagues, reviewing practice across Boeing, Microsoft and the SIOP task force, note roughly 80% overlap between models built for similar positions in different organizations, and observe that most competency dictionaries cannot be called taxonomies because their items were never shown to be exhaustive or conceptually independent.

So the merge decision has to be made on the item bank. Pull the rows. Count them.

Test the overlap before you name the merge

Four tests, cheapest first. Run all four, because each fails in a different direction.

The correlation test needs the most care, because it is the one people trust and the one that misleads. In a twelve-station assessment centre where every station rated the same ten competencies, Monteiro and McConnell found correlations between different competencies rated in the same station averaging 0.60, while the same competency across different stations averaged 0.19. The context carried the correlation, not the construct. If your 360 shows "Customer focus" and "Communication" at 0.7, the honest reading is that one rater watched one person in one setting. That is a reason to look at the items, not a reason to merge.

The unique-evidence test decides the merge. A competency with no items of its own is a label, not a construct, and folding it in costs nothing. One with fourteen items nobody else has is measuring work you would bury.

Decide what happens to the shared core

Overlap is not a verdict that two competencies are the same thing. It says their item banks share a core, and the residue decides the structure. Three outcomes are defensible, and they are not interchangeable.

Absorb. One competency has no unique items. Move the shared core into the surviving competency, retire the empty one. This is the only case where a true merge is honest.

Split by residue. Both have unique items and the residues are different behaviours. Keep both, move the shared items to whichever owns the decision they inform, and stop collecting them twice. Nothing is retired. The framework gets shorter by rows, not by names.

Rebuild one side. The residues describe genuinely different work, so the shared core was mislabelled from the start. Retire both names and write two that describe what the items observe.

Most real cases are the second. The Friday merge applied the first to a case that was the second, which is why it broke.

Retire the ID, never delete it

A competency that has ever been rated gets retired, not deleted.

SAP's guidance on its SuccessFactors competency libraries says it directly: do not delete a library used in the past, because it leads to issues on historical forms. Every other system behaves the same way. Delete the row and the old appraisal form loses the label its scores were stored under. What remains is a number with no question attached.

A retirement needs five fields, in the framework document rather than someone's inbox:

1. Retired ID, unchanged from the live one. Never reuse it.
2. Retirement date, the date the new version goes live for data collection.
3. Successor, the competency or competencies that now carry its items.
4. Item disposition, row by row: moved, deduplicated, or dropped.
5. Baseline status, either restated with item-level history, or marked as a break.

That last field saves the plant head's Monday. With item-level history you can recompute last year's score on the new item set and the comparison holds. If you stored only competency averages you cannot, and the honest move is to print "new measure, baseline from <date>" on every report that crosses the merge. A labelled break is not a failure. An unlabelled one is a false trend.

A crosswalk is a link, not an equating

It is tempting to adjust the old average to the new one so the series looks continuous. Whether that is legitimate has a standard, and it comes from test equating rather than HR.

ETS's principles of test score equating set the bar: equating requires the two forms to measure the same construct at almost the same level of difficulty with the same degree of reliability. Weaker links, including prediction, cannot stand in for it, because they produce scores that are not interchangeable.

Applied here:

• Item set unchanged, only the label moved: same measure. Restate freely, no crosswalk needed.
• Item set changed but construct and difficulty held: you can link, and you must say so. A crosswalk with an adjustment and a note is a link.
• Construct changed, which is what a real merge does: nothing to equate. Report a break.

The professional failure is not the break. It is a crosswalk presented as if it were an equating, so a manager reads a linked number as a measured one.

Worked example: 47 rows, two competencies, one honest split

Illustrative numbers for a 240-person equipment services company. Take the shape, not the values.

"Customer focus" carried 22 items and averaged 3.40 last cycle on a five-point scale. "Communication" carried 25 and averaged 3.10. Eleven escalation-handling items appeared in both maps, scoring 3.60 on average.

De-duplication alone moves the combined figure from 3.24 to 3.13. Nothing about any person changed. Build your first post-merge report by averaging all 47 rows and you have manufactured a 0.11 decline you will spend a quarter explaining.

The item-level view changes the decision. The eleven shared items are about handling an escalated customer complaint. The fourteen unique to "Communication" are about written shift handover: log entries, defect notes, the sheet the next shift reads. Those are not the same behaviour. This is a split by residue, not a merge.

So "Customer focus" keeps its 22 rows and its 3.40 stands unchanged: its item set did not move, so the number stays comparable, which is the whole point of working at item level. The fourteen handover items become "Shift handover and written records", with a restated baseline of 2.71 computed from those fourteen alone.

That is lower than the old "Communication" average and correct, because the old average was inflated by eleven items that had nothing to do with writing. Carrying 3.10 forward would credit the new competency with evidence it does not collect. Had the company stored only the two averages, the new one would start at 3.10 by inheritance and the first year's honest 2.9 would read as decline. Store items.

Say it in the same week the framework changes

Managers do not resist framework changes. They resist unexplained movement in their numbers. Two sentences in the release note do most of the work: "The handover items are now their own competency. Your customer focus score is comparable with last year; your handover score starts fresh from this cycle." One line per affected competency, with the date.

If a platform holds the framework, the items and the evidence together, the retirement and crosswalk are fields rather than a document, and the report carries the break automatically. That is the practical case for keeping assessment and framework data in one system instead of a spreadsheet plus three vendors. If your tools cannot hold a retired ID, attach the crosswalk to every report that crosses the merge.

Two habits make this cheap: every item gets exactly one competency row before any data lands, and you version the anchors rather than the spreadsheet.

Where this advice fails

Merging on item evidence assumes you have item-level history. Most HR systems store the competency average and discard the rows, and that history cannot be rebuilt retroactively. Accept the break, label it, and start storing rows now so the next merge is cheap. Do not reconstruct item history from memory in a workshop: that produces a number nobody can defend and everyone will use.

It also assumes the residues are real behaviours. In a small firm where the sales lead, the service lead and the ops lead are the same three people, competencies overlap because the work overlaps, and merging two changes nothing about how anyone is managed.

And a merge is not free even when it is right. Every retired label costs a report template, a manager conversation and a line in the HRIS. If both competencies still earn their place in performance conversations, the cheaper fix is to stop collecting the duplicate rows. Purity is not the goal. A framework survives when its numbers can be traced, not when no two items brush against each other.

Do this before the next cycle

Export the item map for the two competencies you suspect overlap. Count rows, shared rows and the union. Compute the score three ways: both maps as stored, distinct items only, each competency on unique items alone. The gap between the first two is the arithmetic you have been reporting without knowing it.

Write one line per competency: absorb, split by residue, or rebuild. Name the successor and the retirement date. Then check the thing that decides whether any of it survives contact with a report: does your system hold last cycle's item rows. If yes, restate the baseline in the same sitting. If not, print the break, and fix the storage before the next merge makes the point again.