Incompetence is not an explanation

Incompetence is a poor explanation for anything and it’s a very poor one for a security failure inside a large system.

It’s always available which is part of the problem. Something goes badly wrong, somebody’s name is attached to the change and the story writes itself in a sentence. The trouble starts the moment you follow the chain outward because the work was part of a team effort and you have to decide whether everyone on that team is also incompetent.

Take a database exposed in the cloud. The people who configured it were using a managed service which presumably didn’t warn them clearly enough so are the platform team incompetent for shipping something that dangerous by default. The documentation plainly did a bad job of explaining the security model so are the writers who drafted and checked and shipped it incompetent as well. If the companies involved employed a security team to audit their cloud applications then that team missed it as well. And if the security team did catch it and reported it, then somebody further up didn’t read the report properly which makes the reporting incompetent instead.

You can walk it in both directions and the chain never stops anywhere that satisfies you. That’s not a special property of this incident. It’s how every industry works, with layers of complexity stacked on layers and nobody anywhere in the stack having enough oversight to take real responsibility for a mistake that happened three floors down the rabbit hole.

Somewhere in there you could point at one decision and call it incompetence and be right. Doing that relieves everybody else of their small part in building the chain of tools and defaults and documentation that made the mistake easy to make and that’s the actual cost of the explanation rather than any unfairness to the individual.

Because if all the blame lands on one person, nobody else has any reason to change anything. The team can decide that Chris was terrible, feel relieved that Chris has been let go, and carry on with a system that will produce the same outcome as soon as somebody else is standing in the same place. The story satisfies you precisely because it asks nothing of anyone still in the building.

The other route is less satisfying and a lot more use to you. Accept that mistakes are inevitable, that anybody in that position could have made this one, and then ask what in the surrounding system made it likely. That produces a list of small changes across several teams, none of which is dramatic, and all of which reduce the chance of the next one.

It also takes away the thing you actually want from the blame story, which is a moment where the problem is over. There isn’t one. There’s just a slightly better system than yesterday, and another incident eventually and the same question to ask again.

There’s a practical reason to care beyond fairness, which is that the blame version gives you nothing to do. A report that names a person produces a dismissal and no change. A report that maps the chain produces a documentation fix, a default change, a check in a pipeline and a different escalation path, and any one of those would have broken the sequence on its own.

One of those outcomes feels like justice. The other one is the only one that alters the odds next time.

So when you next read an incident write-up and find a name in it, the useful question is what the other nine links in that chain were doing, and whether any of them changed afterwards.