A building inspector knows that most structural failures are not surprises. The signs are usually visible long before anything falls. A crack along the load-bearing wall. A sag in the floor that gets a little worse each year. Water staining that no one repaired. The inspector can name the failure pattern and predict the eventual collapse, often with uncomfortable accuracy.
Decision systems work the same way. Organizations rarely fail at decision-making in some unique, custom-built way. They fail in patterns. Recognizable, recurring, predictable patterns. Once you have seen them a few times, you can walk into a new organization and spot the cracks within a few meetings.
Here are the four I see most often.
Failure mode one: the missing question
A team has a meeting to make a decision. The data is presented. The options are debated. A choice is made. Everyone leaves.
What never quite happened: an explicit conversation about what question they were actually trying to answer.
This is the most common failure mode and the hardest to spot from the inside. The team felt productive. The meeting felt like decision-making. The decision got made. But because no one named the question carefully, the answer might or might not address it. The team might have answered a smaller, easier-looking version of the real question without noticing. Or they might have answered a question the data was suited for, rather than the question the situation actually demanded.
You see this most clearly in retrospect. Six months later, the decision is producing strange results, and someone says, "Wait, what were we even trying to solve there?" Everyone gets quiet, because no one is quite sure.
The fix is simple, but it requires discipline. Before the data goes on the screen, name the question. Write it down. Say it out loud. Ask whether everyone agrees that this is the question worth answering. Most teams skip this step because it feels obvious. It is not obvious. It is the most important step, and the one most likely to be wrong.
Failure mode two: false consensus
A senior leader walks into a meeting with a preferred direction. They do not say it out loud. They do not have to. The team knows. The conversation looks like real deliberation, with options considered and trade-offs discussed, but the gravitational pull of the leader's preference shapes everything. The team converges on the preferred answer and leaves convinced they made a thoughtful decision.
This is false consensus. It is decision-making that looks like a real conversation but is not.
The cost is invisible in the short term and enormous in the long term. The organization learns that disagreement is performative. People stop bringing their honest views to meetings. The decisions that get made are the ones the most senior person was already inclined toward. Over time, the organization loses access to the cognitive diversity that would have made its decisions better.
The fix is mostly about the senior leader's behavior. State your preference openly so it can be argued with, or stay silent until the team has worked through the options. Do not hint, do not signal, do not let your facial expressions do the work. Make it safe to disagree, and reward the people who do, especially when they turn out to be right and you turn out to be wrong.
Failure mode three: the assumption that did not get examined
Every decision rests on assumptions. Some are explicit. Most are not. The architectural failure is that the implicit ones almost never get examined.
A pricing team decides on a 10 percent increase. The decision rests on the assumption that customer demand is inelastic at this scale. No one says that out loud. No one tests it. Six months later, demand falls more than expected, and the team is confused about why their model was wrong.
A strategy team decides to enter a new market. The decision rests on the assumption that the competitive landscape will look roughly the same in eighteen months as it does today. No one names the assumption. No one tracks it. By the time the assumption breaks, the strategy is already in motion.
A hiring team decides on a new screening process. The decision rests on the assumption that past performance predicts future performance in the way the screening tool measures it. No one tests it. The team trusts the tool. Two years later, the data shows the screening was actively filtering out their best hires.
In each case, the assumption was findable. It just was not made visible. The fix is a small ritual. Before any meaningful decision is finalized, ask the question: "What are we assuming here, and how would we know if we were wrong?" Three minutes of this practice prevents months of confused regret later.
Before any meaningful decision is finalized, ask: what are we assuming here, and how would we know if we were wrong? Three minutes of this practice prevents months of confused regret later.
Failure mode four: the loop that does not close
A decision gets made. Time passes. The world keeps moving. The original decision keeps quietly being executed by people who do not know whether it is still the right one, because no one has gone back to check.
This is the loop that does not close. The architectural failure is treating decisions as one-time events instead of as positions that need to be revisited when conditions change.
I see this constantly. A team decides on a vendor. A year later, the vendor is no longer the right fit, but no one is reviewing the decision. A leader decides on a structure. Three years later, the structure is the source of half the organization's problems, but the decision has calcified into "just how things are." A pricing team decides on a tier. Five years later, the tier is wrong, but it sits on the website unexamined.
Each individual decision was fine at the time. The architectural failure is that none of them had a built-in review cycle. The system has no way to ask, "Is this still right?" until the cost of the misalignment becomes impossible to ignore.
The fix is to design review cycles into decisions when they are first made. For every meaningful decision, ask: when do we re-examine this? What would we have to see to change it? Who owns the review? Without those questions answered, the decision becomes permanent regardless of whether the conditions that produced it still apply.
Why these four keep happening
None of these failure modes are stupid. They are not signs of bad leadership or weak people. They are predictable outputs of systems that were never designed for the work they are now being asked to do.
Most decision systems were built in an earlier era, when decisions were fewer, slower, and more clearly owned. The pace and complexity of the work has changed. The decision system, in most cases, has not. So the same patterns keep producing the same failures, in different industries, with different leaders, year after year.
The good news is that all four failure modes are addressable. Not with a transformation program. With small, deliberate changes in how decisions get made. Name the question. State your preference openly. Examine the assumptions. Design the review cycle. None of these are expensive. None require new technology. All four require attention, and the willingness to slow down the meeting just enough to do the harder work.
The building inspector's job is part diagnostic and part prevention. Spotting the patterns. Recommending the repairs. Helping people see what they would otherwise miss because they walk past it every day.
The same role exists in organizations, mostly informally, and mostly unfilled. Someone has to be looking at the cracks. Someone has to name the failure pattern before it produces a collapse. Someone has to be willing to slow down a meeting long enough to ask the question that should have been asked before the data went on the screen.
That role is available in your organization, today, regardless of your title. The only requirement is a willingness to notice. And once you start noticing, you cannot stop. The patterns are everywhere.