Competence Records Nobody Updates

The three kinds of drift

Upward drift: somebody has become competent and the record does not say so, which hides capacity and keeps a constraint alive after it has been removed.

Downward drift: somebody has not done the task in two years, or an authorisation has lapsed, and the record still says yes. And structural drift, where the task itself has changed and the competence recorded against it no longer describes the work.

Which one hurts most

Downward drift is the one that produces incidents, and upward drift is the one that costs money every week without anybody noticing.

Most organisations check for the first and ignore the second, which means their records are safe and expensive. A matrix that has not recorded a new competence in eighteen months is not stable; it is unmaintained.

The ten-minute routine

Once a month, with the matrix open and the last month's rota beside it:

• Anybody who completed training, add the capability with the date.
• Anybody who has not performed a capability for the stated refresh period, flag it rather than removing it.
• Anybody who joined or left, add or close the row.
• Any capability where the number of holders changed, note the new total.

Ten minutes, and it is the entire maintenance requirement. The reason it does not happen is that nobody owns it, not that it is onerous.

Flag rather than delete

Removing a capability because somebody has not used it recently is both harsh and operationally risky: it reduces apparent capacity overnight and provokes a dispute about the record rather than about the skill.

A flag starts a conversation: has this person done this recently, do they want a refresher, is the refresh period realistic for this task. All three questions are useful and none of them follows from a deletion.

Who should hold it

Whoever builds the rota, not the training function. The training function owns courses; the rota owns capability, and the two records are different documents with different update rhythms.

Where they are merged, the matrix updates at the speed of the training system, which is usually annual, and the rota is built from a year-old picture.

The record and the system

Scheduling systems hold skills and frequently hold them badly: a flat list, no expiry, no supervised state, filled in at implementation and never since.

Where the system cannot hold what the matrix needs, keep the matrix beside it rather than degrading the matrix to fit. The system then enforces what it can, and the person building the rota checks the rest.

Self-assessment as an input

Asking people to rate their own capability annually produces better data than asking managers, on one condition: that nothing is attached to the answer.

The moment a self-assessment affects pay, allocation or appraisal, it becomes a negotiation and the data stops describing capability. Keeping it purely operational is what makes it worth collecting.

The new starter problem

A new person's capabilities are unknown for the first few months, and the record usually says nothing, which the rota reads as cannot.

A deliberate assessment at six weeks, recorded, is worth more than anything else in this section for a team with turnover. Without it, every new person is invisible to the rota for considerably longer than they need to be.

What to do once a year

Rebuild the column totals from scratch rather than updating them: count holders per capability against the current team list, and compare with what the matrix claims.

The differences are the drift, and in most teams there are five or six of them. An hour a year catches what the monthly routine misses.

Why this is a constraint page and not a training page

Because the record is not an HR artefact here. It is the thing that decides which shifts can be built, and every error in it shows up as a constraint that either does not exist or is not where the rota thinks it is.

A rota built from an accurate matrix is a different object from one built from memory, and the difference costs ten minutes a month.