The Law of Failure

Here is a detailed explanation of The Law of Failure, one of the most crucial yet counterintuitive laws in Steven Bartlett's The Diary of a CEO, followed by specific examples tailored for an engineer's context.

The Law of Failure: "Failure is not the opposite of success; it is a prerequisite."

1. Definition: What Is the Law of Failure?

Bartlett's Law of Failure (Law 31 in the 33-law framework) challenges the conventional view that failure is something to be avoided, minimized, or hidden. Instead, he argues that failure is an essential component of the success equation.

Core Principle: Success is not the absence of failure. Success is the ability to fail repeatedly, learn quickly, and persist until the variables align.

Bartlett draws a sharp distinction between two mindsets:

Mindset View of Failure Outcome

Fixed Mindset Failure is a reflection of inherent ability. "I failed, therefore I am a failure." Avoids risk, stays in comfort zone, stagnates.

Growth Mindset Failure is data. "I failed, therefore I learned something valuable." Embraces risk, iterates rapidly, improves.

The Law of Failure states that the speed of your success is determined by the speed at which you fail, learn, and apply the lesson.

2. The Psychology of Failure

Bartlett explains why failure feels so painful and why that pain often leads to counterproductive behavior:

A. The Ego Protection Mechanism

The brain interprets failure as a threat to social standing and self-worth. In evolutionary terms, being rejected by the tribe meant death. Consequently, the brain triggers a strong emotional response—shame, fear, defensiveness—to prevent future failures.

The problem: This mechanism, designed to protect you, actually prevents growth. It makes you:

· Hide mistakes instead of sharing them

· Blame external factors instead of learning

· Avoid challenging situations altogether

B. The Attribution Error

When people succeed, they attribute it to their skill. When they fail, they attribute it to external circumstances. This distortion prevents accurate learning.

Bartlett argues that the person who can honestly ask "What did I do wrong?" without defensiveness has a massive competitive advantage.

C. Failure as Tuition

Bartlett reframes failure as an investment. He suggests viewing every failure as a tuition payment for an education you could not get any other way.

"The question is not whether you will fail. The question is: how quickly will you fail, how cheaply will you fail, and how much will you learn when you do?"

3. Types of Failure

Not all failures are equal. Bartlett distinguishes between different categories:

Type of Failure Description Example

Strategic Failure The idea or approach was fundamentally wrong. Building a product nobody wants.

Execution Failure The idea was sound, but implementation was flawed. Poor coding practices lead to critical bugs.

Timing Failure The idea was good, but the market was not ready. Launching a VR product before hardware adoption.

Process Failure Systems were inadequate to support success. No version control; merge conflicts cause crashes.

Preventable Failure Caused by negligence or ignoring known risks. Skipping testing to meet a deadline.

Intelligent Failure A well-planned experiment that yielded valuable data despite negative results. An A/B test that disproves a hypothesis.

Bartlett emphasizes that intelligent failures—those that are calculated, contained, and designed to generate learning—are not just acceptable; they are essential.

4. How to Fail Intelligently

Bartlett outlines a framework for failing in ways that accelerate success rather than derail it:

Principle Explanation

Fail Fast Do not spend months or years validating an idea. Create small experiments to test assumptions quickly. The faster you fail, the faster you learn.

Fail Cheap Minimize the cost of failure. Do not bet the company on an unproven hypothesis. Use MVPs (minimum viable products), prototypes, and small-scale tests.

Fail Forward Every failure must produce a lesson that improves the next attempt. If you fail and learn nothing, you have wasted the failure.

Fail Publicly (Strategically) Hiding failure prevents collective learning. When appropriate, share failures with your team so everyone benefits from the lesson.

Separate Identity from Outcome You are not your failure. Your project failed; you are learning. This psychological separation is essential for resilience.

5. Example for an Engineer

Let us apply The Law of Failure to the context of a software engineer, product engineer, or engineering leader.

Scenario: Building a New Feature

Context: You are a senior engineer at a tech company. You have an idea for a new feature that you believe will significantly improve user retention. You are excited. You estimate it will take three months to build.

Approach A: Failure-Avoidant Mindset (How Most Engineers Operate)

You spend weeks perfecting the architecture. You write extensive documentation. You build the entire feature in isolation, afraid to show incomplete work. After three months, you launch to great fanfare.

Result: User engagement does not increase. In fact, some users complain that the feature complicates the interface. You spent three months building something nobody wanted.

Emotional response: Defensiveness. "The users just don't understand it." "Marketing didn't promote it properly." "The data must be wrong."

Learning: Minimal. You are too invested to see clearly. The next feature follows the same pattern.

Approach B: Intelligent Failure Mindset (Applying the Law of Failure)

You recognize that the feature is a hypothesis, not a certainty. You design a failure-informed process:

Phase Action Failure Principle

Week 1: Assumption Testing Instead of writing code, you write down your assumptions: "Users will discover this feature without onboarding." "This feature will increase session time by 20%." You share these with product managers and ask them to poke holes. Fail cheap — no code written yet.

Week 2: Smoke Test You build a fake door test: a button that says "New Feature (Coming Soon)" that logs how many users click it. You discover only 2% of users are interested. Fail fast — you learn interest is low before building anything.

Week 3–4: Prototype Instead of building the full feature, you build a clickable prototype in Figma. You test it with five users. Three are confused. You iterate. Fail cheap — design changes cost hours, not weeks.

Week 5–6: Sparse MVP You build only the core functionality—no polish, no edge cases, no documentation. You release to 1% of users with feature flags. Fail forward — you collect real usage data.

Week 7: Analyze Data shows users try the feature once and never return. You interview users. They say it solves a problem they don't actually have. Intelligent failure — you learned that the problem was misidentified.

Week 8: Pivot or Kill You present findings: the feature is not worth further investment. The team reallocates to a higher-value project. You document learnings for future reference. Strategic learning — the failure becomes a asset for future decisions.

Comparison of Outcomes

Metric Failure-Avoidant Approach Intelligent Failure Approach

Time Invested 3 months 2 months (including learning)

Code Debt 3 months of code to maintain or delete Minimal code written

User Impact Negative (unwanted feature launched) None (feature never launched)

Team Learning Little; blame cycle emerges High; documented insights benefit future work

Next Project Same risk of building unwanted features Better problem identification; higher success probability

6. Engineering-Specific Applications

Here are additional ways the Law of Failure applies specifically to engineering practice:

A. Code Reviews and Blameless Post-Mortems

In many engineering cultures, a production outage triggers a blame-seeking process. Bartlett's framework aligns with the blameless post-mortem approach pioneered by organizations like Google and Etsy.

Blame-Oriented Frame Learning-Oriented Frame

"Who wrote this bug?" "What conditions allowed this bug to reach production?"

"This engineer made a mistake." "Our testing process failed to catch this. How do we improve it?"

Bartlett's Law of Failure applied: The failure is not the bug. The failure would be not learning from the bug. The post-mortem is where failure transforms into value.

B. Experimentation Culture

Engineers at high-performing tech companies (Netflix, Amazon, Meta) run thousands of experiments per year. Most fail. This is not a problem; it is the system working.

Metric Low-Failure Culture High-Failure Culture

Experiment Success Rate 80% 20%

Innovation Speed Slow Fast

Risk Tolerance Low High

Learning Velocity Low High

Bartlett's framework explains why: organizations that fear failure only pursue sure things. Sure things are usually incremental. Breakthroughs require experiments that might fail.

C. Technical Debt and Refactoring

Many engineers fear refactoring because it might introduce bugs—a form of failure aversion. The Law of Failure reframes this:

· Failure-avoidant: "I won't touch this legacy code. It works. If I change it and something breaks, I'll be blamed."

· Intelligent failure: "This code is accruing technical debt. The failure is not introducing a bug during refactoring. The failure is letting the system degrade until it collapses under its own weight."

In this frame, inaction becomes the greater failure.

D. Career Development for Engineers

Engineers often stay in comfortable roles because they fear failing in a new domain. Bartlett's law suggests the opposite:

"If you are not failing regularly in your career, you are not growing. Comfort is the enemy of capability."

Career Behavior Outcome

Stays in known stack, familiar problems Steady but stagnant; vulnerable to industry shifts

Takes on stretch projects, new languages, leadership tasks Fails sometimes, but builds broader capability; long-term trajectory is steeper

7. The Failure Resume

Bartlett shares a practice he calls the "Failure Resume" —a document where you list your failures, what you learned from each, and how you applied the lesson.

For an engineer, a failure resume might include:

Failure Lesson Application

Deployed a breaking change on a Friday afternoon Never deploy before weekends Established a "no-deploy Friday" policy

Built a feature users ignored Building without user research is gambling Introduced user interviews before development

Chose a trendy framework that became obsolete Hype is not a technical criterion Implemented a technology evaluation rubric

Misestimated a project by 4x Optimism bias distorts estimates Switched to story-pointing with historical velocity

Bartlett argues that a person who can articulate their failures clearly is more valuable than a person who claims never to have failed. The former has demonstrated learning capacity; the latter has demonstrated either dishonesty or risk aversion.

8. Why the Law of Failure Matters in the Book's Structure

The Law of Failure sits in Part 3: The Philosophy, which combines internal mastery and external communication into a durable approach to leadership and strategy.

Its placement is deliberate:

· Part 1 (The Self) taught you to master your internal response to failure—to separate identity from outcome, to resist defensiveness.

· Part 2 (The Story) taught you how to communicate failures in ways that build trust (vulnerability, proximity, authenticity).

· Part 3 (The Philosophy) now elevates failure from a personal event to a strategic asset—something to be designed for, leveraged, and systematized.

9. Summary: The Law of Failure

Element Summary

Definition Failure is not the opposite of success; it is a prerequisite. Success is the ability to fail, learn, and persist.

Core Principle Your speed of success is determined by your speed of failure and learning.

Fixed vs. Growth Mindset Fixed mindset sees failure as identity; growth mindset sees failure as data.

Intelligent Failure Calculated, contained experiments designed to generate learning.

Types of Failure Strategic, execution, timing, process, preventable, intelligent.

Engineering Application Blameless post-mortems, experimentation culture, technical debt, career growth.

Failure Resume A document listing failures, lessons, and applications—a demonstration of learning capacity.

Book Context Part 3 (The Philosophy)—failure as a strategic asset, not a personal flaw.

Quick Reference: Engineer's Failure Checklist

Step Action

1 Before building, identify assumptions and test them cheaply (smoke tests, prototypes).

2 Use feature flags to limit blast radius of failures.

3 Conduct blameless post-mortems; document lessons, not blame.

4 Maintain a personal failure resume to track learning.

5 Distinguish between preventable failures (negligence) and intelligent failures (calculated experiments).

6 Ask regularly: "What have I failed at recently?" If the answer is "nothing," you are not taking enough risk.