Idea

Looking for someone to blame after a defect makes defects disappear from conversations, not from the product

Info

Originally written in French. Translated by AI — the meaning has been preserved, not the prose.

Main idea

Giving ownership and assigning blame look alike from the outside: in both cases, you trace a defect back to whoever produced it. The effects are opposite.

When naming the author serves to designate a culprit — displaying them, mentioning them in a meeting, making it a ground for appraisal — the team learns what to do so it does not happen to them: downplay a defect, delay reporting it, avoid risky changes, document to cover themselves rather than to explain. The product is no better; the conversation about the product, however, gets poorer.

Useful ownership says something else: you own what you ship, so you take part in its fix and in what is learned from it. It is not looking for a culprit, it is closing a loop. The difference is not one of intensity but of destination: one designates a person, the other attaches a defect to a shipment.

Why it matters

This lifts the most frequent objection to any rule that reattaches a defect to its author: "you're going to create a culture of fear". The objection targets a use of the rule, not the rule.

It also supplies an observable signal. Where blame operates, defects stop appearing in internal exchanges before appearing at the customer — and a team that reports few problems does not necessarily have few.

Nuances and limits

The boundary does not hold through intention, it holds through the setup. A rule stated without blame but tied to individual appraisal produces the same protective behavior.

And individual responsibility has a limit of its own: some defects are the product of a production system, not of a shipment — attaching them to a person is then accurate and useless.

Open questions

  • What signal distinguishes a team that reports few defects because it produces few from a team that has learned not to report them any more?