It certainly can be window dressing if you don’t do it right. But no, it isn’t — and if we look at Texas City, there is a great example of why it matters.

In that instance the site and the company had all the infrastructure in place — all the hardware, all the systems. However, there are some key things that come out of the whole competency space from that tragic incident.

If we step back and look at what actually happened, there were examples on the day of the disaster of operators arriving late, leaving early, family emergencies, that sort of thing. It became a juggling act to have the right people on site while a very important process was underway — and also when things went sideways on that very important process.

You don’t have all the time in the world when things are unravelling like that. It wasn’t the only factor at Texas City by any means — others will argue there were much more important things — but it is one of the backbone things. We like to think of these things and barriers in terms of dominoes, and it is one of the dominoes that fell and allowed the next ones to fall also.

That’s the gap we try to close with a good, robust competence assurance process. And we then have to check on it regularly — you can’t just put it in place and sit and forget. But then we really know we have that barrier in place, and the steps, and the people who know what to do when things go wrong.

It is tempting to break these things down into one big thing, but quite frequently they are more complex than that. I see three recurring mistakes:

• —People mix up training and competence. Training is important, but it is not the same thing.
• —Organisations end up feeding the system. They set up competence management and then spend all of their effort, focus and concern on making sure the system has been fed the necessary information.
• —The tendency to over-complicate. Gathering more detail does offer more precise insight, but it also leads to fatigue — and we don’t win when people lose interest.

On the second point: the system should work for the people. Of course you have to set it up, but the end goal is that it helps keep you safe, not that you keep it up and running.

On the third: depending on the sector, the site and the culture, competency management can be sliced and diced in so many different ways, and it is tempting to try to capture everything. There is a lot of stakeholder management and a lot of opinions on the table. It is very easy to put them all into the system — and much harder to then deliver good, robust assessments if people have to go through something like 2,000 checks before they finish.

I would break it into four areas or principles.

One — make sure the system is relevant. Depending on the context you will be changing it, but always stay focused on relevance. There will be lots of people who want their concerns or experience brought into the framing for a company. That has to be listened to, but keep bringing it back to what matters in terms of the critical roles — and be a little bit ruthless about cutting out the nice-to-haves. For HSE, tie the criteria back to actual risk.

Two — keep it manageable. We don’t want to get it down to the last detail. You can define competence in one or two tests, or you can define it in twenty against a given area. Be very wary of making it overly complicated.

Three — build in options. Don’t force everyone to pass identical tests. Everyone brings their own thing to a job, even if it looks the same on paper, even if they are meeting the same job description. Ensure there is the flexibility to recognise that there is strength in diversity — so person one and person two can meet the same test with quite different experience, without getting too broad.

Four — be clear. Optionality and diversity like that don’t mean everyone passes. It has to be an honest system, and we need to keep reinforcing the idea that not passing is actually an opportunity. It has helped you and the organisation figure out where your development goals are, and where you can get someone looking over your shoulder for a while as you achieve them. If a task needs to have been done, we need to be certain it has been.

And the final thing I would say: favour tests that look at hands-on experience. Don’t be tempted to go for things that can all be answered academically. That gets us back to the 70‑20 — that’s where people are really prepared when the moment comes to act.

I touched on this numerical challenge before. Say you have identified 300 people on a big site and you’ve cut it down to ten competency groupings — those will change depending on the context. And you’ve decided that for a given competence there might be twenty tests for each band: awareness, knowledge, skill, mastery, for example.

That’s potentially 60,000 tests already. That’s a lot of time crafting those competencies, a lot to maintain, and a lot to actually execute — as a manager, and as a person being assessed. So don’t underestimate the resource.

That resource also has to be consistent. You’re going to need more than one person, so how do you ensure consistency between them? We would tend to favour assessors who are line managers, because they can spot when someone is overstating their experience. But there are two key things to manage:

• —Bias. They may have a conflict of interest — they want that person back out on the floor, and lean towards a pass.
• —Variability. One manager’s interpretation of “competent” can be very different to the next.

We manage these by creating a common understanding — making sure the assessor, the organisation and the person being assessed all understand the process in the same way, and the goals of the process. You have to make people feel comfortable; otherwise it does feel a bit like testing.

An assessor who is just receiving a bunch of results with no briefing, who doesn’t know what other people were doing and doesn’t know what good looks like, is going to apply their own judgement. That’s human nature. We need to deal with it and bring everyone to the same level.

Part of my role at SnSD is key support on incident management and improving the systems for following up incidents — and I think that question hits on something real. Many organisations really struggle with incident follow-up in every sense.

With competence we’re talking about systemic support to an organisation, and that gets down to a level we tend to call root causes. Many incidents will stop at the technical failure. They might stop at the human failure. But now we get down to the systems and cultures that sit behind repeat incidents.

Without a doubt, many incidents and many organisations stop short of the ideal — short of these systemic issues. And then they resort to retraining or reissuing a procedure, and are surprised when it happens again.

Incidents certainly suffer from that, and can benefit from things like root cause analysis that drives the thinking down to the systemic level — down to competencies, down to culture.

Audits need to capture this sort of thing too. They need to move away from “we found this wrong, we found that wrong, you didn’t follow this”, and ideally step back and do system audits — which is something we don’t always see on a site basis. Where people have all this stuff in place, now go in and check: is it effective? Is it even implemented six months or a year later?

If an auditor keeps finding the same deviation across a workforce, that isn’t necessarily a discipline problem — competence may need a look. Another thing SnSD promotes here is tiered levels of assurance, where the second tier tends to lift things more into that systemic space.