The Board That Catches What Your Team Won't Tell You
There is a gap between what your written process says and what your team actually does. That gap is where the expensive failures live. Most teams never see them because nobody is looking for the gap. Here is the discipline that catches them five minutes before they ship.
Yesterday at 4pm I almost shipped three things that would have broken by Friday.
The only reason I didn't: I ran my own plan through six adversaries before I executed it.
I built an internal review board of six people whose only job is to interrogate my plans before they go live. Reality. Standards. Scope. Evidence. Risk. Readiness. Six angles. One plan at a time.
Yesterday they caught three things I had missed. Every one of them was the kind of mistake that ships in most service businesses every week because nobody is looking for it.
This article is about what they found, why those failures are universal, and how to run the same discipline on the work coming out of your company starting tomorrow.
The three failures they caught
The first was an approval step that did not exist.
The plan said "the system confirms with the user before proceeding." Nobody had actually built the confirmation step. Half the time it would have run cleanly. The other half, an action would commit silently with no consent. That is not a process. That is the appearance of a process.
The second was a decision with no record.
When the user said "yes," the agreement would have landed in the database with no trail of what was being agreed to. A week later, when a client asks "why did we do this," there is no proposal to point at. No context. No defense. The action happened. The reasoning evaporated.
The third was an SOP citing a step that nobody performs.
The plan referenced a permission pattern the team supposedly used everywhere. The pattern did not actually exist in the workflow. Somewhere between the written process and the real one, the cited step quietly disappeared. The plan was leaning on a fiction.
Three different shapes of the same root problem. The written process and the actual process had drifted apart, and nobody had verified the gap.
Why these survive in most businesses
The cost of a defect rises sharply the later it gets caught. IBM's research on systems development found that a defect caught during design costs roughly six times less to fix than one caught after release. The Systems Sciences Institute placed that ratio closer to one hundred times for code that reaches production. The shape of the curve is the same outside of software. The Project Management Institute reports that rework consumes between 30 and 50 percent of total project effort in poorly managed programs. The Construction Industry Institute placed the direct cost of rework at 5 percent of total project value, with indirect costs pushing the total far higher.
The economics are not hidden. The reason they keep eating margin anyway is that most teams have no checkpoint between "we agree on the plan" and "we execute it." The plan goes from approval straight to action. If something was missed in the plan, the first time anyone notices is when the work has already been done.
Inside a team, people who could have caught the gap usually stay quiet. Not because they are hiding anything. Because by the time they could speak up, the work is already underway and nobody wants to be the one who slows momentum. Catching the failure publicly looks like obstruction. So they let it go and assume someone else will say something. Nobody does.
The three fixes most founders try first
When a leader sees the pattern, the instinct is to add structure. Three structures show up most often.
The tighter SOP. Someone gets pulled off other work to document the process more clearly. The document is comprehensive. It is also read once and then ignored. The team does not refer back to it during execution because the SOP describes a stable past. The work in front of them is novel.
The review step. A new gate gets added between approval and execution. The gate is owned by nobody specifically. Sometimes it happens. Sometimes it does not. When it does happen, the person reviewing has no authority to actually stop anything. They become a rubber stamp.
The project manager hire. Someone is brought in whose job is to make sure things do not slip. Within a quarter they have become the bottleneck. Every decision now waits on their availability. The team starts routing around them to keep moving.
Each of these fails for the same reason. They treat the symptom as a documentation problem when it is actually a verification problem.
The reframe
You do not have an SOP problem. You have a verification problem.
There is a gap between what your written process says and what your team actually does. That gap is where the expensive failures live. Most teams never see them because nobody is looking for the gap. Nobody whose job is specifically to find what the plan is missing, the moment before execution.
The fix is not another document. It is a moment, before execution, when someone adversarial walks the plan and asks three questions.
What assumption is this depending on?
What standard is this violating?
What is verified versus what is assumed?
Three questions. Five minutes. They will not catch everything. They will catch the cheap mistakes that would have been ten times more expensive to clean up later.
Why this is a discipline, not a tool
The temptation is to look for software that solves this. There is no software that solves this. The discipline lives in the posture, not the product.
Run it with one person whose job for five minutes is to find the holes. Run it with three people, each looking from a different angle. Run it with six. The number matters less than the role. The reviewer is not there to validate the plan. They are there to find what the plan is missing.
This is the same logic behind Toyota's andon cord. Any worker on the line can pull it to stop production when they spot a defect. The point is not the cord. The point is the cultural permission to stop, before the defect propagates, without being treated as the problem. Atul Gawande's work on surgical checklists at the World Health Organization landed in the same place. The checklist reduced major surgical complications by 36 percent across eight hospitals in three years. Not because it added new medicine. Because it forced a verification moment that the team had been skipping.
The pattern transfers. A verification moment, owned by someone whose only job in that moment is to find what was missed, beats a tighter document every time.
How to start tomorrow
Pick one plan, decision, or piece of work that is about to be executed.
Before it ships, walk it through the three questions. Out loud, with someone in the room whose job is to push back.
What assumption is this depending on. What standard is this violating. What is verified versus what is assumed.
Write down whatever the conversation surfaces. Adjust the plan. Then ship.
If the conversation surfaces nothing, the plan was clean and you spent five minutes on insurance. If it surfaces one thing, you just avoided a much more expensive cleanup. Either way, the cost of the catch is always smaller than the cost of the patch.
The teams that operate this way move faster than the teams that ship, fail, and fix. Not because they are more cautious. Because their failures get caught at the cheapest possible point in the cycle.
A board you can fit in five minutes is the difference.
Sources
- IBM Systems Sciences Institute, Relative Cost of Fixing Software Defects
- Construction Industry Institute, The Field Rework Index
- Project Management Institute, Pulse of the Profession
- Toyota Production System, Andon Cord History
- Atul Gawande et al., A Surgical Safety Checklist to Reduce Morbidity and Mortality, NEJM
- McKinsey, Three Keys to Faster, Better Decisions
Built to Think
Your decisions, packaged so a small adversarial moment catches the failures before they ship. See what a Brain Map reveals about the gaps inside your business.
See this in your own business.
We run a live workshop where we walk through exactly where your business intelligence is accessible and where it is still trapped. You will leave with a clear picture of what needs to be packaged first.
Join the Live Workshop


