Failure Mode

I asked why people have started saying “failure mode” instead of mistake. The first answer is that the phrase comes from engineering. The more interesting answer is that it makes almost everything sound like a design issue.

A mistake asks who did the wrong thing. A failure mode asks what kind of system keeps producing that wrong thing. Those are not the same question. One points toward the person. The other points toward the conditions around them.

I notice the phrase everywhere now. A company has a failure mode where every difficult decision becomes another meeting. A relationship has a failure mode where neither person says what is wrong until the argument is about something else. A person has a failure mode where uncertainty turns into procrastination.

Sometimes this is just engineering language leaking into ordinary life. But sometimes it is more accurate than mistake. The important difference is repetition.

If I push a door the wrong way once, perhaps I was not paying attention. If almost everyone pushes it the wrong way, the door is doing something. It is communicating push while requiring pull. Calling every person mistaken protects the door from being investigated.

A few days ago I used ChatGPT’s transcription feature with a weak network connection. I spoke for several minutes. The interface let me continue. When I finished, the transcription failed and the thinking disappeared. There was no local recording I could recover, no partial draft, and no reliable retry.

I could describe this as my mistake. I should have checked the connection. I should not have trusted the interface. But that is a very convenient interpretation for the product. The product was in a better position than I was to know whether the connection was unstable. It kept accepting my voice without protecting the only copy of it.

The failure did not begin when the error message appeared. It began when the product allowed valuable and unrecoverable input to accumulate without warning me.

This is what the phrase failure mode reveals. The visible error is usually only the final moment. The actual failure may have been prepared much earlier through a default, a missing safeguard, an unclear signal, an incentive, or an assumption about how attentive and well connected a person would be.

Once I call it a failure mode, the design becomes visible. Why was the audio not stored locally? Why did the interface not show that it had lost contact with the server? Why was there no partial transcript? Why did retry mean trying the failed request again rather than recovering the original material?

Designers usually show the successful flow. The person understands the interface, has a stable connection, remembers the password, enters the correct information, presses the intended button, and completes the task. Everything works because the person and the environment behave exactly as expected.

Real life contains tired people, interruptions, weak networks, old devices, anxiety, accidental taps, unclear language, conflicting goals, and people who misunderstood something three screens earlier.

These are often described as edge cases. But for the person inside one of them, it is not the edge of anything. It is the product.

The happy path shows what the designer intended. The failure mode shows what the system actually believes about people.

Does it believe they will notice a small warning? Does it believe they will never lose the connection? Does it believe they can remember information from the previous screen? Does it believe they can afford to make the payment twice and wait for a refund? Does it believe that a mistake should cost them their work?

This is why repeated mistakes are design evidence. They do not automatically prove that the person has no responsibility. They show that blaming the person is not enough to explain why the same outcome keeps appearing.

There is also something strange about this language becoming popular at the same time as AI.

For most of the history of computing, machines were supposed to be precise and people were the unreliable part. Computers followed instructions. People forgot, misunderstood, got distracted, changed their minds, and made mistakes.

Now we work with machines that hallucinate, lose context, confidently invent sources, and respond differently when asked almost the same thing twice. We do not usually say that the model made a mistake as if it had briefly failed to pay attention. We say it has a failure mode. The behavior comes from the system, even when we cannot fully explain which part of the system produced it.

At exactly the same time, people have started describing themselves like software. We have inputs, outputs, bandwidth, feedback loops, optimization problems, edge cases, and failure modes.

Machines are becoming more human in how they fail. People are becoming more computational in how they explain their failures.

I am not sure whether this makes us more honest.

Calling something a failure mode can be compassionate. It lets me step back from one bad moment and look for the conditions that keep producing it. If I repeatedly avoid difficult work when the next step is unclear, it may be more useful to change how I define the next step than to call myself lazy every time.

But the phrase also creates a very flattering distance between me and what I did. “That is one of my failure modes” sounds like I am observing an interesting machine whose behavior is only partly under my control.

At some point I may be writing an incident report about myself because I do not want to say, “I fucked up.”

Systems thinking can remove pointless blame. It can also remove agency. The fact that my behavior has a pattern does not mean it belongs to someone else. Sometimes understanding the mechanism should make me more responsible, because now I know what keeps happening and can no longer pretend it was a surprise.

Maybe that is the useful boundary. Failure mode is a good phrase when it helps us prevent the next failure. It is useless when it only makes the previous mistake sound more intelligent.

We are living inside increasingly complicated systems made from interfaces, models, policies, networks, incentives, and other people. “Mistake” is sometimes too small for what happens inside them. It identifies the moment when the problem became visible, but not all the things that prepared it.

Still, not every mistake needs to become a systems diagram.

Sometimes the interface needs to be redesigned. Sometimes I need to say I fucked up.

The difficult part is seeing when both are true.

AI authorship note

This essay began with Kris Haamer asking why people have started saying “failure mode” instead of mistake, then recognizing that the phrase immediately turns the event into a design question. Kris supplied the central argument and the ChatGPT transcription example, and directed the piece toward repetition, responsibility, and the strange crossover between human and machine failure. AI helped develop and edit the essay and produced the SVG illustration concepts. Kris shaped the voice, examples, title, argument, and publication decision.