Most bad decision making processes do not look bad.
They look responsible.
One more review. One more stakeholder. One more analysis. One more framework. One more requirement before the team can move.
Any one of those steps might be necessary. But one of the harder parts of decision making in leadership is knowing when rigor is protecting the outcome and when “good process” has quietly become an excuse for delay.
I recently found a question that is changing how I make that distinction:
Is this a necessary control, or have we turned it into an artificial prerequisite?
The question came into focus while I was reading Dave Kellogg’s “Simplifiers Go Far, Complexifiers Get Stuck.” Kellogg describes a pattern I have seen in organizations for years: progress slows, the work becomes “complicated,” and a growing set of plausible prerequisites begins standing between the team and the outcome.
The word that caught me was artificial.
Some prerequisites are real. A consequential claim may need evidence. A financial decision may need review. A security change may need testing. A public campaign may need the right approvals. Removing those controls in the name of speed is not leadership. It is recklessness.
But the opposite failure is just as real. A process can accumulate so many reviews, dependencies, frameworks, checklists, handoffs, and “one more things” that the organization begins protecting the process instead of producing the outcome.
At some point, the process designed to improve the decision becomes the reason nobody can make one.
Good decision making needs friction. Just not all of it.
Recently, I have been tightening an AI-enabled execution approach I call Think → Build → Prove. The purpose is straightforward: think through consequential decisions, build the work, then prove that the result still satisfies the objective and did not quietly introduce a new problem.
As the work became more sophisticated, I added stronger evaluation and regression controls. In plain English, regression control means checking that an improvement in one area did not make an already-approved part of the work worse.
That discipline matters. AI systems can produce a better headline and accidentally weaken an approved positioning statement. A revised workflow can solve one bottleneck while introducing three new handoffs. A polished deliverable can look stronger while drifting away from the original business requirement.
So controls matter.
But I also saw the danger on the other side.
If every improvement requires another framework, every framework requires another evaluator, every evaluator needs another validation step, and every validation step becomes a condition for shipping, the system eventually stops protecting quality.
Congratulations. You now have a beautifully governed way to not finish the work.
It starts protecting delay.
That distinction changed how I think about leadership systems. The goal is not maximum process. The goal is the minimum sufficient control required to produce a responsible outcome.
Artificial prerequisites are dangerous because they sound responsible
The easiest bad process to remove is the one everyone knows is pointless.
Artificial prerequisites are harder because they usually sound reasonable.
We cannot launch until the training is complete. We cannot make the decision until another stakeholder reviews it. We cannot test the idea until the whole operating model is documented. We cannot publish until the new framework is finished. We cannot start the new process until every edge case has been resolved.
Any one of those statements might be true.
The leadership work is determining whether it is actually true this time.
Kellogg’s example is useful because it exposes the test. If a process supposedly cannot begin because training is incomplete, what training is really required? If the essential instruction can fit on one page and people can absorb it in a few minutes, “training” may have become a respectable-sounding reason not to move.
I see the same failure mode in modern AI adoption. A team decides it needs an AI strategy before it can test one workflow. Then it needs a governance framework before it can create the strategy. Then it needs a steering committee before it can approve the framework. Months later, the organization still has no evidence from actual work.
Meanwhile, another team tests one bounded use case, keeps the appropriate controls in place, learns what breaks, and makes the next decision with better evidence.
The second team is not necessarily less rigorous.
It may simply be better at separating necessary controls from artificial prerequisites.
The hard part is not adding process. It is knowing when to remove it.
I do not believe the answer is “move fast and remove all friction.” Some friction protects the business. Some slows the business down for a good reason. Strong decision making is not about eliminating process; it is about matching the process to the consequence of the decision.
The stronger question is: What deserves friction?
- Does this step reduce a specific material risk? If nobody can name the risk, the step may be ritual rather than control.
- Will the result of this step change a decision? If the answer will not alter what happens next, ask why the step exists.
- Is this control based on an observed failure? Repeated problems can justify structure. Imagined problems can create bureaucracy before the work even begins.
- Can we proceed responsibly without it? If the team can move safely, learn from real execution, and preserve the ability to correct course, the prerequisite may not be a prerequisite at all.
That last question is especially important in an AI-enabled organization because the cost of producing another analysis, document, scorecard, or framework has collapsed.
We used to need a committee to create bureaucracy. Now a single person with an AI assistant can generate it before lunch.
That sounds like an advantage, and it is. But cheap production also makes it cheap to create bureaucracy.
AI can generate the 40-page strategy nobody needed, the 17-point evaluation rubric nobody will use, the additional workflow that duplicates an existing workflow, and the detailed operating manual for a process that has never been tested.
The limiting factor is increasingly not our ability to create structure.
It is our judgment about which structure deserves to exist.
Simplification is not removing thought. It is concentrating it.
This is where the idea connects to another Kellogg post I recently read: “The One Key to Dealing with Senior Executives: Answer the Question!”
His advice on executive communication is essentially to answer what was asked, keep the answer concise, and leave the executive a thread to pull if more detail matters.
That is a communication version of the same leadership principle.
Do not make the executive work through five minutes of context to discover the answer.
Do not make the organization work through five layers of process to reach the outcome.
In both cases, the leader absorbs complexity, determines what matters, and presents the shortest responsible path forward.
That is very different from pretending the underlying problem is simple.
A good simplifier may understand more dependencies, tradeoffs, risks, and alternatives than anyone else in the room. The difference is that those details have been processed rather than dumped onto everyone else.
Leadership simplification is not the absence of rigor. It is the ability to carry complexity without making everyone else carry it too.
This changes how I want to lead with AI
I wrote recently about stopping the chase for AI tools and designing an AI workflow around clear responsibilities. I also wrote about refusing to build another marketing system just because I found a useful framework.
This is the leadership principle underneath both decisions.
Capability does not automatically deserve a workflow.
A workflow does not automatically deserve a framework.
A framework does not automatically deserve a governance layer.
And a control does not automatically deserve to become a permanent prerequisite.
The standard I want is simpler: use enough structure to improve the decision-making process, protect the consequential risk, and produce reliable work. Then execute.
When the work produces evidence, update the system. When a failure repeats, add the control that addresses it. When a step stops changing decisions or reducing material risk, question whether it still belongs.
That approach also fits the way I increasingly think about learning: Learn → Apply → Transform.
Learn enough to make the decision responsibly. Apply the smallest complete intervention that can produce evidence. Transform the process when experience shows the change deserves to become repeatable.
Not every useful idea needs to become infrastructure.
The question I am taking forward
When progress starts slowing and the explanation is that we need one more review, one more system, one more meeting, one more document, or one more prerequisite, I want to ask a harder question before automatically accepting the delay:
What specific risk does this protect us from, and what happens if we move without it?
If there is a consequential answer, keep the control.
If there is not, simplify.
Because leadership is not measured by how sophisticated the process looks.
It is measured by whether the organization can make good decisions, produce good work, learn from reality, and keep moving.
