top of page

Why Your Safety Management System Isn't Improving Performance

  • Andy Barker
  • May 1
  • 5 min read

Why Your Safety Management System Isn’t Improving Performance


Keep your tools. Keep your processes.


You’ve worked hard to build them.


I help adjust the Community Operating System they run on, so the effort you’re already making can turn into performance.


Why culture makes “tools” fail or succeed


Think of tools as apps on your phone. Without the right operating system, they won’t work.


Organisations are very similar.


For example, have you tried implementing a new tool without the organisation’s complete understanding of why it is important, or what value it brings?


Did it work well without ownership or buy-in?


Your processes and tools are “apps” running on a cultural operating system.


The OS is important.


The “best system on the market” that changed nothing


A few years back, I was called into a business that had just rolled out what they proudly described as “the best safety management system on the market.”


It had dashboards, analytics and workflows.


On paper, it was flawless.


But six months later, the dashboards were saying what they always had:


Reports were being completed.

Activities were being tracked.


The big issue was that performance hadn’t moved.


We could see the transactions, but we couldn’t link them to outcomes.


The system hadn’t failed.


Culture had edited it.


I’ve seen simple, even clunky systems outperform sophisticated ones because people believed in them.


When people trust that what they share leads to something useful, they work out how to make things work for them.


Without that belief, even the best systems sit unused, or used just enough to keep the numbers moving.


How culture edits the system


In this organisation, the new system really did make some things easier.


Reporting became more visible, more structured.


It simplified transactions and made them more transparent.


But nothing changed in how people operated, contributed or collaborated.


So everyone applied old beliefs, attitudes and behaviours to the new system.


- “If I raise that, it will land badly.”

- “If I put this in writing, it will come back to me.”

- “If I do what’s expected, the rest will look after itself.”


People don’t follow systems.


They follow what they believe happens next.


When people believe that sharing information will help them and their colleagues succeed, they contribute openly.


But if they believe it will create more work, more “social” exposure, or no meaningful change, they hold back.


People adjust what they share based on what they believe happens next — and that belief comes from their past experiences, not from a set of icons on a screen.


So in this organisation, a familiar pattern played out.


People didn’t trust that what they shared would make the difference they wanted, so they shared what had historically been safe, leading to predictable responses.


The new data told the old story:


“We completed the activities.”

“We closed the actions.”


We can re-categorise data all day, ask for more engagement or push close-out rates, but without a shift in trust and belief, performance won’t shift.


Why new systems repeat old outcomes


Most organisations respond to poor outcomes by improving the system.


Adjust the tools.

Increase awareness.

Retrain people in the process.


The assumption is:


If we do the process better, we’ll get better results.


I’ve found the reality is simpler, and less comfortable.


If trust doesn’t change, the output doesn’t change.


Trust, in this context, is really a social risk assessment:


“If I share this, will I get help or harm?”


If people believe the organisation is capable of change and intends to do the right thing with the information, they share openly.


If they don’t, they don’t.


So changing how you collect information without changing the conditions it sits in simply gives you the same story in a new format.


You may get better-looking reports, but what about the underlying behaviour?


The operating system determines the quality of contribution.


And that operating system is social, not technical.


Fix the ground, not the gadget


If you want a system to work, don’t start with the tool.


Start with the employee experience.


When someone raises a problem, do they feel like a burden, or like they’re contributing?


When they raise an idea, do they feel supported, or exposed?


We’ve all heard some version of this:


“If you believe people are the problem, you’ll treat them like one.

If you believe they’re the solution, they’ll show you they are.”


A simple test:


When people speak up, does it lead to:


- Support and resolution?

- More work for them and their supervisor?

- Hitting a target?


People adjust their contribution based on the response.


Where people see burden, contribution disappears.


Engagement isn’t a mindset.


It’s behaviour in response to conditions.


So, if you want to understand engagement, look at where ownership sits, and how far it travels.


Does ownership of an issue stay with the person who raised it?


Does it move to someone who can actually change the conditions?


Does it disappear into “the system” and come back as a number?


The fastest way to increase contribution is to show that sharing leads to help, especially from beyond someone’s immediate environment.


Systems that collect data vs systems that demonstrate help


Systems designed to collect data will always struggle.


They can be accurate, efficient and comprehensive, and still fail to change performance.


Systems that demonstrate help will always outperform them.


When people experience that what they share leads to something better, they don’t need to be told to engage.


They choose to contribute.

This is where the Community Operating System comes in.


Not as another layer of process, but as a way of shaping:


- What people believe happens next when they try.

- How leadership responds when weak signals appear.

- How far ownership travels from the point of observation to the point of decision.


Change that, and you can keep your tools.


You just change what they do for you.


Try this with one system you already have


Pick one system, process or tool that isn’t delivering what you hoped.


Ask three people who use it:


- Who is this supposed to help and how?

- Do you have a story that would help me understand that?

- What would make it worth your time?


Listen less for complaints about the interface, and more for the stories about what happens next.


The gap between those answers will tell you whether the tool is the issue, or whether the story around it is shaping the outcome.


You may find that a “broken system” is really a mismatched belief:


- People think it’s there to audit them, not help them.

- They think it feeds reports, not decisions.

- They think it will make life harder, not easier.


That’s not a software problem.


That’s an operating system problem.


Final thought


If your system is built to gather information, you’ll get information.


If it’s built on trust, respect, and the belief that people will be helped, you’ll get contribution.


And contribution is what changes outcomes.


The question isn’t whether your system works.


It’s whether it gives people a reason to use it in the way you intended.


If this resonates, I’m happy to explore one system you already have and look at how it’s being edited by culture — and what might happen if the script changed.


That’s what we do:


Helping organisations turn everyday effort into real performance by adjusting systems to work for people, not the other way around.

Comments


bottom of page