Saturday, 28 March 2026

The Law of the Story

Here is a detailed explanation of The Law of the Story, one of the most powerful communication principles in Steven Bartlett's The Diary of a CEO.

The Law of the Story: "Facts are forgotten; stories are remembered."

1. Definition: What Is the Law of the Story?

The Law of the Story (Law 19 in the 33-law framework) states that human beings are not wired to remember facts, data, and abstract information. We are wired to remember stories.

Core Principle: 
Facts inform, but stories transform. Facts engage the logical brain (the neocortex), but stories engage the entire brain—emotion, sensory experience, memory, and meaning-making. When you want people to remember, care, and act, you must embed your message in a story.

Bartlett argues that most communication—whether in business, engineering, or leadership—fails because it is delivered as a collection of facts. The presenter assumes that if the facts are clear, the audience will be convinced. But the human brain does not work that way. Facts alone do not create belief, motivation, or memory. Stories do.

The insight: You can have the most compelling data in the world, but if you cannot tell a story around it, the data will be forgotten. The story is the container that makes the facts stick.

2. The Neuroscience of Story

Bartlett grounds the Law of the Story in how the brain processes narrative versus abstract information:

Brain Response Facts Alone Stories
Language Processing Broca's area and Wernicke's area activate (language comprehension only). Language areas activate, plus sensory, emotional, and memory areas.
Emotional Engagement Minimal. Facts are processed neutrally. Strong. Oxytocin (trust hormone) is released when characters and emotions are present.
Memory Encoding Weak. Facts are stored as abstract data, easily forgotten. Strong. Stories are encoded across multiple brain regions, creating rich retrieval paths.
Decision-Making Logic-based. Easily overridden by emotion. Emotion-based. Stories create belief that persists even when logic is challenged.
Transportation The listener remains outside the information. The listener is "transported" into the narrative, experiencing it as if it were real.

Key neurological finding: When a person hears a story that resonates, their brain activity mirrors the storyteller's brain activity. This phenomenon, called neural coupling, means that stories literally synchronize brains. Facts do not achieve this.

3. Facts vs. Stories: A Detailed Comparison

Dimension Facts Stories
Structure Discrete, abstract, decontextualized Narrative arc: context, conflict, resolution, meaning
Emotion Neutral or absent Evokes specific emotions (fear, hope, empathy, anger)
Memory Forgotten quickly. The brain treats facts as low-priority. Remembered for years. Stories are prioritized by the brain.
Persuasion Logical appeal. Easy to counter with opposing facts. Emotional appeal. Creates belief that resists counter-argument.
Connection Distant. Facts create distance between teller and listener. Intimate. Stories create proximity (The Law of Proximity).
Action Facts inform but rarely compel action. Stories compel action. They create urgency, meaning, and motivation.

Bartlett's formulation:

"Facts tell. Stories sell. Facts inform. Stories transform. Facts are the what. Stories are the why."

4. The Anatomy of a Powerful Story

Bartlett outlines the essential elements of a story that sticks:

Element Description Example
Character A protagonist the audience can relate to. Someone with goals, flaws, and humanity. "A young engineer who felt like an imposter..."
Context The world the character inhabits. The stakes. What is at risk. "...joined a team where everyone seemed to know more than her."
Conflict The obstacle, challenge, or enemy. The source of tension. "Then came a production outage at 3 AM, and she was the only one on call."
Struggle The journey through difficulty. Setbacks, failures, learning. "She spent hours debugging, made mistakes, almost gave up..."
Resolution How the conflict was resolved. What changed. "...but she found the root cause, fixed it, and the team trusted her from that day forward."
Meaning The lesson, the takeaway, the universal truth. Why this story matters. "What she learned was that imposter syndrome is not a sign of incompetence—it is a sign of growth."

Bartlett's insight: A story without conflict is not a story; it is an anecdote. A story without meaning is not memorable; it is entertainment. The most powerful stories have both.

5. Why Facts Fail: The Illusion of Persuasion

Bartlett explains why we overestimate the power of facts:

Reason Explanation
The Curse of Knowledge Once you know something, you cannot imagine what it was like not to know it. Experts present facts assuming they are self-explanatory.
The Backfire Effect When people's core beliefs are challenged by facts, they often double down on their original belief rather than change their mind.
Confirmation Bias People filter facts to confirm what they already believe. Facts that contradict existing beliefs are dismissed.
Information Overload We are drowning in data. More facts do not break through the noise; they add to it.

The solution: Do not present facts alone. Embed them in stories. A fact embedded in a story bypasses defense mechanisms. It is not "data being shoved at me"; it is "a truth I discovered through someone else's experience."

6. The Law of the Story: Engineer's Perspective

For an engineer, storytelling is often neglected. Engineering culture prizes precision, data, and logical argument. But the most effective engineers learn to wield stories.

A. Presenting Technical Decisions

Approach Facts-Only Story-Embedded
Architecture Decision "We should adopt microservices because they offer better scalability, independent deployment, and team autonomy." "Six months ago, we had a monolithic deployment that took three hours. Every time we shipped, the entire team held their breath. One bug in one module meant rolling back everything. Last week, with microservices, we deployed a critical security patch in 12 minutes. No one had to coordinate. No one had to wait. That is what we are building toward."

Why the story works:

· The story creates emotional memory (anxiety, relief).
· The facts (scalability, independent deployment) are embedded in a lived experience.
· The audience remembers the pain of the old system and the relief of the new one.

B. Debugging and Post-Mortems

Approach Facts-Only Story-Embedded
Incident Review "The outage was caused by a race condition in the cache layer. We have implemented a fix and added monitoring." "At 2:47 AM, Sarah's pager went off. She was the only one on call. The system was down. Users were seeing 503 errors. For 45 minutes, she traced through logs, her heart racing, unable to find the cause. Then she noticed something—two services writing to the same cache key at different times. A race condition buried in code written two years ago. She fixed it at 3:45 AM. The next morning, we added monitoring to detect this pattern. And we made a rule: no cache design without a review. Sarah's 3 AM panic is now preventing 3 AM panics for everyone."

Why the story works:

· The audience experiences the incident through Sarah's perspective.
· The facts (race condition, monitoring, rule) are memorable because they are attached to a human experience.
· The story creates empathy for on-call engineers and urgency for prevention.

C. Advocating for Quality or Technical Debt

Approach Facts-Only Story-Embedded
Refactoring Request "We have accumulated 400 hours of technical debt. If we do not refactor, future feature development will slow by 30%." "Last month, Maria spent three days adding a simple toggle. Three days. The code was so tangled that what should have been a two-hour change required untangling a spaghetti of dependencies. She cried at her desk. She told me, 'I feel incompetent.' She is not incompetent. The code is broken. We are asking brilliant engineers to work with broken tools. Let's fix the tools."

Why the story works:

· The facts (400 hours, 30% slowdown) are abstract. Maria's three days and her tears are concrete.
· The story creates emotional urgency that spreadsheets cannot.
· Stakeholders remember Maria's experience long after they forget the numbers.

D. Mentoring and Teaching

Approach Facts-Only Story-Embedded
Teaching a Junior Engineer "You should always handle exceptions properly. Unhandled exceptions can crash the application." "When I was a junior, I once deployed code that didn't handle a database timeout. The first time the database had a hiccup—30 seconds of latency—the entire service crashed. It was 6 PM on a Friday. I spent four hours debugging, with my manager sitting next to me, watching me panic. I learned that day: exceptions are not optional. They are the difference between a system that fails gracefully and a system that fails catastrophically."

Why the story works:

· The junior engineer remembers the story, not just the rule.
· The story creates emotional stakes (panic, embarrassment, learning).
· The story establishes credibility—"I made this mistake too, and here is what I learned."

7. The Law of the Story: CEO's Perspective

For a CEO, storytelling is not a soft skill; it is a core leadership capability. The CEO's primary job is to align people around a mission, and alignment is achieved through stories.

A. Communicating Strategy and Vision

Approach Facts-Only Story-Embedded
Company All-Hands "Our Q3 revenue grew 15%. We added 50 new customers. We are on track for our annual target." "When we started this company, we had one customer—a small coffee shop that took a chance on us. Last quarter, we added 50 customers. But the one I want to tell you about is a nonprofit in rural India. They are using our platform to deliver education to children who have no schools. That customer represents why we exist. The 15% growth is not just a number. It is 50 more organizations that can do their work because of what we build."

Why the story works:

· The numbers become meaningful. They are not abstract; they represent human impact.
· The story reinforces the Cathedral (Law of the Cathedral)—the mission behind the numbers.
· Employees remember the nonprofit, not just the revenue target.

B. Navigating Crisis and Change

Approach Facts-Only Story-Embedded
Layoff Announcement "Due to market conditions, we must reduce headcount by 15%. This decision was difficult but necessary." "I started this company in my apartment. I remember the day we hired our tenth person. We celebrated with pizza. I looked around the room and thought, 'These people trust me with their livelihoods.' Today, I have to tell you that we are letting 15% of our team go. I failed to foresee the market shift. I failed to build a larger reservoir. That failure is mine. To those leaving: you did nothing wrong. You were brilliant. I failed you. To those staying: we will rebuild. We will build a bigger reservoir. And we will never forget the people who got us here."

Why the story works:

· Facts alone (15%, market conditions) create fear and resentment.
· The story creates ownership ("I failed"), empathy, and a shared commitment to rebuild.
· The story preserves dignity for those leaving and purpose for those staying.

C. Building Culture and Values

Approach Facts-Only Story-Embedded
Reinforcing Values "Our value is 'customer first.' We should always prioritize customer needs." "Two years ago, we had a customer—a small business owner named Elena. Her payment processor failed on Black Friday. She called us in a panic. Our support engineer, David, spent his entire Saturday walking her through a manual fix. He did not have to. It was not his job. But he said, 'She trusted us. I could not let her down.' That is customer first. Not because a handbook says so. Because when a person is counting on you, you show up."

Why the story works:

· Values without stories are slogans. Slogans are forgotten.
· Stories make values concrete, memorable, and emotionally compelling.
· Employees know what "customer first" looks like because they have a model.

D. Winning Investors and Customers

Approach Facts-Only Story-Embedded
Pitch Deck "We have a $10B total addressable market. Our solution reduces costs by 30%. We project 40% CAGR." "Let me tell you about Maria. Maria runs a logistics company. Every day, her trucks drive empty on return trips. Fuel wasted. Money lost. She tried every software solution—none worked. Then she found us. Today, her trucks run full both ways. She saved $200,000 last year. That is money that paid for her daughter's college tuition. Maria is one customer. There are millions of Marias. That is the opportunity."

Why the story works:

· Investors hear hundreds of pitches with TAM, CAGR, and margins. They forget them.
· They remember Maria. They remember the human problem. They remember the emotional connection.
· The story makes the market real. It is not abstract; it is millions of Marias.

8. How to Craft Powerful Stories: A Framework

Bartlett offers a practical framework for crafting stories that stick:

Step Question to Answer Example
1. Who is the protagonist? Who is the audience meant to relate to? A junior engineer, a customer, the founder.
2. What was the world before? What was the context? What was the problem? Slow deployments, fragile systems, missed opportunities.
3. What was the conflict? What obstacle had to be overcome? A critical bug, a skeptical stakeholder, a near-failure.
4. What was the struggle? What setbacks, mistakes, or difficulties occurred? Failed attempts, late nights, moments of doubt.
5. What was the resolution? How was the conflict overcome? A breakthrough, a learning, a success.
6. What is the meaning? What universal truth does this story teach? Resilience, the value of preparation, the power of teamwork.
7. What is the call to action? What should the audience do with this story? Adopt a practice, support an initiative, believe in the mission.

9. Common Storytelling Mistakes

Bartlett warns against common pitfalls:

Mistake Why It Fails Fix
No Conflict Without conflict, there is no tension. The story feels flat. Include the struggle, the failure, the obstacle. Perfection is boring.
Too Much Detail Details obscure the core message. The audience gets lost. Strip away anything that does not serve the meaning.
No Emotional Stakes If the audience does not feel something, they will not remember. Make sure the story evokes an emotion: fear, hope, empathy, anger, relief.
The Hero Is You A story where you are the flawless hero creates distance, not connection. Make the protagonist someone the audience can relate to. Your role should be observer, facilitator, or learner.
No Clear Meaning If the audience does not know why you told the story, they will not know what to do with it. State the meaning explicitly. Do not assume it is obvious.

10. The Relationship Between Story and Other Laws

The Law of the Story connects to and amplifies many of Bartlett's other laws:

Law Relationship to Story
Law of the Lizard Stories are the most effective way to speak to the lizard brain. They evoke emotion before logic.
Law of Proximity Stories create proximity. When you share a story, the listener feels closer to you and to the experience.
Law of the Cathedral The Cathedral is a story—a narrative about why the organization exists and where it is going.
Law of the Teacher Teaching is most effective when wrapped in stories. Lessons embedded in stories are remembered.
Law of the Wound Your wounds are your most powerful stories. Sharing them creates connection and credibility.

11. Why the Law of the Story Matters in the Book's Structure

The Law of the Story sits in Part 2: The Story, the section on mastering your external message. Its placement is central:

· Part 1 (The Self) built the internal foundation—discipline, reservoirs, comfort with discomfort.
· Part 2 is about communicating that foundation to the world.
· The Law of the Story is the capstone of Part 2. It is the mechanism through which all other communication laws (Proximity, Lizard, Cathedral) are operationalized.

Bartlett's deeper argument: Story is not one communication technique among many. Story is the container for all communication. If you cannot tell a story around your message, your message will not survive contact with the human brain.

12. Summary: The Law of the Story

Element Summary
Definition Facts are forgotten; stories are remembered. The human brain is wired for narrative, not abstract data.
Core Principle Facts inform, but stories transform. Facts engage logic; stories engage emotion, memory, and meaning.
Neuroscience Stories activate multiple brain regions, create neural coupling, and release oxytocin (trust). Facts activate only language centers.
Anatomy of a Story Character, context, conflict, struggle, resolution, meaning.
Engineer Applications Presenting technical decisions, incident reviews, advocating for quality, mentoring.
CEO Applications Communicating strategy, navigating crisis, building culture, winning investors and customers.
Crafting Framework Identify protagonist, describe before world, present conflict, show struggle, reveal resolution, extract meaning, call to action.
Common Mistakes No conflict, too much detail, no emotional stakes, self as hero, no clear meaning.
Book Context Part 2 (The Story)—story is the container that makes all other communication stick.

Quick Reference: Storytelling Checklist

Question For Engineers For CEOs
Who is the protagonist? The user? The junior engineer? The system? The customer? The employee? The company?
What conflict is being overcome? A technical challenge? A failure? A learning curve? A market challenge? A cultural issue? A crisis?
What emotion should the audience feel? Relief? Curiosity? Confidence? Hope? Urgency? Trust? Determination?
What is the meaning—the universal truth? "Good testing prevents outages." "Our mission matters more than short-term profit."
What should the audience do after hearing? Adopt a practice? Support a decision? Align with strategy? Support a change?


The Law of Wall Dicipline

Here is a detailed explanation of The Law of the Wall, one of the most foundational and habit-centered laws in Steven Bartlett's The Diary of a CEO.

The Law of the Wall: "Discipline is the ability to do what is necessary even when motivation is absent."

1. Definition: What Is the Law of the Wall?

The Law of the Wall (Law 11 in the 33-law framework) draws its name from the image of a wall being built brick by brick. Each brick, by itself, is insignificant. But laid consistently over time, brick after brick, a wall emerges that is strong, enduring, and capable of withstanding immense pressure.

Core Principle: 
Motivation is fleeting. Discipline is structural. Motivation is the feeling that compels you to act. Discipline is the system that ensures you act regardless of how you feel. People who achieve extraordinary results do not rely on motivation. They build walls of discipline that carry them through days when motivation is absent.

Bartlett argues that we have been sold a lie: that success comes from finding your passion, waiting for inspiration, or waking up motivated. 

In reality, success comes from showing up when you do not want to. From laying bricks when no one is watching. From building a wall so strong that even your weakest moments cannot break through.

The insight: Motivation is a feeling. Discipline is a choice. Feelings change. Choices compound.

2. The Motivation Myth

Bartlett dismantles the cultural obsession with motivation:

Myth Reality
"I need to feel motivated before I start." Motivation often follows action, not the other way around. Starting creates momentum. Momentum creates motivation.
"Successful people are always motivated." Successful people have mastered the art of acting without motivation. They have built systems that operate regardless of emotional state.
"If I find my passion, discipline will be easy." Even people who love their work have days they do not want to do it. Passion does not eliminate resistance; discipline overcomes it.
"Motivation is reliable." Motivation is volatile. It depends on sleep, mood, external validation, and countless uncontrollable factors. Discipline is reliable.

Bartlett's observation: Waiting for motivation is like waiting for perfect weather to start a journey. The disciplined traveler walks in rain, wind, and exhaustion—and arrives while the motivated traveler is still waiting.

3. The Wall Metaphor: Brick by Brick

Bartlett uses the wall metaphor to illustrate how discipline compounds:

Element Meaning
The Brick A single act of discipline. A day of showing up. A task completed when you did not want to.
The Wall The accumulated result of consistent discipline over time. A skill mastered. A business built. A body transformed.
The Mortar The systems, habits, and structures that ensure bricks are laid consistently. Routines, schedules, accountability.
The Foundation The "why"—the deeper purpose that sustains discipline when motivation fades.

Key insight: No single brick is impressive. Anyone can lay one brick. The wall is impressive. But you cannot build a wall without laying bricks when you do not feel like it.

4. Discipline vs. Motivation: A Detailed Comparison

Dimension Motivation Discipline
Source External (inspiration, results, praise) or fleeting internal emotion Internal (choice, commitment, system)
Reliability Unreliable. Fluctuates with mood, energy, circumstances. Reliable. Operates regardless of circumstances.
Duration Short-term. Motivation spikes and fades. Long-term. Discipline compounds over time.
Dependency Dependent on results. If results are slow, motivation dies. Independent of results. Discipline persists even when results are invisible.
Control Largely outside your control. You cannot will yourself to feel motivated. Entirely within your control. You can choose to act regardless of feeling.
Role in Success Helpful for starting. Useless for sustaining. Essential for sustaining. The engine of long-term achievement.

Bartlett's formula:

Motivation starts the journey. Discipline finishes it.

5. The Three Levels of Discipline

Bartlett identifies three levels at which discipline must operate:

Level Description Example
Level 1: Task Discipline 
The ability to complete specific tasks even when you do not want to. Writing that documentation. Fixing that bug. Making that sales call.

Level 2: System Discipline 
The ability to maintain routines, habits, and structures consistently over time. Daily code review. Weekly learning session. Quarterly planning.

Level 3: Identity Discipline 
The ability to act in alignment with your values and commitments even when no one is watching. Maintaining integrity when cutting corners would be easy. Showing up for your team when you are exhausted.

Bartlett argues that most people focus on Level 1 (task discipline) but neglect Level 2 (system discipline) and Level 3 (identity discipline). True mastery requires all three.

6. The Law of the Wall: Engineer's Perspective

For an engineer, discipline is not just a personal virtue; it is a professional necessity. The quality of your work, the trajectory of your career, and the reliability of the systems you build all depend on discipline.

A. Code Discipline: Writing Quality Code Every Day

Undisciplined Behavior Disciplined Behavior
Writing tests only when you have time (never) Writing tests as part of every change. Test discipline is non-negotiable.
Taking shortcuts to meet deadlines Maintaining quality standards even under pressure. Explaining when shortcuts are taken and tracking technical debt.
Inconsistent style and structure Consistent patterns, naming conventions, and architecture. Code that looks like it was written by one disciplined mind.
Merging code that "probably works" Testing thoroughly. Reviewing carefully. Never merging code you are not confident in.

Why Discipline Matters:

· Undisciplined code accumulates technical debt. Each shortcut is a brick missing from the wall.
· Disciplined code creates a system reservoir (Law of the Reservoir). When pressure comes, the system holds.

Example:

Two engineers joined the same team. Engineer A wrote tests when it was convenient. When deadlines pressed, tests were skipped. Code reviews were rushed. Engineer B was disciplined: tests always, reviews always, documentation always. After six months, Engineer A's code was fragile. Every change broke something. He spent most of his time firefighting. Engineer B's code was stable. She added features easily. She was trusted with critical systems. The difference was not talent. It was discipline.

B. Learning Discipline: Consistent Skill Development

Undisciplined Behavior Disciplined Behavior
Learning only when forced by a project Scheduled, consistent learning regardless of immediate need
Shallow learning (tutorials, copy-paste) Deep learning (fundamentals, building from scratch, teaching others)
Letting busy periods kill learning Protecting learning time even during busy periods
Learning what is easy or familiar Deliberately learning uncomfortable topics (The Law of the Uncomfortable)

Why Discipline Matters:

· Technology evolves constantly. Undisciplined learning leads to skill obsolescence.
· Disciplined learning creates a knowledge reservoir that compounds over time.

Example:

An engineer committed to 30 minutes of deliberate learning every morning before checking email. Not when he felt like it. Not when he had time. Every day. Over a year, he built deep expertise in distributed systems, Rust, and machine learning. When his company needed to build a new AI-powered service, he was the only engineer qualified to lead it. His discipline had built a wall that others could not scale.

C. Review Discipline: Code Reviews and Feedback

Undisciplined Behavior Disciplined Behavior
Rushing through code reviews Giving thoughtful, thorough reviews every time
Approving code you have not fully understood Reviewing until you understand and agree
Avoiding giving critical feedback Giving honest, constructive feedback even when it is uncomfortable
Taking feedback personally Receiving feedback without defensiveness, using it to improve

Why Discipline Matters:

· Undisciplined reviews allow bugs, technical debt, and architectural flaws into the codebase.
· Disciplined reviews maintain system quality and create learning opportunities for the whole team.

Example:

A tech lead was disciplined about code reviews. He never approved code he had not fully understood. He always explained his reasoning. He was patient with junior engineers, walking them through improvements. His reviews took time. Sometimes they delayed releases. But his team's codebase was the cleanest in the company. Outages were rare. New engineers learned quickly. His discipline built a wall of quality that protected the entire organization.

D. Communication Discipline: Documentation and Knowledge Sharing

Undisciplined Behavior Disciplined Behavior
Knowledge lives only in your head Documenting decisions, patterns, and lessons consistently
Writing documentation only when required Writing documentation as part of every project, as a professional habit
Leaving documentation outdated Updating documentation when systems change
Avoiding communication Communicating clearly, proactively, and consistently

Why Discipline Matters:

· Undisciplined knowledge sharing creates bus factors—single points of failure.
· Disciplined documentation creates organizational memory and accelerates onboarding.

Example:

An engineer made it a discipline to write an architecture decision record (ADR) for every significant decision. Not when she had time. Every decision. She documented trade-offs, alternatives, and rationale. Two years later, when the team was trying to understand why a system was built a certain way, her ADRs provided the answers. New engineers learned faster. The team avoided repeating past mistakes. Her discipline had built a wall of institutional knowledge that outlasted her individual presence.

E. Career Discipline: Showing Up When You Do Not Want To

Undisciplined Behavior Disciplined Behavior
Coasting when bored or uninspired Maintaining effort regardless of engagement level
Avoiding difficult tasks Tackling hard problems even when you would rather avoid them
Letting frustration derail progress Working through frustration with systems and structure
Waiting for motivation to return Creating discipline that operates independently of motivation

Why Discipline Matters:

· Every career has seasons of boredom, frustration, and difficulty.
· Discipline carries you through these seasons. Without it, you stall or regress.

Example:

An engineer was assigned to maintain a legacy system he hated. The code was ugly. The users were demanding. The work was unglamorous. Motivation was zero. But he was disciplined. He showed up every day. He cleaned what he could. He documented what he learned. He did not let his lack of motivation affect his output. After 18 months, the legacy system was stable. He had learned more about resilience, debugging, and system architecture than he had in years of greenfield work. That experience made him the company's expert on system reliability. His discipline transformed a miserable assignment into a career-defining strength.

7. The Law of the Wall: CEO's Perspective

For a CEO, discipline operates at the organizational level. The culture of the company, the consistency of execution, and the long-term viability of the business all depend on the CEO's discipline—and the systems of discipline they create.

A. Strategic Discipline: Sticking to the Mission

Undisciplined Behavior Disciplined Behavior
Chasing every new opportunity that appears Saying no to opportunities that do not align with the mission (The Law of the Cathedral)
Changing direction based on short-term pressure Maintaining strategic consistency even when the market is volatile
Adding features to satisfy every customer Building only what serves the core mission
Letting competitors dictate strategy Staying true to your own vision

Why Discipline Matters:

· Undisciplined strategy creates scattered execution. The company tries to be everything to everyone and excels at nothing.
· Disciplined strategy creates focus. Focus creates excellence.

Example:

A CEO had a clear mission: build the most reliable infrastructure software in the industry. Customers constantly asked for new features. Investors wanted expansion into adjacent markets. The undisciplined CEO would have said yes to everything. He stayed disciplined. He said no to features that did not serve reliability. He said no to markets that diluted focus. Five years later, his company was not the biggest. But it was the most trusted. Enterprise customers paid premiums because they knew the product would not fail. His discipline built a wall of reputation that competitors could not breach.

B. Cultural Discipline: Enforcing Standards

Undisciplined Behavior Disciplined Behavior
Making exceptions for high performers Holding everyone to the same cultural standards
Avoiding difficult performance conversations Addressing misalignment directly and consistently
Letting toxicity fester Removing toxic individuals regardless of their contribution
Saying culture is important but not acting on it Enforcing culture through hiring, promotion, and termination decisions

Why Discipline Matters:

· Culture is not what you say; it is what you tolerate.
· Undisciplined culture management allows one toxic person to poison the entire organization.

Example:

A CEO had a top salesperson who brought in 30% of revenue. But the salesperson bullied junior staff, ignored processes, and created a culture of fear. The undisciplined CEO would have kept him, rationalizing that revenue mattered more. The disciplined CEO let him go. Revenue dropped. The board was concerned. But within six months, the culture healed. New salespeople joined. Collaboration improved. Within a year, revenue exceeded previous levels. The CEO's discipline had sacrificed short-term gain for long-term health.

C. Financial Discipline: Managing Resources

Undisciplined Behavior Disciplined Behavior
Spending when revenue is high, assuming it will continue Spending conservatively, building reserves (Law of the Reservoir)
Hiring based on short-term need Hiring thoughtfully, ensuring each hire aligns with long-term strategy
Avoiding hard financial decisions Making cuts when necessary, protecting the long-term health of the company
Chasing growth at any cost Pursuing sustainable growth, even when it is slower

Why Discipline Matters:

· Undisciplined spending creates fragility. When the market shifts, there is no buffer.
· Disciplined financial management creates resilience. The company can survive downturns and seize opportunities.

Example:

A CEO ran a SaaS company. During a boom year, competitors spent heavily—lavish offices, aggressive hiring, expensive marketing. He stayed disciplined. He kept burn rate low. He built a financial reservoir. When the market turned, competitors collapsed. He had runway for 24 months. He hired the best talent from failed startups at reasonable salaries. He outspent competitors when they could not spend at all. His discipline had turned a downturn into an opportunity.

D. Personal Discipline: The CEO's Own Wall

Undisciplined Behavior Disciplined Behavior
Letting the company's chaos dictate your schedule Maintaining personal routines regardless of organizational pressure
Skipping sleep, exercise, or reflection because "there is too much to do" Protecting health, energy, and clarity as non-negotiable
Reacting to every crisis personally Disciplining yourself to delegate, trust, and focus on what only you can do
Allowing your identity to be consumed by the company Maintaining identity and practices outside the company

Why Discipline Matters:

· The CEO's discipline sets the example for the entire organization.
· An undisciplined CEO creates an undisciplined company.

Example:

A CEO made a discipline of writing three priorities every morning before checking email. Not when he had time. Every day. This practice kept him focused on strategy while the organization pulled him toward operations. His team noticed. They started writing their own priorities. The company developed a culture of clarity and intentionality. His small discipline had scaled into an organizational capability.

8. How to Build Discipline: A Practical Framework

Bartlett offers practical strategies for building discipline that lasts:

Strategy Explanation Application
Start Smaller Than You Think Discipline is built through consistency, not intensity. A tiny habit maintained is more powerful than a grand effort abandoned. Engineer: 10 minutes of learning daily. CEO: One hard conversation weekly.
Separate Decision from Action Decision fatigue depletes discipline. Remove decisions by creating automatic systems. Engineer: Fixed time for deep work daily. CEO: Fixed agenda for leadership meetings.
Use Environmental Design Your environment shapes your behavior more than willpower. Design environments that make discipline easier. Engineer: Turn off notifications. CEO: Delegate decisions that do not require your judgment.
Build Identity, Not Just Habits "I am a disciplined person" is more powerful than "I should be disciplined." Act as if your identity is already established. Engineer: "I am someone who writes tests." CEO: "I am someone who makes hard calls."
Track Consistency, Not Intensity Measure whether you showed up, not how much you accomplished. Consistency is the foundation. Engineer: Mark each day you learned something. CEO: Mark each week you had the hard conversation.
Create Accountability Discipline is harder alone. Build structures that hold you accountable. Engineer: Commit to a peer. CEO: Have a coach or board.
Forgive and Resume Discipline is not perfection. When you miss a day, resume immediately. One missed brick does not destroy the wall. Engineer: Missed a day of learning? Do it tomorrow. CEO: Avoided a conversation? Have it today.

9. The Relationship Between Discipline and Other Laws

The Law of the Wall connects to and enables many of Bartlett's other laws:

Law Relationship to Discipline
Law of Compounding Discipline is the engine of compounding. Small, consistent actions (bricks) produce massive results over time (the wall).
Law of the Reservoir Discipline builds reservoirs. You cannot build a financial, energy, or knowledge reservoir without consistent deposits.
Law of the Uncomfortable Discipline is what enables you to stay in discomfort. Motivation would flee; discipline persists.
Law of the Teacher Teaching requires discipline—consistent preparation, clarity, and presence even when you do not feel like teaching.
Law of the Cathedral Cathedrals are built through centuries of discipline. The workers who laid the first bricks never saw the finished building. Discipline sustained them.

10. Why the Law of the Wall Matters in the Book's Structure

The Law of the Wall sits in Part 1: The Self, the foundational section on internal mastery. Its placement is significant:

· Part 1 is about building the internal structure that supports all external success.
· The Law of the Wall is the keystone of Part 1. Without discipline, none of the other internal laws can be sustained.
· Discipline is what enables:
  · Building reservoirs consistently
  · Tolerating discomfort for growth
  · Compounding small actions
  · Processing wounds into strengths

Bartlett's deeper argument: Discipline is not a restriction. It is liberation. The disciplined person is not trapped by their habits; they are freed by them. Because discipline handles the mundane, they have energy for the extraordinary. Because discipline builds the wall, they have something to stand on when the storm comes.

11. Summary: The Law of the Wall

Element Summary
Definition Discipline is the ability to do what is necessary even when motivation is absent.
Core Principle Motivation is fleeting. Discipline is structural. Motivation starts; discipline finishes.
The Wall Metaphor Each act of discipline is a brick. Consistently laid, bricks build a wall of capability, resilience, and results.
Motivation vs. Discipline Motivation is unreliable, external, short-term. Discipline is reliable, internal, long-term.
Three Levels Task discipline, system discipline, identity discipline.
Engineer Applications Code quality, learning, reviews, communication, career consistency.
CEO Applications Strategic focus, cultural standards, financial management, personal routines.
Building Discipline Start small, separate decision from action, design environment, build identity, track consistency, create accountability, forgive and resume.
Book Context Part 1 (The Self)—discipline is the foundation that enables all other internal mastery.

Quick Reference: Discipline Checklist

For Engineers For CEOs
Do I write tests consistently, even when rushed? Do I say no to opportunities that do not fit the mission?
Do I learn something new regularly, not just when required? Do I hold everyone to the same cultural standards?
Do I give thorough code reviews every time? Do I maintain financial reserves even in good times?
Do I document decisions consistently? Do I protect my own routines and energy?
Do I maintain quality even when motivation is low? Do I make hard decisions even when I do not want to?

If you would like, I can:

· Help you design a discipline system tailored to your engineering or leadership context
· Show how to build discipline across a team or organization, not just individually
· Provide examples of how to recover from a discipline breakdown (missed days, lost habits)
· Connect the Law of the Wall to specific engineering practices like test-driven development, continuous integration, or infrastructure as code

Let me know how you would like to proceed.

Survival


From Survival to Strength: A Relentless Journey

Since childhood, life was never easy for me. I was not the kind of student people admired—my academic results were far from outstanding. Even in matriculation, I had to repeat. University was no different; I struggled, failed twice, and came dangerously close to being expelled.

But I held on.

By the grace of God, I finally graduated—though it required an extra semester, and my final CGPA stood at 2.18. To many, that number might seem small. To me, it was a symbol of resilience.

I knew one thing clearly:
If I wasn’t naturally gifted, I had to outwork everyone else.

So I did.


The Decision to Work Harder Than Everyone Else

Right after graduation, I didn’t wait. I stepped straight into the workforce—starting in a steel factory, then moving through several industries. I was fully aware of my limitations. My results were average, but my determination had to be extraordinary.

I pushed harder.

  • Harder in finding opportunities

  • Harder in learning

  • Harder in proving myself at work

Eventually, I entered the palm oil industry—a path that would demand everything from me.

And I gave it everything.


The Sacrifices No One Sees

While others sought salary increments, I chose a different path.

I invested in myself.

Every extra ringgit I had went into learning:

  • Steam Engineer certification

  • Internal Combustion Engine certification

  • DIPOM

  • MBA

  • Communication training through Toastmasters

  • And countless other competencies

I sacrificed time.
I sacrificed comfort.
I sacrificed many things people take for granted.

I told myself:

“It’s not my time to demand yet. It’s my time to build.”


The Breakthrough

In less than three years, something unexpected happened.

I was entrusted to become a Plant Manager.

Not because I was the smartest.
But because I was prepared.

From 2006 until today—2026—I have been managing large organizations. Leading people. Making decisions. Carrying responsibilities many never see.


A 20-Year Promise Fulfilled

One goal remained unfinished for a long time: becoming a Professional Engineer.

It stayed in my bucket list for years—delayed, postponed, set aside.

But this year, after 20 years, I finally achieved it.


Am I Successful Now?

Am I wealthy?
Am I living a life of luxury?

No.

I am still in survival mode.
Still fighting. Still pushing forward.

But when I look back…

I smile.

Because I made it through everything that once felt impossible.


And the Journey Continues

This is not a story about instant success.
This is a story about endurance.

About showing up when it’s hard.
About choosing growth over comfort.
About believing in yourself—when there is no evidence yet.

I am still climbing.

And I will keep climbing.

Perjuangan


“Dari Hampir Gagal ke Terus Berjuang”

Catatan seorang insan yang tidak pernah berhenti belajar

Sejak kecil, hidup saya bukanlah kisah seorang pelajar cemerlang. Saya bukan yang dipuji guru, bukan juga yang dibanggakan dengan keputusan peperiksaan. Saya hanyalah seorang pelajar biasa… atau mungkin di bawah sedikit daripada biasa.

Perjalanan itu bermula dengan jatuh.

Di matrikulasi, saya mengulang. Di universiti, saya diuji lagi — bukan sekali, tetapi dua kali percubaan, hampir-hampir disingkirkan dari dunia yang saya cuba bina. Ketika orang lain melangkah ke hadapan dengan yakin, saya masih bertatih, mencari arah.

Akhirnya saya tamat juga pengajian.
Dengan pointer 2.18.

Bukan sesuatu yang dibanggakan.
Tetapi bagi saya — itu adalah kemenangan pertama.


Realiti Dunia Sebenar

Keluar dari universiti, dunia tidak menjadi lebih mudah. Dengan keputusan yang “cukup makan”, saya tahu satu perkara:

Saya tidak boleh bergantung pada kelayakan. Saya perlu bergantung pada usaha.

Saya mula bekerja — dari kilang besi ke pelbagai kilang lain. Saya bukan memilih kerja. Saya mengejar peluang.

Dan di situlah saya belajar satu prinsip penting:
Jika kita kurang pada satu tempat, kita mesti lebih pada tempat lain.


Harga Sebuah Perubahan

Apabila saya memasuki industri sawit, hidup saya berubah sepenuhnya.

Saya mula berkorban.

  • Korban masa

  • Korban keselesaan

  • Korban kehidupan sosial

  • Korban banyak perkara yang orang lain anggap normal

Setiap hujung bulan, duit lebihan bukan untuk keseronokan.
Ia dilaburkan kembali kepada diri sendiri.

Saya belajar tanpa henti:

  • Sijil Jurutera Stim

  • Jurutera Enjin Pembakaran Dalam

  • DIPOM

  • MBA

  • Komunikasi melalui Toastmasters

  • Dan pelbagai lagi kompetensi

Ketika rakan-rakan sibuk meminta kenaikan gaji, saya memilih jalan yang berbeza.

Saya berkata pada diri sendiri:
“Belum masanya untuk saya demand. Masanya sekarang adalah untuk membina.”


Rezeki Tidak Pernah Salah Alamat

Belum pun tiga tahun bekerja…

Saya diberi amanah menjadi pengurus kilang.

Bukan kerana saya paling pandai.
Tetapi mungkin kerana saya paling bersedia untuk belajar.

Dari tahun 2006 hingga 2026 — 20 tahun perjalanan — saya terus memimpin, mengurus, belajar, jatuh dan bangkit semula.


Impian Yang Tertangguh

Dalam banyak senarai impian hidup saya, ada satu yang sering tertangguh:

Professional Engineer (PE)

Bukan sekali saya cuba, tetapi berkali-kali saya tangguhkan.
Kesibukan kerja. Tanggungjawab. Kehidupan.

Namun, awal tahun ini… selepas 20 tahun, akhirnya saya berjaya mencapainya.

Bukan kerana ia mudah.
Tetapi kerana saya tidak pernah benar-benar berhenti.


Adakah Ini Penghujung?

Adakah saya kini sudah senang?
Sudah kaya?
Sudah terbilang?

Jawapannya: Tidak.

Saya masih dalam mode survival.
Masih berjuang.
Masih belajar.

Tetapi apabila saya menoleh ke belakang…

Saya tersenyum.

Kerana saya tahu,
saya bukan lagi orang yang sama seperti dahulu.


Penutup: Sebuah Perjalanan, Bukan Destinasi

Hidup ini bukan tentang siapa paling cepat sampai.
Tetapi siapa yang tidak berhenti berjalan.

Saya mungkin bermula dengan lemah.
Saya mungkin jatuh lebih banyak dari orang lain.

Tetapi satu perkara yang saya tidak pernah buat —
Saya tidak pernah berhenti.

Dan saya akan terus berjuang.

The Law of the Uncomfortable

Here is a detailed explanation of The Law of the Uncomfortable, framed from the dual perspectives of an engineer and a CEO. This law is one of the most challenging yet essential principles in Steven Bartlett's The Diary of a CEO, as it directly confronts our natural aversion to difficulty.

The Law of the Uncomfortable: "If you are not uncomfortable, you are not growing."

1. Definition: What Is the Law of the Uncomfortable?

The Law of the Uncomfortable (Law 6 in the 33-law framework) states that growth and comfort cannot coexist. Every meaningful expansion of capability—whether technical, strategic, or personal—requires venturing into territory where you feel awkward, uncertain, and exposed.

Core Principle: Comfort is not a sign of success; it is a sign of stagnation. When you feel completely at ease, you are operating within your existing capabilities, not expanding them. Discomfort is not a signal that something is wrong; it is a signal that you are growing.

Bartlett argues that we have been conditioned to avoid discomfort. Our lizard brain (the amygdala) interprets unfamiliar situations as threats. But the path to mastery—whether mastering a programming language, leading a company, or building a public brand—runs directly through discomfort.

The insight: The discomfort you feel when facing a new challenge is not a reason to stop. It is evidence that you are exactly where you need to be.

2. The Psychology of Discomfort

Bartlett grounds this law in the neurobiology of learning and adaptation:

Concept Explanation

The Comfort Zone 

Where you operate with competence and ease. No learning occurs here.

The Learning Zone 

(Stretch Zone) Where tasks are challenging but achievable. Discomfort is present. Neuroplasticity is activated. Growth occurs here.

The Panic Zone 

Where challenges exceed current capability. Overwhelm and shutdown occur. Growth is not possible here.

The goal: Stay in the Learning Zone. Push into discomfort, but not so far that you tip into panic. The boundary between comfort and discomfort is where growth happens.


The Neurochemistry of Discomfort:

· When you encounter unfamiliar challenges, your brain releases cortisol and norepinephrine—stress chemicals.

· These chemicals heighten attention and create the conditions for new neural connections.

· If you persist, the brain rewires. What was once uncomfortable becomes familiar. The discomfort threshold moves.

Bartlett's observation: Most people interpret the stress of discomfort as a sign that they are "not ready" or "not cut out for this." In reality, it is a sign that the brain is doing exactly what it needs to do to adapt.

3. The Comfort Trap

Bartlett describes the Comfort Trap as one of the greatest dangers to long-term success:

Stage Description

1. Initial Growth You work hard, struggle, and expand your capabilities. Discomfort is constant.

2. Competence Achieved You master the skills. Tasks become easy. Discomfort fades.

3. Comfort Settles In You continue doing what you know. There is no challenge. You mistake comfort for success.

4. Stagnation While you rest in comfort, the world moves. Your skills become outdated. Competitors pass you.

5. Crisis External change forces you out of comfort. But now you are behind, and the discomfort is panic, not stretch.

The tragedy: People often work incredibly hard to achieve a level of comfort—and then stay there, mistaking it for arrival. But in a world of constant change, comfort is not a destination. It is a warning sign.

4. The Law of the Uncomfortable: Engineer's Perspective

For an engineer, discomfort is the gateway to technical growth, career advancement, and lasting relevance in a field that evolves relentlessly.

A. Technical Discomfort: Learning New Technologies

Comfort Behavior Uncomfortable Growth Behavior

Staying with the programming language you know Learning a new language with different paradigms (e.g., going from Python to Rust, or from imperative to functional programming)

Using familiar frameworks Building something from scratch to understand fundamentals

Copy-pasting solutions Debugging unfamiliar errors yourself

Avoiding mathematics or systems design Studying distributed systems, algorithms, or low-level architecture

Why It's Uncomfortable:

· You feel slow and incompetent again. Tasks that took minutes now take hours.

· You make beginner mistakes. Your code is ugly. You feel exposed.

· Your ego takes a hit. Colleagues who stayed in their comfort zone seem more productive.

The Growth:

· You build transferable knowledge—understanding concepts, not just syntax.

· You develop learning agility—the meta-skill of picking up new technologies quickly.

· You future-proof your career. When the industry shifts, you shift with it.

Example:

An engineer spent 10 years as a PHP expert. He was comfortable. He was the "go-to" person. But he noticed job postings shifting toward Node.js, Python, and cloud architectures. He decided to learn Node.js. For three months, he felt like a junior again. His pride hurt. His productivity dropped. But he persisted. A year later, his company needed to build a real-time service. He was the only senior engineer who could lead it. His discomfort had opened a door that would have been closed if he had stayed comfortable.

B. Career Discomfort: Taking on New Responsibilities

Comfort Behavior Uncomfortable Growth Behavior

Staying as an individual contributor Moving into tech lead, architect, or management roles

Avoiding public speaking Presenting at team meetings, conferences, or technical reviews

Staying in the same company Leaving for a role that stretches your capabilities

Avoiding ambiguity Taking ownership of ill-defined problems

Why It's Uncomfortable:

· You are no longer judged solely on code quality. You are judged on communication, leadership, and outcomes.

· You make decisions with incomplete information. You are accountable for things you do not fully control.

· You face criticism, disagreement, and the weight of other people's careers.

The Growth:

· You develop leverage—your impact scales through others, not just your own output.

· You build influence—the ability to align teams, secure resources, and drive direction.

· You become indispensable in ways that pure technical skill cannot achieve.

Example:

A senior engineer was deeply respected for her technical skills. She was comfortable. When asked to lead a critical project with three junior engineers, she hesitated. Leading meant less time coding. It meant unblocking others, managing stakeholders, and being accountable for outcomes she could not control. She took the role anyway. The first three months were brutal. She made mistakes. She felt incompetent. But she persisted. Two years later, she was a director of engineering, leading 40 people. Her technical skills were still there, but now she had multiplied her impact.

C. Relational Discomfort: Giving and Receiving Feedback

Comfort Behavior Uncomfortable Growth Behavior

Avoiding difficult conversations Giving direct, constructive feedback to peers or managers

Being defensive in code reviews Asking for feedback proactively and receiving it without defensiveness

Staying silent in meetings Speaking up, challenging assumptions, advocating for quality

Why It's Uncomfortable:

· Conflict is uncomfortable. You risk damaging relationships or being disliked.

· Receiving feedback triggers defensiveness. Your ego wants to explain why the feedback is wrong.

· Speaking up risks being wrong publicly, or being perceived as difficult.

The Growth:

· You build trust—people know you are honest and can handle honesty in return.

· You accelerate learning—feedback is the fastest way to see your blind spots.

· You develop influence—your voice carries weight because you use it thoughtfully.

Example:

An engineer consistently avoided code review conflicts. If someone suggested a change, he accepted it, even when he disagreed. He was comfortable. But his code quality suffered from design-by-committee. His growth stalled. He decided to change. He started explaining his reasoning calmly, asking clarifying questions, and standing firm when he believed his approach was correct. It was uncomfortable. Some conversations were tense. But his designs improved. His team respected him more, not less. He had learned that discomfort was not conflict—it was clarity.

D. Identity Discomfort: Redefining Yourself

Comfort Behavior Uncomfortable Growth Behavior

Identifying as "just an engineer" Expanding identity to include leader, mentor, communicator, or founder

Hiding behind technical complexity Making technical concepts accessible to non-technical stakeholders

Avoiding business context Understanding users, markets, and business strategy

Why It's Uncomfortable:

· You are no longer the expert in the room. You are learning from product managers, salespeople, and customers.

· You risk being seen as "not technical anymore" if you focus on leadership or business.

· Your sense of identity—"I am the person who solves hard technical problems"—is challenged.

The Growth:

· You become T-shaped—deep in engineering, broad in adjacent domains.

· You become strategic—able to align technical decisions with business outcomes.

· You become unstuck—your career is no longer limited by technical ceilings.

Example:

An engineer was known as the best backend developer in the company. His identity was tied to being the "deep technical expert." When he was asked to lead a cross-functional initiative involving product, design, and marketing, he resisted. That was not "his job." But he took it. He had to learn to speak the language of product managers. He had to understand user research. He had to present to executives. It was deeply uncomfortable. But after that project, he was no longer just a backend engineer. He was a technical leader who could bridge engineering and business. His career trajectory changed completely.

5. The Law of the Uncomfortable: CEO's Perspective

For a CEO, discomfort is not occasional; it is the permanent condition of leadership. The higher you rise, the more frequently you encounter situations with no clear path, no precedent, and no guarantee.

A. Strategic Discomfort: Making Decisions Without Certainty

Comfort Behavior Uncomfortable Growth Behavior

Waiting for perfect data Making decisions with incomplete information

Avoiding difficult trade-offs Choosing between two good options or two bad ones

Delegating hard decisions Owning the decisions that cannot be delegated

Why It's Uncomfortable:

· You cannot outsource uncertainty. The weight of decisions rests on you.

· You will be wrong sometimes. Publicly. With consequences for employees, customers, and investors.

· There is no playbook for the situation you are in. You are creating the path as you walk it.

The Growth:

· You develop judgment—the ability to make high-quality decisions with imperfect information.

· You build decisiveness—speed of decision-making becomes a competitive advantage.

· You earn trust—people follow leaders who make hard calls with clarity and accountability.

Example:

A CEO faced a decision: pivot the company to a new market or double down on the existing product. The data was ambiguous. The board was divided. The team was anxious. Staying comfortable meant delaying the decision, gathering more data, running more analyses. But delay was itself a decision—and a costly one. She made the call. She chose to pivot. It was uncomfortable. She lost some employees who disagreed. The first six months were chaotic. But the pivot ultimately saved the company. She learned that discomfort was not a sign to stop; it was a sign that she was doing the job of a CEO.

B. People Discomfort: Having Hard Conversations

Comfort Behavior Uncomfortable Growth Behavior

Avoiding performance conversations Giving direct feedback to underperforming leaders

Keeping misaligned team members Letting people go when they are not the right fit

Avoiding conflict Addressing misalignment, politics, or toxicity directly

Why It's Uncomfortable:

· You are affecting people's livelihoods and identities. The weight is heavy.

· You risk being disliked. You risk being wrong.

· Your own discomfort with conflict can lead to avoidance, which damages the entire organization.

The Growth:

· You build a healthy culture—clarity, accountability, and trust.

· You create psychological safety—when leaders model difficult conversations, others learn to do the same.

· You earn respect—people may not always like hard decisions, but they respect leaders who make them with integrity.

Example:

A CEO had a co-founder who was brilliant but toxic. The co-founder belittled engineers, dismissed feedback, and created a culture of fear. The CEO avoided the conversation for months, hoping it would resolve. The discomfort of conflict felt worse than the slow erosion of culture. But eventually, he realized the cost of avoidance: top engineers were leaving. He had the conversation. It was brutal. The co-founder left. The CEO lost a co-founder and a friend. But the company culture healed. He learned that avoiding discomfort was not protecting the relationship; it was destroying the company.

C. Scaling Discomfort: Letting Go of Control

Comfort Behavior Uncomfortable Growth Behavior

Making all decisions Delegating authority, accepting decisions you would not have made

Staying in the details Stepping back to strategy, trusting others to execute

Hiring people who think like you Hiring people who challenge you, who are better than you in their domains

Why It's Uncomfortable:

· You lose control. Decisions are made that you would not have made. Mistakes happen.

· Your identity shifts from "the person who knows everything" to "the person who enables others."

· You feel irrelevant. The company can operate without you—which is the goal.

The Growth:

· You build scalability—the organization can grow beyond your personal capacity.

· You develop leaders—people who can take on responsibility and grow.

· You become a true CEO—focusing on vision, culture, and strategy, not operations.

Example:

A founder-CEO was involved in every decision: every hire, every feature, every marketing campaign. The company grew to 50 people, and he was the bottleneck. He knew he needed to let go, but it was uncomfortable. He hired a COO. He delegated engineering to a VP. He stopped attending every product meeting. For months, he felt anxious. Decisions were made that he would not have made. Some were wrong. But the company grew to 200 people. He learned that his discomfort was the price of scale. If he had stayed comfortable, the company would have stayed small.

D. Visibility Discomfort: Public Leadership

Comfort Behavior Uncomfortable Growth Behavior

Staying behind the scenes Becoming the public face of the company

Communicating through polished statements Speaking authentically, vulnerably, and directly

Avoiding controversy Taking stands on issues that matter to your mission and values

Why It's Uncomfortable:

· Public visibility invites scrutiny, criticism, and personal attacks.

· Authenticity risks saying the wrong thing, alienating stakeholders, or creating controversy.

· Vulnerability—admitting mistakes, uncertainty, or struggles—feels like weakness.

The Growth:

· You build trust—with employees, customers, and the public. People trust leaders who are real.

· You create alignment—your communication reinforces the mission and culture.

· You become a magnet—talent and partners are drawn to leaders with clarity and courage.

Example:

A CEO had always avoided public speaking. She let her product lead talk to customers, her marketing lead talk to the press. She was comfortable behind the scenes. But the company was struggling with retention. Employees wanted to hear from her. Customers wanted to know the company had a leader. She started recording a weekly video update—unscripted, raw, honest. The first video was terrifying. She stumbled. She revealed uncertainty. But employees responded. They felt connected. Customers trusted her. She learned that discomfort in visibility was not exposure—it was connection.

6. The Growth Formula: Comfort + Risk = Stagnation

Bartlett offers a simple formula:

Formula Implication

Comfort + No Risk = Stagnation Staying where you are, doing what you know, avoiding discomfort. Growth stops.

Discomfort + Calculated Risk = Growth Stepping into uncertainty, stretching capabilities, embracing the awkwardness of learning.

Panic + Reckless Risk = Burnout Taking on challenges far beyond current capability without support.

The sweet spot: Discomfort with calculated risk. You should feel awkward, uncertain, and stretched—but not overwhelmed, unsupported, or hopeless.

7. How to Embrace Discomfort: A Framework

Step Engineer Application CEO Application

1. Identify Your Comfort Zone What technologies, tasks, or roles feel easy? What have you been avoiding? What decisions do you delegate? What conversations are you postponing? Where do you feel in control?

2. Define the Stretch Choose a specific skill, project, or responsibility that sits just outside current capability. Choose a decision, conversation, or strategic shift that you have been avoiding.

3. Accept the Inevitable Discomfort Acknowledge that you will feel slow, foolish, and uncertain. This is not failure; it is the feeling of learning. Acknowledge that you will feel exposed, anxious, and uncertain. This is not weakness; it is the feeling of leading.

4. Create Support Structures Pair with someone more experienced. Set up a learning project with safe failure modes. Find a peer CEO or coach. Create board alignment. Ensure you have support before stepping into exposure.

5. Reflect on Progress After each uncomfortable step, ask: What did I learn? What is easier now than three months ago? After each hard decision, ask: What did I learn about myself? What can I do now that I could not before?

6. Expand the Threshold As what was uncomfortable becomes comfortable, find the next edge. Growth is never finished. As you grow into new capabilities, the organization grows. Your discomfort threshold is the company's growth ceiling.

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

The Law of the Uncomfortable sits in Part 1: The Self, the foundational section on internal mastery. Its placement is critical:

· Part 1 is about building yourself before building your company or brand.

· The Law of the Uncomfortable teaches that self-mastery is not about reaching a state of permanent comfort. It is about developing the capacity to tolerate discomfort.

· This law enables all others. Without the ability to tolerate discomfort, you cannot:

  · Build reservoirs (requires discipline now for future security)

  · Fail intelligently (requires tolerating the discomfort of failure)

  · Learn by teaching (requires vulnerability)

  · Lead authentically (requires exposure)

Bartlett's deeper argument: Your capacity for discomfort is the ceiling of your growth. If you cannot tolerate the discomfort of learning, you will stop learning. If you cannot tolerate the discomfort of leadership, you will stop leading. If you cannot tolerate the discomfort of vulnerability, you will stop connecting.

9. Summary: The Law of the Uncomfortable

Element Summary

Definition Growth and comfort cannot coexist. Discomfort is not a sign of failure; it is a sign of expansion.

Core Principle If you are not uncomfortable, you are not growing.

Zones Comfort Zone (no growth) → Learning Zone (discomfort, growth) → Panic Zone (overwhelm, no growth)

Comfort Trap Achieving comfort, mistaking it for success, and stagnating while the world moves.

Engineer Applications Learning new technologies, taking leadership roles, giving/receiving feedback, expanding identity.

CEO Applications Making decisions with uncertainty, having hard conversations, letting go of control, embracing public visibility.

Growth Formula Discomfort + Calculated Risk = Growth. Comfort + No Risk = Stagnation.

Book Context Part 1 (The Self)—internal mastery means developing capacity to tolerate discomfort.

Quick Reference: Uncomfortable Growth Checklist


For Engineers For CEOs

What technology have you been avoiding learning? What decision have you been postponing?

What role or responsibility feels beyond you? What conversation have you been avoiding?

When did you last ask for feedback? Where are you still holding control you should delegate?

When did you last speak up with a dissenting view? When did you last communicate vulnerably?

What would you do if you were guaranteed not to fail? What would you decide if you were guaranteed to be supported?



Advertisment & Promotion ; Wise ZM Solutions


🔷 WISE ZM SOLUTION

Moving Beyond Imagination


📌 Empowering Growth. Driving Excellence.

We provide professional training, consulting, and coaching tailored for engineers, organizations, and individuals seeking continuous improvement.


🛠️ OUR SERVICES

🔥 Technical Training

  • Boiler Operations & Efficiency

  • Palm Oil Mill Process Optimization

  • Energy Management Systems

📊 Audit & Consultancy

  • Boiler & Plant Operation Audit

  • Cost Saving & Performance Improvement

  • Energy Efficiency Solutions

🎓 Professional Development

  • Professional Engineer (PE) Coaching

  • Leadership & Communication Skills

  • Management Training

👨‍👩‍👧 Personal Growth

  • Parenting Consultancy

  • Motivation & Life-Long Learning

  • Engineering & Psychology Education


💡 WHY CHOOSE US?

✔ Industry Experience
✔ Practical & Result-Oriented Approach
✔ Customized Solutions
✔ Proven Impact


📞 CONTACT US TODAY

📧 Email: wisezms@gmail.com
📱 WhatsApp: +6011 2618 9662


"Transform Knowledge Into Action. Elevate Your Potential."


🎨 Design by Kembara Insan


Thursday, 26 March 2026

The Law of the Reservoir

Here is a detailed explanation of The Law of the Reservoir, framed specifically from the perspective of an engineer. This law is one of the most practical and forward-looking principles in Steven Bartlett's The Diary of a CEO, emphasizing preparation over reaction.

The Law of the Reservoir: "Build reserves before you need them. Crisis reveals poor preparation."

1. Definition: What Is the Law of the Reservoir?

The Law of the Reservoir (Law 7 in the 33-law framework) states that success, resilience, and the ability to seize opportunities are all functions of the reserves you build during times of abundance.

Core Principle: Most people and organizations operate in a state of scarcity—using every resource as soon as it becomes available, leaving no buffer for unexpected challenges or opportunities. When crisis hits, they have nothing to draw upon. The wise, by contrast, build reservoirs: stores of energy, time, money, knowledge, relationships, and goodwill that they can tap into when needed.

Bartlett draws the metaphor from ancient civilizations that built reservoirs to store water during rainy seasons so they could survive droughts. The same principle applies to every dimension of professional and personal life.

The insight: The time to build a reservoir is not when you are thirsty. It is when water is plentiful.

2. The Psychology of Scarcity vs. Abundance

Bartlett grounds the Law of the Reservoir in the psychology of how scarcity affects decision-making:

Mindset Behavior Outcome
Scarcity Mindset Uses resources immediately. Lives paycheck to paycheck—financially, emotionally, and temporally. No buffer. Every crisis becomes catastrophic. Opportunities are missed because there are no reserves to invest. Stress is constant.
Abundance Mindset Sets aside reserves deliberately. Lives below capacity to create buffer. Crises are manageable. Opportunities can be seized. Decision-making is calm because there is room to maneuver.

Bartlett argues that scarcity is not just a financial condition; it is a cognitive state. When you have no reserves, you operate in survival mode. You make short-term decisions. You cannot think strategically. Building reservoirs is what frees you to think long-term.

3. The Types of Reservoirs

Bartlett identifies multiple reservoirs that must be built. For an engineer, each has specific relevance:

Reservoir Description Why It Matters
Financial Reservoir 
Savings, runway, emergency funds. Allows you to take career risks, survive layoffs, invest in learning, and say no to bad opportunities.
Energy Reservoir 
Physical and mental capacity, sleep, fitness, recovery. Engineering requires deep focus. Burnout destroys productivity. Energy reserves allow sustained performance.
Time Reservoir 
Slack in schedules, buffer in estimates, margin in calendars. When everything is scheduled to the minute, any unexpected task creates crisis. Time reserves allow for emergencies and strategic work.
Knowledge Reservoir 
Deep expertise, broad understanding, learned skills. When a new problem arises, you draw on knowledge built in advance. You cannot learn cryptography the night before you need it.
Relationship Reservoir 
Trust, goodwill, network, mentorship connections. When you need help, advice, or a job, you draw on relationships built before you needed them.
Code/System Reservoir 
Clean architecture, documentation, tests, monitoring, technical debt paid down. When a production issue arises, you draw on the quality built into the system. Fragile systems fail under pressure.
Attention Reservoir 
Focus, deep work capacity, reduced context switching. In a crisis, you need clarity. Attention reserves allow you to think clearly when others panic.

4. The Reservoir in Engineering: Detailed Applications

Let us explore each reservoir through the lens of an engineer's daily work and career.

A. The Financial Reservoir

For an engineer, financial reserves are not just about personal savings—though that matters profoundly. They are about creating career optionality.

Scenario Without Financial Reservoir With Financial Reservoir
You want to leave a toxic job You feel trapped. You cannot afford to quit without another offer lined up. You stay, burn out, and accept poor treatment. You have 6–12 months of runway. You can quit, take time to recover, and find the right role, not just any role.
A startup opportunity arises You cannot take the risk. You need a steady paycheck. You pass on what could have been a life-changing equity opportunity. You can afford to take a calculated risk. You join the startup, accepting lower salary for potential upside.
You want to invest in learning You cannot afford a course, conference, or certification. Your skills stagnate. You invest in high-quality training, books, and conferences. Your skills compound.

Bartlett's advice: Build a financial reservoir that gives you the power to say no. The ability to walk away is the foundation of all other freedoms.

B. The Energy Reservoir

Engineering is cognitively demanding. It requires sustained focus, complex problem-solving, and the ability to hold multiple variables in working memory. Energy reserves are not optional; they are professional infrastructure.

Practice Depletes Reservoir Builds Reservoir
Sleep Sacrificing sleep to meet deadlines. Consistent 7–9 hours. Sleep as non-negotiable.
Recovery Working through weekends. Always being on call. Deliberate rest. Clear boundaries. Sustainable pace.
Fitness Sedentary lifestyle. No movement. Regular exercise. Physical energy supports mental energy.
Nutrition Caffeine and sugar as fuel. Skipping meals. Stable nutrition. Hydration. Avoiding energy crashes.
Focus Constant context switching. Open office chaos. Deep work blocks. Notification management. Protected focus time.

Bartlett's insight: Your code is only as good as the brain that writes it. Treating your energy reservoir as a professional asset is not weakness; it is optimization.

Example:

An engineer I know was known for working 80-hour weeks during crunch times. He was praised for his dedication. But his code quality declined. He made mistakes that caused outages. He burned out and took three months off. When he returned, he set boundaries: no work after 6 PM, no weekend work except true emergencies. His productivity actually increased. His code was cleaner. His decisions were sharper. He realized that his "dedication" had been self-destructive. He now teaches junior engineers that energy reserves are not selfish—they are professional discipline.

C. The Time Reservoir

In engineering, time reserves manifest as slack—buffer in schedules, margin in estimates, space in calendars.

Practice Depletes Time Reservoir Builds Time Reservoir
Estimating Padding-less estimates. Promising delivery dates without buffer. Adding 20–50% buffer for unknowns. Distinguishing between optimistic and realistic estimates.
Scheduling Back-to-back meetings. No gaps between commitments. Deliberate white space in calendar. Time for thinking, not just reacting.
Task Management Always at 100% capacity. No room for unexpected work. Operating at 70–80% capacity. Room for emergencies, learning, and strategic work.
Technical Debt Taking shortcuts to meet deadlines. "We'll fix it later." Allocating time for refactoring, documentation, and debt reduction.

Bartlett's principle: If you are always at 100% capacity, you have no room for the unexpected. And the unexpected always comes.

Example:

A engineering manager noticed that his team consistently missed deadlines. He assumed they were underestimating. But when he looked at their calendars, he saw they were booked solid with meetings, leaving no time for actual coding. Worse, any urgent bug or request would push everything back. He instituted "focus blocks"—four-hour uninterrupted coding windows, three times a week. He also added 30% buffer to all estimates. Suddenly, deadlines were met. Morale improved. The team had time to refactor, to document, to learn. They had built a time reservoir.

D. The Knowledge Reservoir

Engineering knowledge compounds. The skills you build today become the tools you use tomorrow. The knowledge reservoir is built through deliberate learning before it is needed.

Practice Depletes Knowledge Reservoir Builds Knowledge Reservoir
Learning Only learning what is immediately needed for the current task. Regular investment in learning—books, courses, side projects, conferences.
Depth Surface-level understanding. Copy-pasting from Stack Overflow. Deep understanding of fundamentals. Knowing why something works.
Breadth Siloed expertise. Only knows one language, one domain. Broad exposure. Understanding adjacent systems, business context, user needs.
Documentation Knowledge lives only in heads. No written record. Documenting decisions, patterns, lessons. Building a shared knowledge base.

Bartlett's observation: The best engineers are not the ones who know everything. They are the ones who have built a knowledge reservoir so that when a new problem appears, they have adjacent knowledge to draw upon. They can learn quickly because they have a foundation.

Example:

An engineer spent 20% of her time for two years learning about distributed systems—reading papers, building small prototypes, attending meetups. Her current job was in web development; none of this was directly applicable. Then her company decided to migrate to microservices. Suddenly, she was the only engineer on the team who understood eventual consistency, consensus algorithms, and failure modes of distributed systems. She became the technical lead for the migration. Her knowledge reservoir, built when it was not needed, became indispensable when it was.

E. The Relationship Reservoir

Engineering is often seen as a solitary discipline, but in reality, it is deeply collaborative. The relationships you build before you need help become the network you draw upon when you are stuck, when you need a job, or when you need advice.

Practice Depletes Relationship Reservoir Builds Relationship Reservoir
Mentorship Never asking for help. Trying to solve everything alone. Building relationships with senior engineers. Asking thoughtful questions.
Collaboration Working in isolation. Avoiding pair programming. Pairing regularly. Helping others. Being generous with knowledge.
Networking Only reaching out when you need something. Building genuine relationships. Offering help before asking for it.
Reputation Taking credit. Blaming others. Hoarding knowledge. Giving credit generously. Taking responsibility for failures. Sharing knowledge freely.

Bartlett's insight: Your network is not a list of contacts. It is a reservoir of trust. When you need a job, a reference, or help debugging a critical issue at 2 AM, you draw on that reservoir. If you have not deposited into it, you cannot withdraw.

Example:

An engineer was laid off during a company restructuring. His technical skills were solid, but not exceptional. However, over the years, he had built deep relationships. He had mentored juniors. He had helped colleagues debug impossible problems. He had written thoughtful post-mortems that helped the whole team. When he was laid off, seven former colleagues reached out within 48 hours with job leads. One hired him without a formal interview. His technical skills were not unique. But his relationship reservoir was so deep that he never experienced unemployment.

F. The Code/System Reservoir

This is the reservoir most familiar to engineers: the quality and resilience of the systems you build. A well-maintained codebase is a reservoir of reliability. A fragile codebase is a constant source of crisis.

Practice Depletes System Reservoir Builds System Reservoir
Testing No tests. Tests that are flaky or slow. Comprehensive tests. Fast, reliable test suite.
Monitoring No observability. Finding out about failures from users. Metrics, logs, traces. Dashboards. Alerts that signal before users notice.
Documentation No documentation. Outdated, misleading documentation. Clear, maintained documentation. Architecture decision records. Runbooks.
Architecture Spaghetti code. Tight coupling. No separation of concerns. Clean architecture. Loose coupling. Clear boundaries.
Technical Debt Accruing debt to meet deadlines. Never paying it down. Deliberate debt management. Scheduled refactoring. Debt tracked and prioritized.

Bartlett's principle: A system with no reservoir fails under the smallest pressure. A system with a reservoir—tests, monitoring, clean architecture—can absorb shocks, recover quickly, and scale.

Example:

Two teams were building similar features. Team A took shortcuts to ship faster. No tests. Minimal monitoring. Technical debt everywhere. They shipped first. Team B invested in tests, monitoring, and clean architecture. They shipped two weeks later. Six months later, Team A's feature was a constant source of outages. Every change broke something. The team was spending 80% of their time firefighting. Team B's feature ran smoothly. They added new features easily. The team had time for innovation. The "slower" team had actually been building a reservoir. The "faster" team had been creating future crisis.

---

G. The Attention Reservoir

In an age of constant notifications, open offices, and context switching, attention is the scarcest resource. The ability to focus deeply—to hold complex problems in your mind without interruption—is a reservoir that must be protected.

Practice Depletes Attention Reservoir Builds Attention Reservoir
Notifications Email, Slack, phone notifications always on. Scheduled notification checks. Do Not Disturb during focus work.
Context Switching Switching tasks every few minutes. Deep work blocks. Batching similar tasks.
Multitasking Believing multitasking is efficient. Single-tasking. Completing one thing before starting another.
Environment Open office with constant interruptions. Protected focus space. Noise-canceling headphones. Clear focus signals.

Bartlett's insight: Attention is the only non-renewable resource. Money lost can be earned again. Time lost cannot. But attention lost—the ability to think clearly—is the costliest of all.

5. The Compounding Nature of Reservoirs

Bartlett emphasizes that reservoirs do not just protect you; they compound. Each reservoir makes it easier to build the others.

Reservoir Enables
Financial Reservoir Allows you to invest time in learning (knowledge reservoir) and take breaks to protect energy (energy reservoir).
Energy Reservoir Gives you the capacity to build relationships, learn deeply, and maintain code quality.
Time Reservoir Creates space for refactoring (system reservoir), mentoring (relationship reservoir), and learning (knowledge reservoir).
Knowledge Reservoir Makes you faster and more effective, creating more time (time reservoir) and reducing stress (energy reservoir).
Relationship Reservoir Provides support during crises, protecting energy and time.
System Reservoir Reduces firefighting, freeing time and energy.
Attention Reservoir Enables deep work, which accelerates all other reservoirs.

The virtuous cycle: Building one reservoir creates capacity to build others. Neglecting one reservoir creates pressure that drains others.

6. How to Build Your Reservoirs: An Engineer's Action Plan

Reservoir Actionable Steps
Financial Automate savings. Build 6–12 months of runway. Live below your means. Treat financial independence as professional infrastructure.
Energy Prioritize sleep. Set boundaries on work hours. Take breaks. Exercise regularly. Treat recovery as non-negotiable.
Time Add buffer to estimates. Operate at 70–80% capacity. Block focus time. Say no to non-essential work.
Knowledge Schedule regular learning time. Read deeply. Build side projects. Teach others. Document what you learn.
Relationship Help others without expectation. Mentor juniors. Give credit generously. Stay in touch with former colleagues.
System Write tests. Add monitoring. Document decisions. Refactor incrementally. Treat technical debt as a liability to be managed.
Attention Turn off notifications. Batch communication. Create focus blocks. Protect deep work time.

7. Why the Law of the Reservoir Matters in the Book's Structure

The Law of the Reservoir sits in Part 1: The Self, the foundational section on internal mastery. Its placement is critical:

· Part 1 is about building yourself before you build your company, your brand, or your legacy.
· The Law of the Reservoir teaches that you cannot build anything sustainable if you are operating from a place of scarcity. You must first build reserves.
· The reservoir is the foundation that enables all other laws. Without a financial reservoir, you cannot take the risks required by The Law of the Failure. Without an energy reservoir, you cannot sustain The Law of Compounding. Without a relationship reservoir, you cannot leverage The Law of Proximity.

Bartlett's deeper argument: Most people fail not because they lack talent, but because they lack reserves. When pressure comes, they break. The person with reserves does not break. They adapt, they pivot, they seize opportunities that others cannot see because they are too busy surviving.

8. Summary: The Law of the Reservoir (Engineer's Perspective)

Element Summary
Definition Build reserves before you need them. Crisis reveals poor preparation.
Core Principle The time to build a reservoir is when resources are abundant, not when you are thirsty.
Types of Reservoirs Financial, energy, time, knowledge, relationship, system, attention.
Scarcity vs. Abundance Scarcity mindset uses everything immediately. Abundance mindset builds buffer.
Engineering Applications Savings for career optionality, energy for sustained focus, time for strategic work, knowledge for complex problems, relationships for support, clean systems for reliability, attention for deep work.
Compounding Reservoirs reinforce each other. Building one creates capacity to build others.
Book Context Part 1 (The Self)—internal mastery requires building reserves before pursuing external success.

Quick Reference: Engineer's Reservoir Checklist

Reservoir Ask Yourself Action
Financial Do I have 6+ months of runway? Automate savings. Build emergency fund.
Energy Am I sleeping 7–9 hours? Exercising? Set boundaries. Prioritize recovery.
Time Is my calendar 80% full, not 100%? Add buffer. Block focus time. Say no.
Knowledge Am I learning regularly, not just when needed? Schedule learning. Build side projects.
Relationship Have I helped someone recently with no expectation? Mentor. Give credit. Stay connected.
System Does my codebase have tests, monitoring, docs? Pay down technical debt. Add observability.
Attention Do I control notifications, or do they control me? Turn off notifications. Protect deep work.