The Law of Legacy

Here is a detailed explanation of The Law of Legacy, framed specifically from the perspective of an engineer. This law is the culminating principle in Steven Bartlett's The Diary of a CEO, representing the ultimate measure of a life and career well lived.

The Law of Legacy: "Success is measured not by what you accumulated, but by what you leave behind."

1. Definition: What Is the Law of Legacy?

The Law of Legacy (Law 33 in the 33-law framework) states that the true measure of your life and career is not what you built for yourself, but what you built that outlasts you.

Core Principle: 

Legacy is what remains after you are gone. It is the systems you built that continue to function. 

The people you mentored who go on to mentor others. 

The culture you shaped that persists beyond your tenure. 

The problems you solved that never need solving again. 

The knowledge you shared that becomes part of the collective wisdom.

Bartlett places this law at the very end of his 33-law framework because it is the culmination of everything that comes before. 

You build yourself (Part 1: The Self). 

You learn to communicate your value (Part 2: The Story). 

You develop a philosophy for navigating complexity (Part 3: The Philosophy). 

And then, finally, you ask: What will outlast me?

The insight: 

Ego asks, "What can I achieve?" 

Legacy asks, "What can I leave?" 

The first is finite; it ends with you. The second is infinite; it continues through others.

2. The Two Types of Legacy

Bartlett distinguishes between two forms of legacy, both of which apply powerfully to engineering:

Type Description Engineering Example

Tangible Legacy Concrete artifacts that outlast you. Systems, code, documentation, products. The open-source library you built that thousands of projects depend on. The architecture you designed that still runs a decade later.

Intangible Legacy The influence you had on people, culture, and practices. The knowledge you transferred. The engineers you mentored who became leaders. The culture of quality you instilled. The post-mortem discipline you established.

Bartlett argues that both matter, but intangible legacy is ultimately more enduring. Code becomes obsolete. Systems are replaced. But the people you influenced carry your lessons forward, and they influence others, creating a chain that extends far beyond the lifespan of any technical artifact.

3. The Legacy Mindset vs. The Ego Mindset

Bartlett contrasts two orientations that shape how we approach our work:

Dimension Ego Mindset Legacy Mindset

Focus "What will I get?" "What will remain?"

Time Horizon Short-term. Current quarter, current project, current performance review. Long-term. Generations.

Decision Criteria "Does this benefit me?" "Does this benefit those who come after?"

Ownership Hoards knowledge, creates dependency. Shares knowledge, builds independence.

Credit Seeks recognition. Gives credit freely. Cares less who gets credit.

Response to Change Resists changes that diminish personal relevance. Welcomes changes that ensure the system or organization outlasts any individual.

Definition of Success Titles, compensation, status, personal achievements. Impact, influence, things that continue after departure.

Bartlett's observation:

The ego mindset builds monuments to itself. 

The legacy mindset builds cathedrals (Law of the Cathedral). 

Monuments are forgotten. Cathedrals endure.

4. The Law of Legacy: Engineer's Perspective

For an engineer, legacy takes specific forms. The code you write, the systems you design, the people you mentor, and the culture you shape all contribute to what outlasts you.

A. Legacy Through Code and Systems

The most tangible form of engineering legacy is the systems you build that continue to function and serve users long after you have moved on.

Ego-Driven Engineering Legacy-Driven Engineering

Writing clever, complex code that only you can understand Writing clear, simple code that anyone can maintain

Creating dependencies on yourself as the "only one who knows" Documenting thoroughly so others can take over

Optimizing for personal learning and interesting challenges Optimizing for long-term maintainability and reliability

Leaving systems fragile because you will be there to fix them Building systems that are resilient even when you are gone

Hoarding tribal knowledge Codifying knowledge in documentation, runbooks, and architecture decision records

Example:

An engineer built a critical payment processing system. He was brilliant. The code was elegant but complex. He was the only one who fully understood it. When he left the company, the system became a source of constant anxiety. Every change was risky. Outages happened. The team spent months reverse-engineering his brilliance. His ego had built a monument to his genius. His legacy was fragility.

Another engineer built a similar system. She wrote clear documentation. She created runbooks. She explained design decisions in architecture decision records. She paired with junior engineers so they understood the system before she left. When she moved on, the system ran smoothly. The team maintained it easily. Her legacy was not the code—it was the capability she left behind.

B. Legacy Through Documentation and Knowledge

Documentation is often neglected because it does not feel like "real work." But from a legacy perspective, documentation is how your knowledge survives you.

Ego-Driven Documentation Legacy-Driven Documentation

Minimal or no documentation. "The code is the documentation." Comprehensive, clear documentation. Assumes reader knows nothing.

Documentation that is outdated because you never maintained it Documentation that is maintained as part of the development process

Knowledge stored only in your head Knowledge codified in accessible, searchable formats

Complex concepts explained with jargon Complex concepts explained with analogies, examples, and clear language

Example:

An engineer was known as the "expert" on a legacy system. Everyone came to him with questions. He enjoyed being indispensable. When he retired, the system became a black hole. No one understood how it worked. His knowledge retired with him.

Another engineer, knowing she would eventually move on, spent time writing comprehensive documentation. She created a wiki with architecture overviews, common failure modes, and step-by-step runbooks. She recorded video walkthroughs of complex subsystems. When she left, the team barely noticed. Her knowledge had become institutionalized. Her legacy was not her expertise—it was that expertise transferred.

C. Legacy Through Mentorship and People Development

The most enduring form of engineering legacy is not code or systems. It is people. The engineers you mentor carry your lessons forward. Their work, and the work of those they mentor, becomes your legacy multiplied.

Ego-Driven Mentorship Legacy-Driven Mentorship

Hoarding knowledge to maintain status Sharing knowledge freely, knowing it multiplies impact

Criticizing to demonstrate superiority Teaching patiently, remembering what it was like to not know

Creating dependency—juniors always come to you Building independence—juniors learn to solve problems themselves

Taking credit for mentees' successes Giving credit freely; celebrating mentees' growth as the reward

Mentoring only when convenient Investing time in people deliberately, as a core responsibility

Example:

A senior engineer was brilliant but impatient with juniors. He answered questions quickly but did not explain. He fixed problems himself rather than teaching. He was efficient but left no capability behind. When he left, his team was no stronger than when he arrived.

Another senior engineer made mentoring her primary contribution. She paired with juniors. She explained her reasoning. She let them make mistakes and guided them through debugging. She celebrated their promotions as her own achievements. Years later, engineers she had mentored were leading teams across the industry. Her legacy was not in code—it was in the hundreds of engineers who carried her lessons forward.

D. Legacy Through Culture and Practices

The way you work—the practices you establish, the standards you set, the culture you shape—can outlast you if you embed them in how the organization operates.

Ego-Driven Culture Legacy-Driven Culture

Enforcing standards through authority and control Embedding standards through systems, habits, and shared ownership

Being the "quality police" Creating a culture where everyone cares about quality

Practices that depend on your presence Practices that persist even when you are not there

Blaming individuals for failures Building blameless post-mortems and systemic improvement

Example:

A tech lead enforced code quality by personally reviewing every line of code. When he was present, quality was high. When he went on vacation, standards slipped. He was the bottleneck. His quality culture was actually a dependency.

Another tech lead established practices: automated testing, code review checklists, shared ownership of quality. She taught the team why these practices mattered. She created systems that enforced quality without her presence. When she left, the practices continued. Her legacy was not her reviews—it was a team that no longer needed her to maintain quality.

E. Legacy Through Open Source and Community Contribution

For many engineers, open-source contribution is a direct form of legacy. Code you write today may be used by thousands of projects for decades.

Ego-Driven Open Source Legacy-Driven Open Source

Building a project for personal recognition Building a project to solve a problem that many people face

Poor documentation, assuming users will figure it out Comprehensive documentation, examples, and onboarding

Not accepting contributions; controlling the project Building a maintainer community; ensuring the project outlasts you

Abandoning the project when interest fades Planning for succession; handing over to new maintainers

Example:

An engineer built a popular open-source library. He was the sole maintainer. He did not accept contributions. He did not document well. When he lost interest, the library died. Users had to migrate.

Another engineer built an open-source library and deliberately built a community around it. He documented thoroughly. He recruited maintainers. He set up governance so the project could continue without him. When he moved on, the library thrived. His legacy was not the code—it was a self-sustaining project that continued to serve users.

5. The Generational Perspective: Thinking Beyond Your Career

Bartlett encourages thinking in generations, not quarters. For an engineer, this means:

Time Horizon Focus

This Quarter Ship features. Meet deadlines. Fix bugs.

This Year Build capabilities. Complete projects. Get promoted.

This Career Build expertise. Grow influence. Achieve positions.

Generations What will remain after you are gone? What did you build that outlasts you? What did you teach that continues to be taught?

The shift: Most engineers focus on the first three horizons. The legacy mindset adds the fourth. It asks: What am I doing today that will matter in 20 years?

6. The Paradox of Legacy: You May Never See It

One of Bartlett's most profound insights is that legacy is often invisible to the one who builds it.

Truth Implication

You may never see the full impact of your work. The system you designed may run for decades after you leave. The engineer you mentored may become a CTO in 15 years. The documentation you wrote may save countless hours you never witness.

Legacy is built in the ordinary, not the extraordinary. It is not the one grand gesture. It is the consistent discipline of documenting, mentoring, and building sustainably.

You build legacy by making yourself replaceable. The ultimate act of legacy is to build systems and people that no longer need you. This is counterintuitive to ego.

Bartlett's formulation:

"The goal is not to be indispensable. The goal is to build something that does not require you to be indispensable."

7. How to Build Legacy as an Engineer: A Framework

Step Action Example

1. Document Everything 

Assume you will leave tomorrow. Would someone else understand your work? Architecture decisions, runbooks, onboarding guides, design rationale.

2. Mentor Intentionally 

Treat the growth of others as core work, not extracurricular. Pair programming, teaching sessions, career guidance.

3. Build Systems, 

Not Silos Create systems that are resilient, documented, and maintainable by others. Automated testing, self-healing infrastructure, clear separation of concerns.

4. Codify Knowledge 

Move knowledge from your head to shared repositories. Wikis, videos, recorded walkthroughs, architecture decision records.

5. Create Successors 

Identify people who can take over your responsibilities. Train them. Deliberate succession planning. Handing over ownership gradually.

6. Embed Practices 

Establish practices that will continue without your enforcement. Code review culture, testing discipline, post-mortem rituals.

7. Give Credit Freely 

Make others the heroes. Your legacy is multiplied when others succeed. Publicly celebrating others' contributions. Writing recommendation letters. Advocating for promotions.

8. Ask the Legacy Question 

Regularly ask: "If I left today, what would break? What would continue?" Use the answer to guide where to invest in documentation, training, and system improvement.

8. Legacy and the Other Laws

The Law of Legacy is the culmination of all the other laws. It integrates them into a final, enduring purpose:

Law How It Contributes to Legacy

Law of the Wall (Discipline) 

Legacy is built through consistent, disciplined action over time. One grand gesture is not enough.

Law of the Reservoir 

Building reservoirs—of knowledge, relationships, systems—creates what outlasts you.

Law of the Teacher 

Teaching is the purest form of legacy. When you teach, your knowledge survives you.

Law of the Cathedral 

Legacy requires a mission larger than yourself. The Cathedral outlasts the builder.

Law of the Story 

Your legacy is carried in the stories others tell about you. What stories will they tell?

Law of the Wound 

The wisdom you gained from your wounds becomes your most valuable gift to others.

9. The Emotional Dimension: Letting Go

Bartlett acknowledges that building legacy requires emotional work. It means letting go.

Challenge Legacy Response

Letting go of control 

Your legacy is not in your control. It is in what others do with what you gave them.

Letting go of credit 

Your legacy may be anonymous. The best legacy often has no name attached.

Letting go of being needed 

If you build well, you become unnecessary. This is success, not failure.

Letting go of seeing the end 

You may never see the full impact of your legacy. You must build it without witnessing its completion.

Bartlett's reflection:

"The cathedral builders of medieval Europe never saw the finished building. They laid stones for generations they would never meet. They did not need to see the finished cathedral to know it mattered. Neither do you."

10. Summary: The Law of Legacy (Engineer's Perspective)

Element Summary

Definition Success is measured not by what you accumulated, but by what you leave behind. Legacy is what outlasts you.

Core Principle Ego asks, "What can I achieve?" Legacy asks, "What can I leave?"

Two Types Tangible legacy (code, systems, products) and intangible legacy (people, culture, knowledge). Intangible is ultimately more enduring.

Ego vs. Legacy Mindset Ego hoards, seeks credit, creates dependency. Legacy shares, gives credit, builds independence.

Engineer Legacy Forms Code and systems, documentation, mentorship, culture and practices, open-source contribution.

Legacy Framework Document everything, mentor intentionally, build systems not silos, codify knowledge, create successors, embed practices, give credit freely, ask the legacy question.

The Paradox You may never see your legacy. You build it by making yourself replaceable.

Book Context Law 33—the culmination of all laws. The final measure of a life and career.

Quick Reference: Engineer's Legacy Checklist

Question Action

If I left tomorrow, would my systems survive? 

Document. Automate. Reduce complexity. Create runbooks.

If I left tomorrow, would my knowledge survive? 

Write documentation. Record walkthroughs. Share what I know.

If I left tomorrow, would the people I mentored thrive? 

Invest time in mentoring. Build independence. Celebrate their growth.

If I left tomorrow, would the practices I established continue? 

Embed practices in systems, not personality. Create shared ownership.

What stories will people tell about me after I am gone? 

Live and work in a way that creates stories worth telling.

What am I building that will matter in 20 years? 

Choose work that outlasts quarterly goals. Invest in enduring impact.

11. A Final Reflection: The Engineer's Cathedral

Bartlett closes the book with the image of the cathedral—the structure built over centuries by people who would never see it completed.

For an engineer, the cathedral is:

· The open-source project that outlives its original authors

· The system design so clear and robust that it runs for decades

· The documentation that saves countless hours for engineers who will never know your name

· The junior engineer you mentored who becomes a leader and mentors others

· The culture of quality, safety, and learning that persists long after you have moved on

The Law of Legacy asks you to be a cathedral builder. To lay bricks for a structure you may never see completed. To invest in people whose success you may never witness. To build systems that will outlast your tenure. To share knowledge that will propagate beyond your reach.

"You do not need to see the finished cathedral to know it matters. You just need to lay the bricks well. The rest takes care of itself."

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?