When to Use the Standard Pattern (Foundation-Building Approach)
The "7+1" golden rule (a seven-role internal review plus one external audit) does not always need to run through all three full rounds. The previous chapter covered when it is appropriate to make that shift.
Here we look at the reverse question: when should you not skip any rounds? This chapter lays out the conditions under which the standard pattern -- running all three rounds -- is the right choice.
The procedure of "consulting seven internal roles, receiving external audit, and repeating up to three rounds" is what we call the standard pattern in this series. Because it builds the design from the ground up, it is also called the foundation-building approach. It takes time and effort. Even so, there are situations where skipping it creates more problems than it solves.
Condition 1: Introducing a New Architecture
When designing an architecture (the overall structure and skeleton of a system) for the first time, use the standard pattern.
When building a new skeleton, the volume of problems that surface in round one tends to be high. Because there is no prior example, everyone participating in the consultation sees the subject for the first time. Fresh eyes miss things easily -- yet they also produce the kind of "this feels off" reactions that only a first look can generate. Run round one carefully to draw out both.
After making corrections, round two confirms consistency, and round three nails down the details. Without these three stages, problems that were invisible in round one emerge later and force the entire design to be rebuilt from scratch. Cutting corners at the foundation stage drives up the cost of corrections later.
Condition 2: Fundamental Changes That Overturn Existing Assumptions
When you change the criteria or assumptions that have been treated as correct up to that point, use the standard pattern.
When an assumption changes, the impact ripples into other parts that depend on it. The full extent of that ripple is not visible at the moment the change is decided.
For example, say we change a rule from "make decisions in a weekly batch" to "make decisions on demand as needed." The change looks like a single point, but it reaches into the criteria for when to start a consultation and into priority rules when multiple consultations overlap. These cascading effects cannot be fully traced in one round.
Rounds two and three let you verify in order "what has changed after each correction" and capture the full extent of the ripple.
Condition 3: First Attempts in Unfamiliar Territory
When making a type of decision for which there is no prior example, use the standard pattern.
When there is prior experience, you can narrow the focus of checks with the prediction that a similar problem to last time will likely appear. In unfamiliar territory, there is no way to know in advance what is likely to go wrong.
Trying to lock things down in one round produces the result of "solving only the visible problems while leaving the invisible ones behind." Running three rounds allows perspectives that did not emerge in round one to appear in rounds two and three.
The question is not "is three rounds enough?" It is "how do we surface all first-look problems within those three rounds?" The less prior experience there is, the more valuable each additional round becomes.
Condition 4: High-Irreversibility Decisions
When making a decision that is difficult to reverse later, or where the cost to reverse it is extremely high, use the standard pattern.
An irreversible action (one that cannot be returned to its prior state) leaves no room to undo. You cannot proceed on the assumption that "if a problem comes up, we can fix it later." For that reason, you need to surface as many problems as possible before acting.
In this series, article publication, major design changes, and external agreements are treated as examples of high-irreversibility decisions. Once something is published it cannot be taken back; walking back a major change after the fact causes even larger impact than the change itself did.
Running three rounds is how we close off as many problems as possible at the last point where action is still available.
Condition 5: Changes Where the Scope of Impact Cannot Be Read in Advance
When you cannot tell at the time of a change "how far the impact will reach," use the standard pattern.
Taking a shortcut while the scope of impact is still unknown leaves parts that were assumed to be checked but were not. Problems stay undetected until they surface on their own.
Going through three rounds gradually brings the "outside" of what was confirmed in round one into view in rounds two and three. Problems that appear as side effects of corrections sometimes reveal that the impact was wider than assumed. When the full width cannot be read in advance, multiple rounds of checking are the only available option.
What the Five Conditions Have in Common
The five conditions listed here share a common structure.
In every case, these are situations where the cost of missing something is high.
For a new architecture, a missed issue leads to a complete redesign from the ground up. For a fundamental change, a missed ripple triggers cascading problems. In unfamiliar territory, there is no way to know in advance what has been missed. In an irreversible decision, there is no opportunity to correct what was missed. In a change of unknown scope, problems arise in the territory that was overlooked.
In situations where the cost of missing something is high, skipping rounds becomes a risk in itself. The cost of missing something is greater than the cost of the extra effort.
What to Do After Deciding to Use the Standard Pattern
Once we decide to use the standard pattern, the only thing left is to run three rounds in order.
The decision of "does this situation call for the standard pattern?" is settled by checking whether any of the five conditions above apply. If it applies, use the standard pattern. If it does not, other approaches become available options.
We do not think it through from scratch each time. We narrow it down to checking the conditions. That is why we built this condition list. In practice, we open this list and check against it each time a decision comes up.