Founder's Fog: When Decision Volume Exceeds Capacity

Why do founders often lose clarity right when their companies are doing well?

This question bothered me enough to spend time reading about it, decision science, cognitive load, organisational design, even how the military and large tech companies think about decision-making at scale.

What stood out was a simple pattern.

Early-stage companies fail because of bad decisions.

Scaling companies slow down because of too many decisions.

Most research around cognitive load points to the same constraint: humans don’t struggle with complexity as much as they struggle with simultaneity. When multiple decisions remain open at the same time, they continue to consume attention, even when you are not actively working on them. This is why clarity drops without anything visibly breaking.

Founders feel this first.

As companies grow, decisions stop arriving sequentially and start arriving in parallel, product trade-offs, people decisions, customer exceptions, long-term bets. Each decision is reasonable. The issue is aggregate load. The brain was never designed to hold dozens of unresolved trade-offs at once.

This is what I now think of as Founder’s Fog (this by the way is a real term and people are studying it).

Founder’s Fog is technically not stress, burnout or confusion. It is the predictable result of decision volume exceeding decision-processing capacity. Research describes this as cognitive saturation. Founders experience it as loss of sharpness.

What makes this phase dangerous is that it’s invisible on dashboards. Execution continues. People stay busy. Meetings increase. But fewer decisions actually reduce uncertainty. The organisation produces activity faster than it produces clarity.

This is perhaps the reason why founders often misread this phase and try to fix it with more reviews, more inputs or more effort, when the real issue is that clarity itself has become the scarcest resource.

I am writing this because once you see this pattern, you stop treating it as a personal failure and start treating it as a design problem and design problems always have solutions.