After a customer-visible outage, an executive asks who was responsible and wants consequences. How do you respond as the engineering lead?

## Read the question underneath the question An executive asking "who was responsible?" is rarely enjoying the prospect of punishment. They are usually holding something else: a customer or regulator asking them a question they cannot answer, a board meeting on Thursday, or a plain fear that the organisation does not have this under control. "Nobody is to blame" answers none of that and sounds evasive. The move is to answer the underlying need — *what changed so this cannot recur, and how will you know* — with more specificity than they expected, and to do it immediately rather than after a defence of process philosophy. ## What to bring into that conversation 1. **A crisp account of what the system permitted.** Not "an engineer made a mistake", but "a destructive command was available on the default path with no confirmation, production and staging were visually identical, and nothing detected the deletion for eleven minutes." Executives generally find this *more* reassuring than a name, because it is something an organisation can fix. 2. **The controls, with owners and dates.** Concrete and few. A short list of shipped guardrails beats a long list of intentions. 3. **Detection.** What will catch it faster next time, and by how much. Leaders anchor on time-to-recovery even when they ask about fault. 4. **A follow-up commitment.** Offer to come back on a specific date with evidence the work landed. That is accountability with a name on it, which is what was being asked for in the first place. ## Making the cost of punishment explicit The argument that lands is economic rather than moral: - **You lose the best-informed person.** After an incident, the operator involved understands that failure better than anyone in the company. Removing them exports that knowledge to a competitor and leaves the replacement to rediscover it. - **You buy silence for years.** Every engineer watching learns what candour costs. The next incident gets reported later, described more vaguely, and takes longer to resolve — and none of that appears on any dashboard as a consequence of this decision. - **You get the wrong fix.** A punished team produces postmortems designed to be safe to publish rather than accurate, and the guardrails that would have prevented the recurrence never get identified. - **The individual is a poor predictor.** Whoever happened to be on call that night is largely a scheduling artefact. The condition that permitted the failure is the durable variable; the person is not. ## Concede the line honestly Credibility here depends on not overclaiming. Blamelessness is not a promise that behaviour never has consequences. Just-culture models separate honest error, at-risk behaviour where someone drifted into a shortcut without recognising the risk, and reckless behaviour where someone knowingly disregarded a substantial, understood risk. Only the first two are learning material. The third exists, is handled privately by the person's manager on its own evidence, and stays out of the postmortem — and saying so plainly is what stops an executive suspecting that "blameless" is a shield. The corollary matters just as much: the category is judged by the behaviour, not by how expensive the outcome was. If the same shortcut would have drawn no reaction on a quiet day, punishing it because it happened to be costly on a loud one is a lottery, and teams read lotteries as arbitrary. ## Repeat involvement If the same individual keeps appearing at the centre of incidents, that is data, not a verdict. The likely readings are structural: they own the least-defended part of the system, they are the only person who touches it, they are exhausted from carrying a disproportionate share of the pager, or the tooling they use is the worst in the estate. Any of those is an organisational finding. Genuine individual performance concerns exist too, and they belong to that person's manager, privately, with normal evidence — never as an output of a postmortem process people are supposed to trust. ## Do this before you need it The conversation goes far better if leadership agreed to the model in advance: what blameless does and does not cover, where the recklessness line sits, and what leadership will be given instead of a name. Negotiating that during a costly outage, with a customer on the phone, is the worst possible moment. Pre-agreement is the actual principal-level work; the conversation described here is just the moment it gets tested. Also decide in advance what goes outside the company. Regulated and contractual contexts may require a formal record with named individuals, and that record is kept separately from the internal learning document by design — conflating the two is how internal postmortems become sanitised into uselessness. ## What a strong interview answer sounds like Do not perform indignation on behalf of blamelessness. Show that you can hold a hard line while giving a senior stakeholder something real: the system finding, the shipped controls, the detection improvement, the explicit cost of the punitive alternative, an honest concession about where recklessness is handled, and a date to report back.