Blame the process, not the person

The one secret

I have just watched Jake Humphrey's interview with Toto Wolff and I can't stop thinking about it. Jake asked Toto for his one secret, and he said the answer rearranged how he thinks about failure. It has done the same for me.

Toto's answer was simple: "At Mercedes, we blame the process. Not the person."

Every single time

Jake pushed him on it. Every single time? Toto said yes.

So Jake pushed again. What if it genuinely is one person's mistake? I'm going to use Toto's words here because they are better than mine: "If someone's a bit shit, why have we not got a process that makes them better?" He then asked why they hadn't looked at that person's weak points and made them their strong points.

This is a team where the drivers are risking their lives every race. If there was ever a place where you would expect someone to take the blame, it's there. Yet Jake couldn't find one example of Mercedes blaming the person over the process.

The line I keep coming back to is this one: "If you blame the person and you sack the person, where's the learning?"

Why this matters so much in data

I don't know the inside of a Mercedes garage, but think about a pit stop. Around twenty people change four tyres in a couple of seconds. Every person has one job and does it the same way every time, because the process has been drilled until it's second nature. If a wheel gun jams, the question isn't who was holding it. The question is why the gun jammed and what changes so it doesn't happen again.

Data delivery is exactly the same. A pipeline fails overnight, a load duplicates records, or a report goes to the board with the wrong number on it. The natural reaction is to ask who did it. Who wrote that code? Who signed it off?

I think that's the wrong first question. The better one is how did our process let that reach the client? Was there a test that should have caught it? Did someone review the code? Was the requirement clear in the first place?

People are human and they make mistakes. That will never change. What we can change is the guardrails around their work, so that when a mistake happens it gets caught before it causes an issue.

There's another reason this matters in data. If people are scared of being blamed, they hide their mistakes. In most jobs a hidden mistake is bad. In data it's dangerous, because numbers get trusted and decisions get made on them, sometimes for months before anyone notices.

How we put it into practice at Business Thinking

So, what does this look like on the projects we deliver for our clients?

It starts with automation. With AutomateDV the Data Vault loading code is generated from metadata, so nobody is hand-writing the same pattern over and over and getting it slightly different each time. That's a process doing the job a tired developer at 6pm on a Friday shouldn't have to.

Then there are the checks around the work. Code gets peer reviewed and tested before it goes anywhere near production, and the definition of done is agreed up front so everyone knows what good looks like.

We deliver using agile, following the GDS approach, and the retrospective at the end of each sprint is where this mentality really lives. It's the place to talk openly about what didn't go well without anyone feeling they are on trial.

When something does go wrong, the post-mortem asks what in the process let it happen and what we are changing, and the actions go into Azure DevOps like any other piece of work so they actually get done.

The same goes for our clients' teams. When we find an issue in a client's data, our job is to help fix the process that let it in. It's never to point a finger at the analyst who built the report.

Isn't this letting people off the hook?

Some will say this sounds soft and lets people off the hook. I don't think it does. People still own their work and still own up when something goes wrong. The difference is what happens next. Instead of a telling off, the response is a better process and some help to turn a weak point into a strong one, which is exactly what Toto described.

I also think it's the commercial answer. A team that hides mistakes costs a client far more than a team that surfaces them early and fixes the cause. And a consultant who learns from a mistake is worth more to the next client than one who has been replaced.

People and processes are at the heart of everything I do, and this interview put into words something I have always believed. So next time something goes wrong on one of your projects, before anyone asks who, ask Toto's question. Where's the learning?

Let me know your thoughts?