Why Does My Team Keep Making the Same Mistakes?

If the same mistake keeps coming back with different people in the chairs, the problem is not the people. It is the system that keeps producing it.

Why does my team keep making the same mistakes?

Your team keeps making the same mistakes because the cause sits in how the work is shaped, not in how hard people are trying. When the same shape of problem recurs across different people and projects — a particular sign-off that always slips, a particular handover that always leaks, a particular decision that always stalls — that recurrence is information about the system. One missed detail is a bad week. The same kind of miss, three or four times a quarter, is the system telling you something.

This reframe changes the question you ask. The instinctive question is who dropped this? It feels responsible, but it does almost no work: the named person is more careful for a fortnight, and the same problem turns up on someone else's desk two months later. The more useful question is what in the system is making this easy to miss, hard to escalate, or likely to recur? The first hunts for a culprit; the second hunts for the cause.

What's the difference between a one-off mistake and a pattern?

A one-off is a single mistake in unusual circumstances; a pattern is the same shape of mistake recurring across people, projects or time. Telling them apart matters, because the cure is different: a one-off deserves a quick fix and a short honest note, while a pattern deserves a redesign. Treating every one-off as a pattern buries a team in process; refusing to treat a pattern as a pattern is its own kind of laziness.

A few signals separate the two. Any one might be coincidence; two or three together, pointing at the same seam of work, is almost always a pattern:

• Recurring pattern — the same kind of issue, different people in the chairs. When you explain this month's problem with the same sentence you used last month, you are holding system information.
• Recurring confusion — the same question gets asked repeatedly (who decides this? where is the live version?) because the answer does not live anywhere findable.
• Dependence on one person's memory — the work only runs well because a particular colleague remembers how it went last time. That is the bus factor of one, and it is a vulnerability, not a strength.
• Recurring late discovery — important problems consistently arrive too late to respond well, which points at the information flow rather than any individual.
• Recurring variation — the same task is handled five ways by five people, and two or three of them reliably produce worse results, because nobody has written down what good looks like.

Where do recurring mistakes actually come from?

Recurring mistakes come from a handful of ordinary places in the system, not from a shortage of care. "The system" rarely lives in flow diagrams; it lives in the things you can point at on a Tuesday, and recurring mistakes cluster in four of them:

• Handoffs. Every seam where work moves between people is where each side can assume the other owns a step. A handoff without an owner, a standard and a check is a predictable leak — and a disproportionate share of recurring pain begins exactly there.
• Decision rights. A lot of what reads as indecision is really ambiguity about who is allowed to make the call. When decision rights are unclear, choices default upward, queue behind one person, and stall — every time.
• Standards. A standard is what a team has agreed "good enough" looks like, legible to someone who was not in the meeting. Without one, the same work is done differently each time, and the worse versions keep recurring.
• Feedback loops. If a problem is only learned about once it has already bitten, the cadence and surfaces around the work are not pulling information forward early enough to act on.

The common thread is that none of these is a carefulness problem. As Sidney Dekker, the safety researcher whose work on just culture shaped how serious organisations treat error, puts it, human error is not a cause to be eliminated but a symptom of trouble deeper inside the system.¹ Chase the person and the trouble stays. Change the seam and it goes.

How do you turn a recurring mistake into one light fix?

You turn a recurring mistake into a durable fix by redesigning one small piece of the work so the next instance lands on a stronger structure. The Control Standard (Chapter 6) puts the underlying idea in a sentence: repeated pain is system information. Chapter 9 then turns it into a move — from pattern to mechanism — and the discipline is to pick the lightest mechanism that addresses the actual weakness, not the most visible one.

A mechanism is not a new committee or a heavier process. Most of the time it is a single sentence added to a handover document, one checklist item at a known risk point, a named owner for a decision, or a fifteen-minute review attached to where the information needs to land. The book describes a small family of these levers, but the one-line test for whether a recurrence has earned a mechanism is simple:

Ask three questions: how often does this shape of problem arrive, how expensive is it when it does, and how bad is our current detection? If all three are meaningful, a small mechanism is almost always cheaper than continuing to pay for the drift.

If only one or two are meaningful, be slower and smaller. If none is, write the honest note and move on. The test is not whether the fix feels serious. It is whether it works.

The cleanest public evidence that a small mechanism beats more vigilance comes from surgery. The World Health Organization's nineteen-item Surgical Safety Checklist — a short pause read aloud at three handoff points in an operation — was trialled across eight hospitals on four continents. Introducing it was associated with the rate of death from inpatient surgery falling from 1.5% to 0.8%, and complications from 11% to 7%.² The checklist added no new skill and no new procedure; it required the team to stop at a high-risk handoff and say a few specific things out loud. The value was in the pause and the conversation, not the paperwork.

How do you have the conversation without making it worse?

You hold the conversation blameless about people and demanding about system learning. The most common way a review fails is by turning into a hunt for who to blame: the named person defends themselves, everyone else quietly decides to surface less in future, and a year later the business has fewer visible problems and far more buried ones. The fix is not a softer review. It is a sharper one, aimed at the right object.

The reference practice is the blameless postmortem, written down in a portable form by Etsy's engineering team and rooted in the older just culture tradition from aviation safety.³ The operating rule is to assume the people involved acted reasonably on the information they had, then ask what about the surrounding system made that outcome the likely one. Blameless does not mean consequence-free; it means directing accountability at the lever most likely to change the outcome next time. If that lever is the system, change the system. If it is a specific, repeated, coachable habit, the feedback happens — usually in a one-to-one, not in public.

Two borrowed techniques carry that conversation. A root-cause analysis drives past the symptom to the one condition you can actually change. An after-action review — the four-question debrief formalised by the US Army (what was supposed to happen, what actually happened, why the difference, what will we change?) — is the meeting that holds it. Run the review blameless, run the analysis until you reach a cause you can change, and end with one specific change, a named owner, and a date.

What if the recurring mistake is worth more than a sentence?

Sometimes a recurring mistake is frequent and structured enough that the right fix is a documented process, a permanent checklist, or a piece of software — but only after you have made the work explicit, because automating a process nobody has defined just produces a faster mess. Deciding which kind of fix a repeated pain actually needs — a changed habit, a clearer process, or a built tool — is what systemising before you automate is about, and it sits at the heart of the systemising pain pillar.

When the same mistake keeps draining time and trust across projects, that recurring cost is the drift tax in action — rarely on the books, which is exactly why it gets tolerated for years. The free Pain Automation Score below weighs one recurring pain in about five minutes — frequency, cost, process stability and detection — and tells you whether to clarify it, systemise it, or build something. That judgement, and the method behind it, is what The Control Standard teaches in full.

1. Sidney Dekker, The Field Guide to Understanding 'Human Error', 3rd edition (Ashgate/CRC Press, 2014). Dekker's central argument across this and his Just Culture work is that "human error" is not a cause but a symptom of deeper systemic trouble, and that durable safety comes from redesigning the conditions that make error likely rather than exhorting people to try harder. ↩

2. Alex B. Haynes et al., "A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population", New England Journal of Medicine 360(5), 2009 (nejm.org/doi/full/10.1056/NEJMsa0810119). The WHO pilot across eight hospitals saw inpatient surgical deaths fall from 1.5% to 0.8% and complications from 11% to 7%. The checklist and resources are at the World Health Organization. ↩

3. John Allspaw, "Blameless PostMortems and a Just Culture", Etsy Code as Craft (etsy.com/codeascraft/blameless-postmortems). Allspaw popularised the term in technology and traces it to the wider just-culture tradition in aviation and high-reliability work. ↩