While tightening my AI-enabled execution approach, Think → Build → Prove, I began questioning how much control the work needed. Every useful control can become another condition for finishing the work. A better evaluation needs a check. That check needs validation. Eventually, improving the system can consume the time it was supposed to save.
I want controls that catch a weakened positioning statement, a missed requirement, or a workflow change that breaks an existing handoff. I also need to recognize when another review will leave the decision exactly where it was. The difficult part of decision making is separating those two situations.
Dave Kellogg gave me useful language for that distinction in “Simplifiers Go Far, Complexifiers Get Stuck.” He describes slow progress accompanied by plausible-sounding artificial prerequisites. The word that caught me was artificial. A requirement can sound responsible without protecting anything that matters.
What does the next review protect?
Some prerequisites are real. A consequential claim needs evidence. A financial decision may need review. A change affecting access or sensitive information may need testing and approval. Removing a control because it delays the launch does not resolve the risk it was designed to address.
But adding a review does not automatically improve the decision either. In my own work, regression checks have a specific job: confirm that an improvement did not damage an already-approved part of the work. If AI improves a headline but weakens the positioning underneath it, the check has caught something worth correcting.
The problem starts when that purpose disappears beneath the procedure. Every improvement requires another framework, every framework needs another evaluator, and every evaluator adds a condition for shipping. Congratulations. You now have a beautifully governed way to not finish the work.
The standard I want is the minimum sufficient control for a responsible outcome. That requires naming the risk, deciding what evidence would address it, and recognizing when the check is complete.
A plausible prerequisite still needs testing
Kellogg uses the example of delaying a new process because training is incomplete. His challenge is to examine what training is actually required: perhaps a page people can read in a few minutes would be sufficient. That does not make training unnecessary. It makes the size of the requirement open to examination.
Consider a team that wants to test one AI-assisted workflow. It could spend months designing a strategy, governance framework, and committee before anyone tries the work. Whether that sequence is justified depends on the proposed use, the information involved, the consequences of failure, and any approvals the business requires.
A bounded test may provide better evidence for the next decision. It might also reveal a risk that warrants stopping. The point is to distinguish what must be resolved before the test from what the test can responsibly help the team learn.
When another prerequisite appears, I want to know what it changes:
- Which material risk does it reduce? Name the failure it is intended to prevent.
- Could its result change the decision? Identify what would make the team proceed, revise, or stop.
- What makes the control necessary now? An observed failure can justify it, but so can a credible risk that would be costly to discover through failure.
- Can the team proceed responsibly within a narrower scope? Sometimes the answer is a smaller test. Sometimes the missing evidence or authority means waiting.
These questions should help make a decision, not become another approval ritual. If the team can explain why a control is needed, keep it. If nobody can explain what it protects or changes, examine whether it belongs.
AI makes it cheap to add structure
AI can produce another analysis, operating manual, evaluation rubric, or workflow before the existing one has been tested. That capability is useful when the missing structure solves a real problem. It also makes it easy to mistake a growing collection of documents for progress.
I wrote about stopping the chase for AI tools and assigning systems clear responsibilities. I also wrote about refusing to build another marketing system simply because I found a useful framework. Both decisions come back to the same question: what work becomes possible or more reliable because this structure exists?
A useful idea may improve an instruction, a handoff, or a single decision. It does not always need to become a permanent framework. When a failure repeats, add a control that addresses it. When a step stops changing decisions or reducing material risk, question whether it still earns its place.
The leader should absorb some of the complexity
Kellogg makes a related point in “The One Key to Dealing with Senior Executives: Answer the Question!” Give a direct answer, keep it concise, and leave room for the executive to ask for detail. The analysis still matters; the listener should not have to reconstruct it to discover your answer.
I see a similar responsibility in process design. A leader needs to understand the dependencies, risks, and tradeoffs, then make the path through them clear. Passing every unresolved detail to the next person does not make the organization more rigorous. It leaves someone else to do the thinking.
That is how I want to apply Learn → Apply → Transform: learn enough to choose responsibly, apply a complete intervention within an appropriate scope, and change the process when the evidence warrants it. The next review should have a defined purpose and an end.
When progress stalls, ask what specific risk the proposed step protects against and what would happen if the team proceeded without it. Keep the controls the answer justifies. Remove or narrow the rest, then finish the work.
