Competency Management That People Actually Use

Somewhere in most large organizations there is a competency framework with several hundred entries. It was commissioned a few years ago, delivered as a PDF and a spreadsheet, launched with a communications plan, and is now consulted once a year during appraisal season by the people who remember it exists. Nobody defends it. Nobody deletes it either, because deleting it would require admitting what it cost.

The framework was not wrong. It was built as a description of the organization when it needed to be an instrument for making decisions, and those two things have almost nothing in common.

The test a framework has to pass

For every entry, someone should be able to name the decision it informs. Staffing a project. Approving training spend. Deciding whether to hire or develop. Deciding who is allowed to sign off a piece of work. Deciding what a promotion actually requires, in terms specific enough that two managers would reach the same conclusion.

If no decision can be named, the entry is documentation. Documentation is not worthless, but it does not justify the cost of keeping it current, and in practice it will not be kept current. A framework of two hundred entries where sixty inform decisions is worse than a framework of sixty, because the ratio teaches everyone to ignore the whole thing.

Why the four-hundred-item framework dies

• Nobody can hold it in their head. A manager who cannot recall the vocabulary falls back on their own, and within two quarters the organization has as many frameworks as it has managers.
• The granularity does not hold. Frameworks routinely list “communication” and “configuring OAuth flows” as peers. One is a career, the other is an afternoon.
• Ratings are annual and self-reported, so the data is a negotiation rather than evidence. Everyone learns the score that produces the outcome they want.
• There is no owner. Entries persist for tools that were retired two years ago, and nothing new gets added without a project.
• It is disconnected from anything anyone does weekly, which means it competes with real work and loses.

What to build instead

Start from roles, not from the organization chart

A role profile with eight to twelve competencies is usable. A person can read it, recognise themselves in it, and see what the next role requires. Build those profiles for the job families where staffing decisions are painful today, and leave the rest alone until someone asks. Resisting the enterprise-wide launch is the single highest-value decision in this whole exercise, and it is the one most programmes get wrong.

Describe behaviour, not adjectives

“Advanced stakeholder management” means whatever the reader wants it to mean. “Can run a requirements workshop with a client who disagrees internally, and leave with a written scope both sides accept” can be observed, disputed, and evidenced. The levels underneath each competency need the same treatment, which is a longer subject in its own right — defining levels that mean something is where most frameworks quietly fall apart.

Get evidence from work, not from a form

A rating should carry a source and a date: an assessment result, a manager observation against a defined checklist, a piece of delivered work, a verified credential. Once every rating has provenance, disagreements become productive, because two people are arguing about evidence rather than about each other’s judgment. This is the difference between a survey and measured skill data, and it is the difference that decides whether anyone trusts the output.

Give it an owner and a release cycle

A framework is a product. It needs a named owner, a version number, a change window a few times a year, a deprecation path for entries being retired, and a mapping from the old vocabulary to the new so historical data survives the change. Without a release process, the framework is accurate on launch day and decaying from the day after.

The manager test

Two months after launch, take a real question to a line manager: there is a data migration for a regulated client starting next quarter, and you need two people who can run it. If the system answers that question with names, evidence and gaps, the framework is alive. If the manager answers from memory and then updates the system afterwards to match, you have built a record-keeping obligation.

The same test applies to development. A person who asks what they would need to reach the next role should get a specific, short, ordered answer — not a list of twenty competencies at level three. Reducing that answer to the two or three things that actually block progression is what gap analysis is for, and it is the moment most people first find the framework useful rather than administrative.

What to give up

Some precision, deliberately. A coarse framework that managers use beats a precise one they route around, and the fastest way to lose adoption is to demand a level of detail that only the people who wrote it can sustain. Complete coverage is also worth giving up early. Starting with the job families where hiring is hardest produces evidence of value; starting everywhere produces a two-year programme with a steering committee.

Underneath all of this is a single idea. Competency management is not an inventory exercise, it is a decision-support system that happens to be built out of vocabulary. Judge it the way you would judge any other system: by whether the decisions it touches get made faster, more consistently, and with fewer surprises six months later. If you are rebuilding one, how we model competency management is designed around that assumption rather than around annual reporting.