The Essence of Failure

The Essence of Failure is a very famous book in Japan. By analyzing the various defeats of the Imperial Japanese Army and Navy during World War II, the authors hold up a mirror to let readers see how an organization gradually undermines itself through its systems, culture, and processes. Although it focuses on the problems of the Japanese military, its analysis of root causes applies remarkably well to modern organizations.

Failure is rarely the result of a single momentary mistake; rather, it is the outcome of long-term systemic imbalances and cultural inertia.

During a project, failure usually doesn’t stem from a single cause, but rather accumulates from small details over time.

Here are a few reasons mentioned in the book:

• Diffuse authority and fragmented responsibility
• Information blocking and filtering: lower ranks afraid to report the reality
• Prioritizing spiritual doctrine over material resources
• Dogmatism
• Lack of self-reflection and improvement

When an organization becomes accustomed to concealing bad news, prizing obedience over questioning, or narrowing its metrics of success down to a single quantitative target, it becomes extremely fragile under external pressure.

The authors use case studies to deconstruct these effects, illustrating that without fixing structural flaws, individual heroism or last-minute improvisations cannot reverse the overall trend—and the “spirit of Bushido” alone certainly won’t turn the tide of battle.

Software Development

Information

For example, when frontline engineers are afraid to report risks or user pain points, upper management ends up making decisions based on distorted information.

Imagine a manager who isn’t on the front lines, whose knee-jerk reaction to any problem is: “Why is this feature (substitute whatever here) taking so long? It’s so simple!”

However, most software requirements are inherently ambiguous and subject to constant change, and coding inevitably involves a great deal of exploration. Development isn’t merely about churning out a feature; it also requires considering historical context, how to integrate with the existing codebase, and how to make future development smoother.

Don’t Get Trapped by Past Success

In an era of relentless advancements in LLMs and AI, many ways of doing things will gradually shift. In this era, unifying knowledge and action is a fantastic approach. However, never stop questioning or cease reviewing and evolving simply because of past successes.

Learn from Failure

Bugs and incidents are inevitable in software development. Companies of a certain scale usually have formal incident reporting mechanisms. Suppose the system suddenly goes down today and won’t boot up. How do developers and executives react? Do they get angry, pass the buck, and search for scapegoats, or do they have a standard operating procedure to minimize the damage caused by the incident?

When an incident occurs, getting emotional is the single most useless reaction.

To learn from failure, you must ensure that the same mistake doesn’t happen again. To achieve this, management must cultivate a blameless culture focused on finding solutions:

• The product belongs to everyone; blaming a single person indicates a flaw in the company’s system.
• The codebase is the collective technical debt and shared legacy of all R&D; attributing faults solely to a specific individual similarly signals a broken development process.

Years ago, a thread went viral on Reddit: Accidentally destroyed production database on first day of a job, and was told to leave, on top of this i was told by the CTO that they need to get legal involved, how screwed am i?

The post recounted how a new hire accidentally wiped out the production database on his very first day. At a certain step, instead of copying the value output by a tool, he used an environment variable listed in the documentation—which happened to point directly to the production environment. In the end, the employee was fired on the spot.

I wonder what your reaction is when reading this story. Do you think, “How could this employee be so careless and not check if the values were correct?” Or do you think, “How could a developer make such an egregious mistake?” Approaching the situation with this mindset guarantees you’ll be hit even harder when the next disaster strikes.

A company that operates on wishful thinking without maintaining proper backups for its production database is inevitably bound to pay the price sooner or later. People only realize the importance of backups after data is lost. If a brand-new hire can so effortlessly delete the production database, it means any other employee could have done it eventually too.

Among the many comments, someone shared Netflix’s approach.

I don’t recall the exact details, but from what I remember, not only do they regularly run disaster recovery drills to practice rapid backups, but they also configure permissions meticulously and even incentivize employees with bounties if anyone manages to break the production database.

Confronted with the exact same problem, one company resorts to immediate blame, while the other addresses it through systems and processes to eliminate human error.

Don’t Rely on Slogans

A slogan must be backed by institutional implementation to be worthy of respect. For instance, in companies where “iterate rapidly, move in small steps” is merely a slogan, it often ends up being an excuse to exploit engineering output while showing zero respect for engineering expertise.

If genuinely put into practice, it should manifest in several concrete ways:

• Placing a strong emphasis on CI/CD so developers can deploy painlessly
• Recognizing that development speed has physical limits
• Polishing all underlying infrastructure so developers can focus purely on building
• Valuing the establishment of documentation and processes
• Understanding that rapid iteration inevitably requires trading off some degree of quality