Failure is usually treated as a psychological problem. Something goes wrong, and then we are told to be resilient, learn from it, and try again.
This is too shallow.
In genuinely uncertain work, failure is not merely an emotional cost paid after the plan. It is one of the mechanisms by which the plan produces truth.
The question is not how to avoid failure, nor how to make peace with it. The question is how to design a path on which reality can say no early, clearly, and usefully.
Maximum Uncertainty, Maximum Information
The simplest mathematical version of this idea appears in Claude Shannon’s information theory.
Suppose an experiment has only two possible outcomes: success or failure. Let the probability of success be p. The entropy of the outcome is:
H(Y) = -p log₂ p - (1-p) log₂(1-p)
For a binary outcome, entropy reaches its maximum when p = 0.5. At that point, neither result is predetermined. Observing the outcome can eliminate the greatest amount of uncertainty.
As p moves toward either zero or one, entropy falls. A result that was almost guaranteed contains less information because it rules out fewer possibilities. Moving toward any predetermined answer means giving reality less room to tell us something new.
This does not mean every real experiment should be tuned to fail half the time. In Bayesian experimental design, the real objective is expected information gain: how much an observation changes what we believe about the underlying parameters.
I(Θ;Y) = H(Y) - EΘ[H(Y|Θ)]
The useful principle is narrower and more important: an experiment becomes less informative as its outcome becomes more predetermined.
A guaranteed success mostly confirms the design of the test. A guaranteed failure is no better. The valuable boundary is where several explanations are still alive and one observation can kill most of them.
A Failure Is Useful Only If It Changes the Next Move
Failure is not automatically information.
An unobserved failure is only damage. A failure with no competing hypotheses is only confusion. A failure that cannot change the next decision is only repetition.
For failure to teach, the experiment has to be bounded and instrumented. It should reveal which assumption was wrong, preserve enough evidence to distinguish causes, and feed that evidence into the next version of the system.
SpaceX is a visible example of this logic, but not the source of it. NASA’s launch-vehicle failure analysis records how the first three Falcon 1 flights failed for different reasons and how hardware, software, checks, tank design, and staging logic changed in response. The fourth Falcon 1 reached orbit. SpaceX later described Starship as a rapid iterative development program in which flight data, root-cause analysis, and corrective action feed directly into the next vehicle.
The explosion is not the lesson. The changed system is the lesson.
Not every visible failure proves intelligence. Repeating the same failure for the same reason is not iteration; it is negligence with better branding. But the opposite error is also common: making every test so safe that it protects the team’s reputation while teaching the team nothing.
The Bitter Lesson Is a Systems Lesson
Richard Sutton’s essay The Bitter Lesson describes a recurring pattern in artificial intelligence. Researchers repeatedly encoded human knowledge, intuition, and handcrafted structure into their systems. Those methods often worked in the short term and then plateaued. More general methods that could scale through computation, search, and learning eventually went further.
The lesson is bitter because we want our own cleverness to be the valuable part. We prefer a system that succeeds because it contains our insight. We are less comfortable building one that can search beyond us, learn from outcomes, and make our favorite explanation irrelevant.
Founders reproduce the same mistake inside companies.
They prevent failure by routing uncertainty through themselves. They review every message, approve every hire, rewrite every pitch, and personally rescue every ambiguous situation. For a while, the company appears unusually intelligent because the founder is carrying the intelligence manually.
But that is not a learning system. It is a dependency.
A real operating system must be able to generate a hypothesis, test it against the world, capture the result, and change the next action without requiring one person to reinterpret everything from scratch. The founder’s job is not to make the system incapable of failure. It is to make failure cheap enough, visible enough, and informative enough that the system improves.
This is the same architectural shift I keep returning to in AI-native organizations: the human defines the objective and the judgment boundary, while the system carries more of the execution, observation, and feedback loop.
Failure Should Exist Before the Experiment
The cliché that founders should “make peace with failure” treats failure as an accident followed by an emotional recovery. First the plan breaks; then the founder practices maturity.
A better design begins before the experiment. It defines:
- the assumption being tested;
- the evidence that would prove it wrong;
- the maximum acceptable blast radius;
- the data that must survive either outcome;
- the decision that will change afterward; and
- the system update that prevents paying twice for the same lesson.
You do not merely endure failure. You purchase information with it. But the purchase is rational only when the information survives and changes the system.
Test the cheapest fragile assumption first. Make the blast radius smaller than the lesson. Instrument the result before launching the experiment. Decide in advance what evidence will make you stop, continue, or change direction.
Failure that you merely survive is pain. Failure that changes the system is information.
Designing the Path
Designing failure into a path does not mean desiring failure, romanticizing risk, or forcing every probability toward fifty percent. It means creating the conditions under which a wrong belief becomes difficult to preserve.
The person who never fails may be working too close to what is already known—or defining every outcome as success after the fact. The person who fails constantly without learning is simply incompetent. Productive work lives between those positions: uncertain enough to teach, bounded enough to survive, and instrumented enough to update the next move.
Most organizations quietly optimize for a predetermined answer. Tests are designed to validate the proposal. Reports are written to protect the owner. Failures are renamed, while successes are amplified. The organization appears stable because reality has been removed from the loop.
Truth requires a veto.
To design failure into the path to truth is to preserve that veto: to build a process in which reality can contradict the plan before the plan becomes too expensive, too political, or too entangled with identity to change.
The opposite of truth-seeking is not failure. It is a process in which success has already been decided before reality is consulted.