Mistakes as a learning cycle, not a blame game

How to turn an error into a managed learning loop: effort criteria, new information, process adjustment, and engineering memory.

  • When a mistake truly teaches
  • The review loop
  • How this relates to IT
  • In his letter "Mistakes Don't Exist," Ichak Adizes suggests seeing a mistake as an invitation to learn, provided the person acted in good faith and wi...

In the letter "Mistakes Don't Exist"

Ichak Adizes suggests viewing a mistake as an invitation to learn if a person acted in good faith and with the information available to them. For project management, this is useful, but it needs one clarification: a mistake becomes learning only when the team has a mechanism for extracting new information.

Otherwise, the phrase "mistakes do not exist"

easily turns into a soft excuse for chaos

We do not need a cult of mistakes, but a short loop:

  • hypothesis
  • action
  • fact
  • process correction
  • knowledge reinforcement

When a mistake truly teaches

Learning happens

  • The decision was made on the information available at the time.
  • The team can name what new information appeared after the action.
  • The next step changed: a test, a checklist, an architectural constraint, a metric, or an agreement.
  • The knowledge entered the shared context instead of staying with one person.

No learning

  • No one tried to test the risk before launch.
  • The review boiled down to finding someone to blame or to a vague "we need to be more careful."
  • The same mistake repeats in the next iteration.
  • The team did not change the process, only the rhetoric.

The review loop

  1. 01

    Fact

    What happened observably: date, system, user scenario, effect.

  2. 02

    Context

    What the team knew at the moment of the decision and which constraints it considered material.

  3. 03

    New information

    What became clear only after the action or the incident.

  4. 04

    Change

    How the process, test, monitoring, architectural rule, or definition of done changes.

  5. 05

    Memory

    Where this knowledge will live so the next team does not pay for it again.

Analyze data and reference master records in your environment

How this relates to IT

  1. DORA and SRE have long stated the same principle in engineering terms: speed and reliability are not enemies when a system runs on small changes, observability and fast recovery.

  2. A mistake in a large batch becomes a crisis.

  3. A mistake in a small batch becomes a signal.

  4. So for an AI-native team it matters not only to speed up generating solutions but also to speed up verification.

  5. The faster a model, developer, or analyst produces options, the stronger the verification loop must be: tests, evals, review, logging, and clear acceptance criteria.

Where the line is

  1. Not every failure deserves to be called learning.

  2. If the team ignored known constraints, did not ask the process owner, did not check the data, and did not raise the risk in time, that is not an "invitation to learn" but a failure of accountability.

  3. Learning will still be required, but first the management contract must be restored.

  4. A healthy culture does not remove accountability.

  5. It makes accountability useful: not punishment for its own sake, but a change to the system that lowers the chance of recurrence.

Conclusion

A mistake becomes an asset only after it is turned into knowledge. Until it changes a process, test, metric, or architectural rule, it is just a cost. The leader's job is not to ban mistakes but to make every honest mistake shorten the next path.

Sources

Reviewed: 30.06.2026

Discuss the article: Mistakes as a Learning Loop, Not a Blame…

Send via: