Field notes › Compliance

Building a competency matrix that survives contact with reality

Ask ten labour hire firms for their competency matrix and you get ten spreadsheets, all of which were accurate on the day they were built. The interesting question is not how to make one. It is how to make one that is still true a year later, after four new client sites, two regulation changes and a supervisor who quietly started accepting a different ticket for the same task.

Start from the site, not the person

The instinct is to list your workers down the side and their tickets across the top. That produces a picture of what you have, which is useful once, and tells you nothing about what you need.

The durable structure runs the other way. Start from the client site: what does this site require of anybody who walks through the gate? Usually that is a site induction plus a small number of tickets. Then the role: what does this particular job require on top of the site's baseline? The medic needs different paper to the operator. Then, occasionally, the shift: this one job needs something extra that the role does not normally need.

Three layers, each owned by someone who actually knows the answer. The site layer belongs to the client relationship. The role layer belongs to your operations people. The shift layer belongs to whoever took the booking. When a matrix goes stale it is nearly always because all three were flattened into one list that nobody owns.

Two kinds of ticket, and the difference matters

Some certificates never expire. Some renew. A matrix that treats them the same either nags people about tickets that do not need renewing, or lets renewable ones lapse silently.

DashboardON SITE NOW12UNFILLED SHIFTS3EXPIRING SOON5Expiring in the next 60 daysWorking at Heights · 2 workersRemindSite induction · 3 workersRemind12
The office dashboard: who's on site, what's unfilled, what's expiring.

Model them separately from the start: one-off tickets carry an issue date and no expiry, renewing certs carry an expiry that drives reminders. It is a small distinction that decides whether your reminder emails are useful or ignorable, and ignorable reminders are worse than none because they train people to skip the ones that matter.

Name things the way the site names them

A matrix accumulates near-duplicates: working at heights, work at heights, WAH, heights ticket. Each new entry gets created by someone in a hurry who could not find the existing one. Six months later you cannot tell whether two workers hold the same qualification.

Two habits keep it clean. Use the name the client site uses on their own paperwork, because that is the name that turns up in an audit. And make adding a new competency type slightly deliberate: a step that shows existing types first is worth the extra few seconds, because a merge later costs an afternoon.

What the regulator says is not what the site asks for

Some requirements are set by law: high risk work licence classes and their rules are the regulator's, and they vary by state, so check with the regulator rather than taking anyone's word for it, including ours. Other requirements are simply what the client asks for, which can be stricter than the law, or just different. Both are real, and both belong in the matrix.

Keeping them mentally separate helps when a client asks why a worker was turned away. It is a different conversation if the answer is the law requires it than if the answer is your own site rules require it, and if your matrix does not distinguish them, you cannot answer either way with confidence.

Make the matrix do work, or it will drift

Here is the real test. If your matrix is a reference document that someone consults when they remember to, it will drift, because nothing punishes it for being wrong. If the matrix is what the system checks before a booking is allowed, it cannot drift far, because the first wrong entry produces an argument the same week.

That is the case for wiring the matrix into the roster rather than keeping it beside it. In Mustr, required competencies live on the client site and the role, the check runs on the server before a booking is made, and a booking that fails is blocked with the reason named. When the matrix is wrong, somebody finds out immediately, and gets it fixed, which is the only maintenance regime that actually works.

Review it on a schedule, briefly

Once a quarter, take fifteen minutes: list the competency types nobody has used since the last review, list the sites whose requirements have not been touched since they were set up, and ask the operations lead whether either list looks wrong. Most quarters the answer is no. The quarter it is yes is the one that would have become an incident.

The compliance page covers how the checks read the matrix, and the certificates guide walks through the states a certificate moves through.

Bring one roster to the demo. We'll show you Mustr running it.

Book a 20-minute demo