"Who feels the pain when we get this wrong?"
It was a question I found myself asking after taking over a newly formed team that had yet to find its rhythm.
The metrics weren't good. Quality was inconsistent, mistakes were frequent, and confidence was low.
The obvious response would have been to focus on the numbers. Tighten controls. Increase oversight. Add more training.
Instead, I spent time talking to the team.
What I discovered was that most people could explain the process. They could tell me the steps they were expected to follow. They knew the targets they were measured against.
What many of them couldn't explain was who depended on their work and what happened when mistakes occurred.
That gap — between knowing the process and understanding who it served — became the first thing I set out to close.
The Missing Context
Most onboarding programmes teach people what to do. Far fewer teach people why it matters.
The team understood the mechanics of the role. What they lacked was context.
Who was receiving the output of their work? What happened when something was delayed? What happened when an error slipped through? More importantly, who had to deal with the consequences?
When an error occurred, it wasn't just a failed transaction. It meant a salesperson couldn't close a deal, a customer couldn't proceed with a purchase, or a colleague had to spend hours untangling the issue.
Until then, many people had only seen the process from their side of the screen. They had never been shown what happened to the person on the other end.
Once we started discussing those consequences, the tone shifted. People stopped framing mistakes as bad luck and started asking what had made them more likely.
The work stopped being a series of transactions. It became a responsibility to another person.
People were no longer simply processing requests. They were helping someone else succeed at their job.
That distinction mattered more than I expected.
Accountability Works Differently When Purpose Is Clear
At the same time, there was another issue.
When mistakes occurred, responsibility tended to stop with the individual who made the error. The assumption was simple: if something went wrong, the person closest to the work must be at fault.
What was often missing from those discussions was whether leadership, training, communication, or process design had contributed to the outcome.
I have seen this pattern more than once in operational environments.
I remember a debrief early in the transformation where a mistake was raised and the discussion quickly focused on the most junior person involved. I redirected the conversation: what had we not made clear enough? What had the briefing missed? The shift was uncomfortable, but it was the point. Accountability flows downward very easily. Shared accountability takes deliberate effort.
Part of the transformation involved resetting that expectation. Leaders would be held accountable for the quality of workflows, the clarity of standards, and the effectiveness of training — not just the numbers that resulted.
Once that happened, conversations became less focused on blame and more focused on problem-solving.
Diagnose Before Deciding
Another lesson emerged during the process.
Poor performance is often treated as a single problem requiring a single solution. In reality, different people struggle for different reasons.
Sometimes the issue is knowledge. The person needs coaching and support. Sometimes the issue is process. The system around them is creating failure. Sometimes the issue is fit. The role and the individual's strengths are simply misaligned.
Each requires a different approach.
The more useful question is often not "What should we do?" but "What is actually causing this outcome?"
The answer is rarely the same for everyone.
What Changed
The metrics improved over time. Quality stabilised. Stakeholder confidence increased. Performance became more consistent.
But the numbers were not what I remember most. What stayed with me was the shift in behaviour.
What surprised me most was that people started challenging outdated processes — not waiting to be asked, just raising the issue. Small improvements began appearing everywhere. A section of the process guidelines was simplified. A checklist was introduced to reduce missed steps. None of these changes were particularly significant on their own.
Together, they signalled something more important: people had started taking ownership of the work and the way it was done.
That ownership gradually turned into pride.
I remember hearing team members talk enthusiastically about how they had helped solve a problem or support a stakeholder through a difficult situation. That had not existed before.
The team had stopped thinking only about avoiding mistakes. They had started thinking about what they were actually making possible for the people who depended on them.
The metrics followed. They usually do when people understand why their work matters.
What This Taught Me
Most transformation programmes begin with systems, processes, and dashboards. Those things matter.
But many transformations fail because people are expected to care about outcomes before they understand who those outcomes affect.
The biggest shift did not come from a new process, a new tool, or a new reporting structure. It came from helping people see the human consequence of their work.
Once they understood who experienced the pain when things went wrong, they also understood the value they created when things went right.
That understanding changed behaviour.
People rarely commit to a process. They commit to a purpose.
The moment the team could see the people behind the process, the quality of their decisions began to change.