What Keeps Repeating?

Well, crud. 

When something goes wrong in an organization, the first instinct is often to address it directly and move on. That's not a bad instinct. Organizations run on momentum, and stopping to dissect every problem would grind the place to a halt. But there's a category of problem that needs a different approach, and the way to recognize it is simple: it comes back.

Not every problem that recurs is a structural problem. Sometimes a deadline gets missed because someone was out sick, and that's genuinely just bad timing. But most leaders, if they're honest, can name two or three things in their organization that have been "fixed" multiple times and keep showing up anyway. The details change. The people involved might change. But the pattern is recognizable. Certain teams are constantly putting out fires, others seem like they’re drowning in dropped balls. Recognizing that feeling of "here we go again" is one of the most useful signals an organization or team can produce.

But we don't treat it that way because repetition feels like failure. If the problem came back, someone didn't fix it right or didn't follow through. So the response to the repetition is usually the same as the response to the first one, just with more frustration behind it. Added threats or incentives. A more detailed plan. And usually, a similar result.

Repetition is data. When a problem keeps happening despite efforts to stop it, the system is telling you something about how it's built. The problem isn't sticking around because people are failing. It's here because something in the structure keeps producing it. The effort to fix it is real, but it's treating the symptom rather than resolving the problem.

Think about a product team that consistently ships late. Every time. Management has addressed it. The team has talked about it. There have been new processes, new tools, new commitments, threats, and rewards. But after a couple wins, the next release is late too. If you ask people on the team why, you'll get a range of answers. Requirements changed mid-sprint. Another team didn't deliver what was needed on time. There was a production issue that pulled people away. They can all be true. And they're true every time, in some form. The specific cause rotates, but the outcome is the same.

That stability is the signal. When the result is consistent but the stated causes keep changing, the real cause isn't any of the individual reasons people are giving. It's something upstream of all of them, something about how work enters the team, how dependencies are managed, how decisions get made when things shift. The shifting reasons are the system finding different paths to the same place.

It’s counterintuitive, because we're trained to look for causes and fix them. A causes B, remove A, B stops. That logic works fine for simple problems. But in even slightly complex organizations, the problems that keep repeating aren't simple. They involve multiple teams, competing priorities, unclear ownership, and changing conditions. You're playing whack-a-mole.

So we shift our questioning. "Why does this issue continue to exist?" If a bottleneck keeps appearing at the same point in a process, maybe it’s doing something. It might be absorbing ambiguity from earlier in the process. Or it could be the place where competing priorities finally have to be resolved. The delays looks like the problem, but can be a symptom of a gap that the organization hasn't found a better way to fill yet.

The same logic applies to interpersonal and cross-team friction. If the same two teams keep clashing, the instinct is to work on the relationship between them, clarify the roles, improve communication. Sometimes that helps. When it doesn’t, it's likely that the teams are structurally positioned to want different things, and no amount of communication training resolves the structural incentive. They're built to be in tension, and they'll stay in tension until something about how they're built changes.

So the first thing worth doing, before anything else, is making a short list. Not of problems, but of patterns. What are the two or three things in your organization that keep coming back? The ones where someone in the room, when it comes up yet again, says "of course." Write them down plainly, the way you'd describe them to someone outside the organization who doesn't know the jargon or the history. Just what keeps happening.

Then ask a different question about each one. Don't ask what caused it this time. Ask how long it's been happening, what's been tried, and whether the problem tends to get worse when the organization is under more pressure, when there's more to do, more urgency, more at stake. That last part matters more than it might seem right now. We'll come back to it.

For the moment, the goal is just to see the pattern clearly and take it seriously as information rather than as evidence of failure. Something in the system is producing it. That something is findable. And finding it is a very different task than fixing the latest instance of it.

Next time, we'll look at what that something usually turns out to be, because most repeating problems are protecting something the organization or its people actually value, even if nobody would say it out loud.