Chapter 24

Five Things

In January, eleven months after the night on Ward 4B, Priya Shah was given her first solo investigation.

It was a mid-sized logistics company in Northampton. Overnight, a routing system had sent forty refrigerated lorries of vaccines to the wrong depots, and three days later nobody could quite explain why. The chief executive wanted answers within a fortnight. Graham gave it to Priya on a Monday morning, in the small glass room on the third floor with the whiteboard nobody could clean. Afterwards she came and stood in the doorway of Maya’s office with the face of someone who has just been handed something heavy and is trying not to show how heavy.

“Any advice?” she said.

Maya looked at her. Priya was four years into the firm now, still sharp and still stubborn. She’d cut her last report to two factors and an appendix without being asked, and then come back to argue that one of the appendix items should have been a factor, and been right.

“Yes,” Maya said. “Give me until tomorrow. I’ll write it down.”

“You could just tell me.”

“I could. But you’d remember the conclusions and forget how I got there.” She heard Marcus in the sentence and didn’t mind. “Tomorrow.”

She stayed late that evening and wrote it at her desk, by hand first, then typed. It took her four hours. It was the first report she’d written in nine years that she didn’t try to make sound clean.


To: Priya From: Maya Re: Five things I wish someone had made me write down before my first one

Priya,

You asked for advice. Here’s what I’ve got. It’s not a methodology. Kestrel has one of those already, it’s forty pages, and you’ve read it. This is shorter. It’s the things I didn’t understand on my first solo investigation and did by the end of Meridian, mostly because somebody older and more irritating than me kept asking me how I knew.

First, though, I owe you something.

My first solo investigation was a near-miss at a press shop in the Midlands. I found the shift supervisor who’d signed off a lockout check without doing it, and I named him. It was a very good report. Graham used it in pitches for three years. It’s partly why you were hired: I’m the person who wrote it, and I’m the reason the firm thought it was good at this.

In my interview notes I also had a setter telling me that every supervisor on every shift signed that form without doing the check, because the targets made it impossible not to. I didn’t put that in the report. The client didn’t want it, and I already had a clean answer. Eighteen months later, at the company’s sister plant, a man was killed by the same kind of press, with the same form, signed in the same way. His name was Gary Holt.

I’m telling you this because you should know who’s giving you advice. Everything below is the opposite of what I did that time.


1. The name you’re offered is where it broke. It isn’t why.

On almost every investigation, someone will be standing at the exact place where the failure came out. They’ll have made the change, signed the form or pressed the button. Everyone will know their name by the second day. Usually that person did do something, and it’s tempting to stop there, because they’re real and their action is visible and attributable, and a name closes a file.

At Meridian it was a twenty-four-year-old engineer called Sam. He removed thirty lines of code that kept critical blood results reaching the right doctor. He was standing at the place where it broke. Behind him, though, were nine years of nobody documenting that code. There was a 2019 decision to switch off the only other safeguard, and a cost cut that left his tools unable to see the one file that would have warned him. There was a review culture that approved his change in four minutes, and a Skill that had been edited eight times until it stopped asking questions. And there was a risk register that had turned an explicit warning into a green dot. If the board had removed Sam, every one of those things would still have been there for the next person.

So when you’re handed a name, find out what’s behind it. Ask what would have had to be true for that person not to make that mistake, and then check whether any of those things were true. Usually none of them were. That’s your finding.

When someone on the board says in the end, somebody pressed the button, and someone will, ask them which somebody. Make them pick. They’ll find, quite quickly, that they can’t.

I told you once to practise picking. I still mean it. You’ll always have to choose what matters most, and a report that gives everything equal weight is useless. But pick a cause, not a culprit. They’re very rarely the same thing.

2. Ask “how do you know that?” Ask it of every document, and of yourself.

On the day Meridian hired me, you asked how I knew it wasn’t the chatbot. I didn’t know. The chief executive had told me so, I’d believed her, and I’d moved on. I was right, as it happened, but that was luck, not method.

Organisations are machines for producing confident statements about themselves. Most of those statements are true. Your job is to find the ones that aren’t, and you won’t find them by how confident they sound. At Meridian, everyone knew Mr Hale’s was the only incident. When we finally asked someone to run the query, there had been three in six weeks. One of the other two patients had been readmitted with a bleed, and nobody had connected it, because the system said delivered.

Be most suspicious of the things that look most rigorous. Meridian had three hundred and forty pages of beautifully generated documentation on the service that failed. It had a budget paper with immaculate charts, and pull-request descriptions written in flawless prose. The warning was in the documentation, in plain English, ten months before the incident. It was in the pull-request description too, as item three of seven. Nobody read either of them in a way that made them act, because everything was written in the same calm, competent voice, and nothing sounded more important than anything else. A document that looks rigorous is evidence that a document exists. It isn’t evidence that anyone was rigorous.

And when you interview people, ask about the one sentence they didn’t prepare. Not the facts. The thing they said and then apologised for. Then stop talking, and keep not talking for much longer than feels polite. It’s the hardest thing I’ve learned to do, and it’s where nearly every real finding at Meridian came from.

3. Somebody wrote it down. Find them, and find out what happened to them.

In my experience there’s almost always someone who saw it coming, and at Meridian it was a senior engineer called Ruth. Eleven months before the incident she named the exact failure in writing: the method, the mechanism, the words results will appear delivered. She did everything an organisation tells you to do when you see a risk. She put it in the register, wrote a paper and asked in person. Her risk was downgraded and her paper summarised into a green bullet point. A few months later her performance rating was lowered, partly for slowing things down, and she was moved off the service she’d warned about.

Finding the warning is the easy part. The finding is what the organisation did with the person who raised it. If the person who saw the risk was measured as the problem, then the organisation is set up to keep not hearing that kind of warning. The fix you recommend has to change that, or it changes nothing. At Meridian it meant giving Ruth real authority to stop a change, and saying explicitly that using it wouldn’t count against her.

And Priya, protect them. Not only in the report, but in the room. Get them a seat at the table, not a chair by the wall. Someone I respect a great deal failed to do that once, thirty years ago, and has been eating at the same counter ever since trying to make up for it.

4. Measure what the organisation rewarded, not what it says it values.

Every organisation says it values safety. Look at what it put on the slide at the all-hands meeting. Look at whose dashboard was shown to the board, whose rating was moved down at calibration, and what the budget paper measured and what it left out.

At Meridian the spending on AI tools varied by a factor of two hundred and eighty to one between two engineers on the same team, and nobody had ever asked which of them was doing better work. The budget had been tripled on a paper that measured only how fast things were made: pull requests, cycle time, features. There wasn’t a single number on what was made, or whether it was safe. The engineering lead whose team caused the incident had been held up as the model for everyone else, and he’d done exactly what he was rewarded for, extremely well. I was just doing what got rewarded, he told me, and it was true. It wasn’t an excuse, and it didn’t excuse the outcome. It was a description.

If you want to know why people did what they did, don’t ask them what they value. Find the incentives, and follow them until you reach a decision someone actually made. That’s where your recommendations need to land.

5. Look for the distance, and for whatever used to close it.

This is the one it took me longest to see, and I didn’t see it on my own.

Every safety mechanism I’ve ever seen depended, somewhere, on someone being close to something. Close to the work, to the risk, or to the person at the other end. At Meridian, a biochemist used to phone the ward with critical results, so someone close to the number spoke to someone close to the patient. Ruth found the dangerous code because she was close to that module. Even laziness was a safety mechanism, because people used to be too tired to rewrite two thousand lines of old code on a Monday afternoon. So they left the scars alone.

Then everything that made Meridian faster moved people further away. The tools meant nobody had to be close to the code, the summaries meant nobody had to be close to the risks, and the dashboards meant nobody had to be close to the work, only to the numbers about it. The team was fourteen people looking after nine services, so nobody was close to the whole of anything. The man who nearly died was at the far end of all of that, and nobody who could see the risk was anywhere near him.

So ask, of every failure, how far it was between the people who could see the danger and the people who could do something about it, and between both of them and the person who’d be hurt. Then find out what used to close that distance and when it stopped. It’s almost always a decision someone made for good reasons: a phone call retired, a reviewer declined, a cheaper setting chosen, a team grown larger. It’s almost never recorded as a safety decision, because nobody knew it was one.

The fix, nearly always, is to make the distance smaller. At Meridian that meant small teams of three or four people who own one thing end to end, with somebody who understands the risk and is allowed to say no, and somebody who stands where the patient is. It meant protecting, on purpose, the slow work through which people come to understand a system, because reading something carefully is not the same as having built it. The tools make the first fast and do nothing for the second. And it meant doing all of it one team at a time, so that when something didn’t work we knew which change had caused it.


What I don’t know

I’d be a hypocrite if I finished without this.

At Meridian there were two problems we didn’t solve, and still haven’t. We don’t know how to tell what AI spend is actually buying, because the prices change every few weeks and nobody has a way to connect a pound spent to a pound of value or a pound of risk. And we don’t know how to stop the machines turning every warning into the same calm paragraph. Ruth’s best answer so far is to have one person read every risk paper by hand once a month and write one sentence about the worst thing in it. It works, and it doesn’t scale, and she’s said both of those things to the board every month.

We said so in the board minutes, in those words. It was the most useful thing in the report, because it meant nobody could pretend afterwards that we’d fixed something we hadn’t.

If anyone in Northampton offers you a framework that claims to have solved those, or a tool, or a vendor deck, ask them how they know. Then ask to see the benchmark.

The real point

Not one of these five needs an incident. You could walk into any organisation tomorrow, before anything has gone wrong, and ask all five. Who is standing at the point where it would break, and what’s behind them? How does anyone know the things they’re sure of? Who has already written the warning down, and where did they end up? What gets rewarded, and what does that make people do? How far is it between the people who can see the risk and the people who’d be hurt, and what used to close the gap?

If I’d asked those questions at the press shop, a man in Telford would probably be alive. If anyone had asked them at Meridian a year earlier, Mr Hale would have had a quiet night on Ward 4B and gone home with a new hip.

Ask them before, Priya. That’s the whole of it. Everything else is just how.

Good luck in Northampton. Ring me if you get stuck. Ring Marcus if you get really stuck, but he’ll make you buy him dinner, and it’s not a cheap dinner.

M.


She read it through once more at a quarter to eleven, alone in the office, with the lights off on the rest of the floor. She didn’t summarise it, and didn’t move anything into an appendix. She left in everything that made her look bad.

Then she sent it to Priya, and copied Marcus. She didn’t ask whether it was any good.

His reply came back at ten to seven the next morning, before she was up. At that hour, she thought, he was almost certainly sitting at the counter in Clerkenwell while Aiko made the stock.

You left the messy bits in, he wrote. Good. That’s the first honest one.

And then, a line below:

Tell her the dinner’s worth it.