When Does a Mistake Become a Pattern?

The previous article ended on a condition: accountability requires that the pattern be real.

That sounds like a small qualifier. It is the hardest part of the whole framework.

Because a pattern is not a thing you observe. It is a thing you infer, usually from a small number of events, usually about a person, usually while under some pressure to reach a conclusion. And human beings are extremely good at seeing patterns in noise, particularly when we have already formed an opinion about who the noise belongs to.

So this article is about a narrow and unglamorous question:

When is a repeated mistake actually a pattern, and when does it just feel like one?

This is the sixth article in this series, following A Blame-Free Culture Is Not an Accountability-Free Culture.

Recency Is Not Recurrence

Start with the most common failure, because almost every organization does this.

Someone makes a visible mistake. Two weeks later they make another one. The second one is now interpreted through the first.

This is not analysis. It is availability. The two events are salient because they were recent and because they happened to the same name, and the mind fills in a trend line between two points that would never have been drawn between two different names.

The test is simple and almost nobody applies it: would this second finding have registered as a pattern if it had a different person's name on it?

If the honest answer is no, you do not have a pattern. You have a memory.

A Pattern Requires a Class

Two defects are not a pattern merely because they are two defects.

They are a pattern when they share a class: the same failure mode, arising at the same point in the process, for the same underlying reason.

Consider three findings attributed to the same person over a month:

• A wrong price in an email.
• A card layout that breaks on mobile with a long product name.
• A missing UTM parameter on a paid link.

That is three defects and zero patterns. They come from three different parts of the process and would be prevented by three unrelated controls. Grouping them produces exactly one insight, "this person had three findings," which is a fact about volume, not about behavior.

Now consider a different three:

• A wrong price in an email.
• A wrong price on a landing page.
• A wrong discount in a social post.

That is one pattern with three instances, and it points at something specific: pricing information is entering the work without passing through a verification step. Note that this pattern is almost certainly not about the person at all. It is about where pricing comes from.

This is why classifying findings by type is worth the small effort it costs. Without a class, "recurrence" degrades into "how often does this name appear in the log," which is the metric most likely to be quietly punitive and least likely to be informative.

The Window Has to Be Decided in Advance

The second way patterns get manufactured is by choosing the time window after seeing the data.

Three findings in a month reads as a problem. The same three findings across five months reads as normal. Both descriptions can be true of the same events, and whichever one gets used usually depends on what the person describing it already believed.

Pick the window before you look. Make it the same for everyone. Write it down.

A reasonable default is one review cycle, whatever your organization already uses: monthly, quarterly, per campaign. The specific length matters much less than the fact that it was fixed in advance and applies identically to the person you like and the person you find difficult.

Volume Changes Everything

Here is the objection that dismantles most naive recurrence counting.

Jane produces ten thousand assets in a quarter. John produces ten.

Jane has fifteen findings. John has two.

Which of them has a quality problem?

If your framework answers "Jane, she has seven times as many," the framework is worse than having no framework, because it will systematically penalize your highest-output people and reward your lowest-output ones. And it will do it while looking like arithmetic.

Absolute counts are unusable. Rates are better and still misleading at small samples, since John's two findings out of ten is a twenty percent rate calculated on a sample where a single additional event would swing it by ten points.

This problem has enough depth that it gets its own article next: No Rate Without a Denominator.

For pattern detection specifically, one rule is enough to avoid the worst mistakes:

A recurrence count without a denominator is not a finding about a person. It is a finding about how much work they did.

Compare Against the Team, Not Against Zero

Even with a denominator, a rate in isolation means nothing.

Is a defect rate of 1.5 per thousand assets good or bad? The question has no answer without a baseline, and the baseline that matters is the one your own team produces on the kind of work you actually do.

If the team's rate is 1.4, then 1.5 is normal variation and there is nothing to discuss.

If the team's rate is 0.3, then 1.5 is a real signal and worth investigating.

The comparison also has to respect the work. Someone producing high-volume repetitive social assets and someone building a bespoke campaign microsite are not on the same scale, and averaging them produces a number that describes neither. What to do when you cannot construct comparable groups is covered in the next article.

This has a consequence people find uncomfortable: your best performer's rate is not the standard everyone should be held to. Studying what they do differently is enormously valuable. Using their number as the passing grade is a way of converting an asset into a threat, and it has its own article later in the series: Your Best Performer Should Be a Laboratory, Not a Weapon.

Patterns After a Control Is Added

There is one form of recurrence that is genuinely informative, and it is much narrower than what most organizations look at.

It is the recurrence of the same class of defect after a control was introduced to prevent it.

That sequence carries real information, because the control divides the timeline into a before and an after. Whatever happens after is happening in the presence of a known, agreed, available mechanism.

And even then, the finding is ambiguous in a useful way. It could mean the control is not being run, which is the performance case from the previous article. It could equally mean the control does not work, is too slow, is in the wrong place in the workflow, or catches something adjacent to the actual failure.

Which of those is true is an empirical question, and it is answerable. What is not answerable is the version where nobody wrote down when the control was introduced, so nobody can tell whether the defect is a repeat or the first data point of a new regime.

The Pattern Is Usually in the Process

When teams do this analysis honestly, the result is consistently deflating for anyone hoping to identify a problem employee.

Most real patterns turn out to be structural. Pricing that arrives through three different channels. A design system with no long-content states. A handoff that happens over chat with no artifact. A tool that silently truncates. A client contact who sends updates by phone.

Those patterns are visible only when findings are classified and pooled across the whole team. They are invisible when findings are filed under individual names, which is another argument for classifying by defect type first and by person second, if at all.

A pattern that only appears when you sort by person is usually a pattern about the person's workload.

A pattern that appears when you sort by defect class is usually a pattern about the process.

The second kind is the one you can fix.

What the Metric Is For

All of the above exists to protect one sentence, which is the point of the article:

A recurrence metric is an alert, not a verdict.

It says: something here is worth looking at. It does not say what, and it does not say who.

Used that way, recurrence tracking is one of the most valuable things a quality process can produce, because it converts a pile of individual incidents into a short list of places where the system leaks.

Used as a verdict, it becomes something else entirely: an instrument that people learn to manage rather than a signal they trust. What that failure looks like in practice, and how quickly it happens, is the subject of Metrics Can Destroy the Culture They Were Designed to Improve, later in this series.

The difference between the two uses is not in the data.

It is entirely in what happens in the ten minutes after the number appears.