Terdampar di hilir Sungai Kinabatangan

 

Mac 2004, saya menjejak kaki ke Morisem Palm Oil Mill ‘B’ sebagai seorang kadet jurutera.

Sebuah kilang yang ketika itu baru beroperasi kurang daripada setahun, namun sudah gah berdiri sebagai kilang sawit terbesar dalam syarikat, berkapasiti 120 mt/jam. Dibina megah di atas kaki bukit, dengan dua cerobong boiler berkapasiti 45 mt/jam model water tube Mechmar menjulang ke langit.

Seorang rakan berkongsi gambar kilang tersebut yang dirakam pada tahun 2020, ketika dunia dibungkus sunyi oleh COVID-19.

Semasa saya mula menyertai kilang ini, pokok-pokok sawit masih muda, usianya belum pun mencecah 10 tahun. Saujana mata memandang. Pemandangan kilang sawit inilah yang menjadi saksi tempat saya memulakan kerjaya sebagai jurutera stim, menjadi seorang suami, dan memulakan kehidupan sebagai seorang ayah kepada puteri pertama kami.

Di sinilah semuanya bermula.

Sebenarnya, selepas tamat pengajian dalam bidang Kejuruteraan Mekanik di Universiti Sains Malaysia, Kampus Kejuruteraan Nibong Tebal pada tahun 2003, perjalanan hidup membawa saya berpindah tempat kerja dari Pulau Pinang, Kelantan dan Selangor. Akhirnya saya terdampar ke sebuah tempat asing yang tidak pernah dijejaki sebelumnya — pendalaman Sungai Kinabatangan.

Perjalanannya bukan mudah.

90 kilometer melalui Jalan Jeroco yang berbatu. Laluan kedua pula melalui feri di Kampung Sukau sebelum menyusuri Jalan Sukau ke Kinabatangan yang sama kasarnya. Kedua-duanya memakan masa lebih tiga jam untuk sampai ke Bandar Lahad Datu ataupun Sandakan.

Nama kilang sawit Morisem mempunyai huruf ‘B’ kerana Kilang Sawit Morisem pertama terletak di sebelah hilir Sungai Kinabatangan. Awal tahun 2000, kilang tersebut ditutup akibat isu alam sekitar kerana lokasinya yang terlalu hampir dengan Sungai Kinabatangan.

Perjalanan kerjaya dan kehidupan saya membina keluarga kecil bersama isteri di sini cukup berwarna-warni.

Jauh daripada keluarga di Kelantan. Berada di tempat asing dan terpencil, di tengah ladang sawit yang jauh daripada bandar dan segala kemudahan. Setahun kemudian saya berkahwin, lalu membawa isteri masuk ke dunia ladang sawit yang serba sederhana namun penuh cerita.

Mempunyai mentor dan rakan sekerja yang baik adalah rahmat paling besar dalam permulaan kerjaya saya.

Rakan serumah saya mempunyai lebih 20 tahun pengalaman dalam industri sawit, seorang anak tempatan dari Kota Belud, Sabah. Beliaulah insan pertama yang meniup inspirasi dalam jiwa saya untuk mengembara ke seluruh pelusuk negeri Sabah.

Cerita-ceritanya tentang keindahan Ranau, Kundasang dan Gunung Kinabalu cukup mengujakan saya.

Dan ya… memang benar.

Sabah itu terlalu indah.

Dari Gunung Kinabalu ke Pantai Kalampunian, dari hutan tropika Lembah Danum ke Sungai Kinabatangan, hinggalah ke gugusan pulau-pulau Semporna.

Dalam bertatih menjadi seorang jurutera, saya sangat bertuah kerana mempunyai seorang ketua yang juga merupakan seorang jurutera profesional berpengalaman puluhan tahun dalam industri sawit serta beberapa syarikat ternama negara.

Beliau sering menasihati saya supaya mendalami ilmu pengurusan dengan lebih serius.

Kerana beliau, hari ini saya bergelar jurutera profesional, di samping memiliki kemahiran dalam bidang pengurusan hasil fokus yang diberikan kepada kedua-dua bidang tersebut.

Namun, di kolam takungan biru ini juga, tersimpan satu pengalaman yang sangat menyayat hati.

Seorang kanak-kanak mati lemas ketika memancing bersama datuknya.

Kawasan itu sebenarnya kawasan larangan memancing.

Itulah kematian pertama yang berlaku di depan mata saya sendiri.

Sehingga hari ini, kejadian itu masih segar dalam ingatan — saat bagaimana saya turut turun menyelam bersama-sama dalam usaha mencari mangsa lemas tersebut.

Peristiwa itu membentuk jiwa saya.

Ia menanam semangat yang lebih kental dalam menguatkuasakan peraturan keselamatan di tempat kerja.

Di kilang ini juga, saya sempat berguru dengan empat orang pengurus yang masing-masing mempunyai karakter kepimpinan yang berbeza.

Kesemuanya menjadi pengajaran dan pedoman dalam mendepani tanggungjawab pada masa hadapan.

Yang baik diambil.

Yang kurang baik dijadikan sempadan.

Namun, kesemua mereka tetap memberikan asas pengurusan yang kuat untuk perjalanan lebih 20 tahun kerjaya saya selepas itu.

Sebagai insan baru, muda dan masih kering pengalaman, setiap butir nasihat mentor serta rakan sekerja cukup memberi motivasi, inspirasi dan kekuatan kepada diri untuk terus berdiri, walau di mana jua berada.

Pada tahun 2009, saya berpindah ke syarikat baharu di Loagan Bunut, Miri, Sarawak.

Sejak itu, saya mula menulis dan menjadi mentor kepada ramai pengikut di Blog Kembara Insan.

Kenapa?

Kerana itulah cara saya menunjukkan rasa syukur atas jasa orang-orang lama yang pernah membimbing saya.

Saya curahkan pengalaman dan ilmu kepada jiwa-jiwa muda.

Dan sehingga hari ini…

saya masih lagi menulis.

Semoga setiap perkongsian ini terus memberi manfaat.

Kredit gambar: FB Zul Rahman.

#KembaraInsan #blog #sawit #mpob #LahadDatu #ranau #sabah #borneo #sarawak

Learned Helplessness

That’s a very real and common issue—and from a psychological perspective, it goes deeper than just “management not listening.” It shapes how people perceive risk, power, and personal safety in the workplace.

---

What’s happening psychologically?

1. Learned Helplessness

When staff repeatedly speak up but see no action, they start to believe:

“Nothing will change anyway.”

This is known as Learned Helplessness.

Impact in a chemical plant:

• Workers stop reporting hazards

• Near-misses go unshared

• People mentally disengage from safety responsibility

---

2. Low Voice Efficacy

Employees ask themselves subconsciously:

“Is it worth speaking up?”

If past experience says “no,” their voice efficacy (belief that speaking up matters) drops.

Result:

• Only the most serious issues get reported (too late)

• Small warning signs are ignored

---

3. Psychological Contract Breach

Workers expect:

“If I raise safety concerns, management will act.”

When that doesn’t happen, it breaks the unwritten trust—called a psychological contract.

Consequences:

• Cynicism (“management doesn’t care”)

• Reduced commitment to safety rules

• “Why should I care if they don’t?”

---

4. Fear Conditioning (Indirect)

Even without punishment, people observe:

• Others being ignored

• Concerns dismissed in meetings

This creates silent fear, not of punishment—but of:

• Being seen as annoying

• Wasting time

• Looking incompetent

---

5. Social Norms: Silence becomes the culture

Humans follow group behavior.

If the norm is:

“We don’t speak up here”

Then even confident employees will stay quiet.

---

Why this is dangerous in chemical plants

In high-risk environments, disasters rarely come from a single failure. They come from accumulated silence.

This pattern was seen in incidents like the Deepwater Horizon oil spill, where warning signs existed—but escalation and response were inadequate.

---

How to fix it (psychologically, not just procedurally)

1. Close the feedback loop

The biggest mistake management makes:

Listening… but not responding

Instead:

• Acknowledge every concern

• Explain what action was taken (or why not)

👉 This rebuilds belief that speaking up matters

---

2. Visible action from leadership

People don’t trust words—they trust patterns.

• Fix even small issues quickly

• Publicly credit the person who raised it

This shifts mindset from:

“No one listens” → “Speaking up works”

---

3. Rebuild trust through consistency

Trust is not rebuilt in one meeting.

It requires:

• Repeated follow-through

• Transparent decisions

• No selective listening

---

4. Make silence visible

Track:

• Reporting rates

• Participation in meetings

Low numbers ≠ safe plant
Low numbers = people have given up

---

5. Train leaders to respond properly

A bad response like:

“We already know that”

can shut someone down permanently.

Better response:

“Thanks, let’s look into it together.”

---

Simple mental model

Employee decision process:

1. “Will they listen?”

2. “Will anything change?”

3. “Is it worth the effort?”

If any answer = NO → silence

---

Key takeaway

When staff stop speaking up, it’s not laziness or lack of awareness—it’s a learned psychological response to being ignored.

In chemical plants, this is extremely risky because:

Ignored voices today become incidents tomorrow.

Psychological safety in chemical plant

Texas-catastrophic-explosion

Psychological safety in a chemical plant means workers feel safe to speak up about risks, mistakes, or concerns without fear of punishment, blame, or embarrassment. In high-hazard environments like chemical processing, this is just as important as physical safety systems.

---

Why it matters in chemical plants

Chemical plants deal with dangerous materials, complex processes, and tight operating limits. Disasters often happen not just technical failures—but because people stayed silent.

Psychological safety helps:

• Catch small issues before they escalate (e.g., leaks, abnormal readings)

• Encourage reporting of near-misses

• Improve teamwork during emergencies

• Reduce human error caused by stress or fear

A lack of it has contributed to major incidents like the Texas City Refinery explosion, where warning signs were missed or not escalated properly.

---

What it looks like in practice

In a psychologically safe chemical plant:

• Operators freely question unusual readings

• Junior staff can challenge senior decisions

• Mistakes are discussed openly for learning—not punishment

• Safety meetings involve real input, not just compliance

---

How to improve psychological safety

1. Leadership behavior (most critical)

• Supervisors should invite input: “What are we missing?”

• Respond to concerns with appreciation, not criticism

• Admit their own mistakes to model openness

👉 If leaders shut people down even once, people stop speaking up.

---

2. Just Culture (fair accountability)

• Separate human error from negligence

• Focus on fixing systems, not blaming individuals

• Use incident investigations as learning tools

---

3. Encourage near-miss reporting

• Make reporting simple and quick

• Reward reporting (even small issues)

• Share lessons learned across teams

---

4. Structured communication tools

Use standardized methods:

• Shift handover checklists

• Pre-job safety briefings

• “Stop work authority” policies

Everyone should feel empowered to stop unsafe operations.

---

5. Training and simulation

• Run emergency drills where all voices matter

• Train workers to speak up assertively

• Practice challenging authority in safe scenarios

---

6. Reduce hierarchy barriers

• Encourage informal interaction between levels

• Rotate roles in safety meetings

• Ask quieter team members directly for input

---

7. Measure and monitor

• Use anonymous surveys

• Track reporting rates (low reporting can mean fear, not safety)

• Look for patterns of silence or underreporting

---

Simple example

A control room operator notices a slight pressure increase:

• Low psychological safety: stays quiet → possible explosion risk

• High psychological safety: speaks up → team checks → issue resolved early

---

Key takeaway

In chemical plants, silence is a hidden hazard. Psychological safety turns every worker into an active safety sensor, not just a rule follower.

BP Texas City Explosion, 2005

On March 23, 2005, a catastrophic explosion at BP's Texas City refinery killed 15 workers and injured 180 others. It is considered the world's costliest refinery accident, with total liabilities exceeding $2.5 billion.

⚙️ What Went Wrong?

The disaster occurred during the startup of the Isomerization (ISOM) unit and was caused by a combination of technical failures and cost-cutting:

· The Incident: Operators overfilled a 170-foot "raffinate splitter" tower. When heated, the liquid overflowed into a blowdown stack and was vented directly into the atmosphere instead of the sewer. A geyser of flammable liquid formed, and a running vehicle engine ignited it.

· The Fatal Trailer: The blowdown stack was located just 150 feet from temporary work trailers. All 15 victims were contractors in these trailers, which were never evacuated despite warnings.

🏛️ Systemic Failures

Investigations (CSB, Baker Panel) found the root cause was BP's corporate culture, not just operator error:

· Cost Cutting: A 25% budget cut led to poor maintenance, understaffing, and reduced training. Audits warned of "catastrophic risk" years before the blast.

· Production Pressure: Profit was prioritized over safety. A report noted that "production and budget compliance gets recognized before anything else".

· Warning Fatigue: Alarms were ignored because upsets had become "routine." Crucially, organizational changes (cuts to staffing) were not reviewed for safety impact.

⚖️ Aftermath and Legacy

The explosion had massive legal and industry-wide consequences:

· Record Fines: BP pleaded guilty to a Clean Air Act violation, paying a $50 million** fine—the largest criminal fine for a single OSHA violation in history. BP also pledged **$500 million for safety improvements.

· Industry Changes: The industry revised standards for trailer siting (to keep workers further from hazards) and fatigue prevention (for shift workers). One CSB safety recommendation regarding organizational "Management of Change" remains open as of 2025.

· Reputation: The disaster was the first in a series (including Deepwater Horizon) that severely damaged BP's reputation, eventually forcing the sale of the refinery.

Esso Longford Gas Plant Incident 1998

On September 25, 1998, a devastating explosion and fire at Esso's Longford gas plant in Victoria, Australia, killed two workers and injured eight others. It caused a two-week gas supply shutdown to the state of Victoria, affecting 1.4 million households and 89,000 businesses, with economic losses estimated at A$1.3 billion.

💥 What Went Wrong?

The disaster resulted from a chain reaction caused by low temperature embrittlement:

· The Incident: A pump failed, stopping the flow of hot oil. Cold gas entered a heat exchanger (GP905), cooling parts of it to -48°C, making the steel brittle.

· The Rupture: When the pump restarted, it sent 230°C oil into the brittle vessel. The sudden temperature shock caused it to rupture, releasing 10 tonnes of gas that ignited.

⚖️ The Royal Commission Findings

Contrary to Esso's initial claims of "operator error," the Royal Commission found Esso fully responsible, citing systemic safety failures:

· Inadequate Training: Operators lacked procedures to manage complex "upsets" like the pump failure.

· Poor Design: The layout lacked isolation valves, causing the fire to spread uncontrollably.

· Warning Fatigue: An excessive number of alarms desensitized operators to critical warnings.

· Remote Management: Moving engineers to Melbourne reduced on-site technical supervision.

📜 Consequences and Legacy

The findings led to significant legal and regulatory changes:

· Record Fine: Esso was fined A$2 million** (a record at the time) and paid **A$32.5 million in a class-action settlement.

· New Regulations: Victoria introduced Major Hazard Facility regulations, requiring strict safety cases and management systems for high-risk plants.

The Phillips Pasadena Explosion 1989

The Phillips Pasadena explosion occurred on October 23, 1989, at a chemical complex in Pasadena, Texas, killing 23 workers and injuring 314 others—making it one of the worst industrial disasters in U.S. history .

From a process safety perspective, this incident is a definitive case study in how routine maintenance on a single valve, combined with flawed design and inadequate procedures, can trigger a catastrophic vapor cloud explosion.

⚙️ The Direct Technical Cause: A Valve Connected Backwards

The disaster occurred during maintenance on a polyethylene reactor operating at high pressure (700 psi) . The immediate cause was a single block valve left open:

· 85,000 lbs of highly flammable hydrocarbon gases (ethylene, isobutane) were released almost instantaneously 

· The release formed a vapor cloud that ignited within 90–120 seconds 

· The explosion had the force of 2.4 tons of TNT and registered 3.5 on the Richter scale 

· The initial blast was followed by at least six further explosions, including a 20,000-gallon isobutane tank 

Why did the valve fail?

The accident had a mechanical root cause: a design flaw in the valve actuation system. Compressed air hoses for opening and closing the valve used identical fittings, and during reconnection, the hoses were reversed. This meant the control room indicator showed "valve closed" when the valve was actually open .

🛑 Layer of Protection Failures

Safety Layer What Failed

Lockout/Tagout (LOTO) 

Inadequate procedures; the open valve was not physically locked out 

Permit-to-Work System 

Maintenance permits did not adequately control the hazard 

Combustible Gas Detection 

No gas detection or alarm system existed to warn of the release 

Process Hazard Analysis (PHA) 

Had never been properly conducted for this operation 

Fail-Safe Valve Design 

The block valve was not fail-safe (i.e., it did not automatically close on loss of air pressure) 

Firewater System 

The explosion sheared off fire hydrants and disabled electrical power to fire pumps. Backup diesel pumps failed (one out of service, one ran out of fuel) 

Building Siting 

High-occupancy structures (control rooms, offices) were dangerously close to reactors 

🧠 Systemic & Cultural Failures

The OSHA investigation identified catastrophic failures in Phillips' safety management systems :

· Inadequate Standard Operating Procedures (SOPs) for maintenance activities

· Lack of Process Hazard Analysis for the polyethylene unit

· Poor maintenance permitting system that allowed hazardous energy to remain uncontrolled

· No combustible gas detection—a fundamental layer of protection was simply absent

· Inadequate ventilation for buildings near process areas

· Crowded equipment layout with insufficient separation between hazardous operations and occupied buildings

· Normalization of deviance: The valve reconnection issue had likely occurred before, but without consequence—until it did

The investigation resulted in 566 willful and 9 serious violations against Phillips, with a proposed fine of $5.6 million (the contractor, Fish Engineering, received 181 willful violations) .

📜 Regulatory Impact: Birth of OSHA PSM

The Phillips disaster directly accelerated the development of OSHA's Process Safety Management (PSM) standard (29 CFR 1910.119) , issued in 1992 . The incident proved that relying on personal injury rates (which were low) was a poor predictor of catastrophic risk—a lesson BP would tragically re-learn at Texas City in 2005 .

Key elements of PSM that Phillips lacked, now legally required:

1. Process Hazard Analysis (PHA) for all covered processes

2. Mechanical Integrity programs for critical equipment

3. Management of Change (MOC) for modifications (including valve reconnections)

4. Pre-startup Safety Review (PSSR)

5. Contractor safety management

6. Emergency planning and response

📚 Key Process Safety Lessons

1. Lockout/Tagout is not optional – The LOTO standard was issued just weeks before this disaster (September 1989), but compliance was not yet required. Had it been in place, the valve might have been physically locked closed .

2. Design for failure – Block valves should be fail-safe (closed on loss of actuating signal). Identical fittings for "open" and "close" connections are an inherent design flaw.

3. Gas detection saves lives – A combustible gas detector could have alerted operators within seconds, potentially allowing evacuation before ignition.

4. Don't crowd the hazard – Control rooms and offices must not be located adjacent to reactors.

5. Firewater must be robust – Fire pumps must be protected from blast damage; backup systems must be tested and fueled.

In short, the Phillips disaster was not caused by a single "error" but by a systemic failure to implement basic process safety elements: hazard analysis, lockout/tagout, gas detection, and fail-safe design. The same lack of process safety management that killed 23 in Pasadena in 1989 would kill 15 in Texas City in 2005—because the industry, despite new regulations, still struggled with implementing what it had learned.

The Exxon Valdex Oil Spill 1989

The Exxon Valdez oil spill (March 24, 1989) was not a process plant disaster, but from a process safety perspective, it is a landmark case in human factors, fatigue management, maintenance of critical safeguards, and emergency response. It spilled roughly 11 million gallons of crude oil into Alaska’s Prince William Sound.

🛳️ The Direct Cause: A Grounding That Should Not Have Happened

The tanker left the Valdez terminal fully loaded, then deviated from the shipping lane to avoid small icebergs. The ship ran aground on Bligh Reef at 12:04 AM.

· The helmsman failed to turn in time – but that was the final error in a chain.

· Critical equipment was bypassed: The Raytheon Collision Avoidance Radar (RAYCAS) was broken and had been inoperable for over a year. The company allowed the ship to sail without it.

· The lookout was not posted – required by rules, but the third mate did not call him to the bridge.

😴 The Human Factor & Work System Failure

The root cause from a process safety view is fatigue and understaffing:

Factor What Happened

Sleep deprivation 

The third mate (on watch) had had only 6 hours of sleep in the previous 48.

Excessive workload 

After the pilot left, the third mate was alone on the bridge for over 3 hours (no lookout, no second officer).

No relief system 

There was no policy to ensure rested watchstanders.

Company pressure 

Sailing late was normal; reporting fatigue was discouraged.

🛡️ Failure of Safety Layers (Like Process Safety Barriers)

Barrier Failure

Bridge manning Required two officers + lookout; only one officer was present.

Collision avoidance radar Broken for a year, not fixed (deferred maintenance).

Traffic separation scheme The ship left the designated lane – no alarm or oversight.

Pilot onboard The harbor pilot left before the most hazardous part of the voyage (iceberg zone).

Vessel Traffic Service (VTS) The Coast Guard radar could see the deviation but did not broadcast a warning.

🌊 Emergency Response Failures (Critical for Process Safety)

· Delay: The company took over 10 hours to begin dispersant application, then stopped due to false concerns.

· No local plan: There was no pre-staged equipment or trained response team in Valdez.

· Equipment not ready: Booms and skimmers were stored far away or in disrepair.

· Command confusion: Exxon, the Coast Guard, and Alaska had overlapping authority with no clear leader.

🧠 Systemic & Cultural Root Causes

· Cost cutting: Reduced crew sizes and deferred radar repair to save money.

· Weak regulation: The Oil Pollution Act (OPA 90) did not yet exist; no required spill response plan or double hulls.

· Normalization of deviance: Skipping the lookout and sailing with broken radar was routine at Exxon. Nothing had gone wrong before.

· Poor safety culture: Exxon’s internal audits had flagged fatigue and manning issues years earlier – no action was taken.

📚 Key Process Safety Lessons (Now Embedded in Law)

The Exxon Valdez directly created OPA 90 (Oil Pollution Act of 1990) and changed maritime safety:

1. Fatigue is a process hazard – Hours-of-service rules and crew rest standards are now regulated.

2. Maintenance of safety-critical equipment – Radar and navigation aids cannot be deferred without formal management of change.

3. Emergency response must be real – Plans, equipment, and drills must be in place before an incident.

4. Double hulls – New tankers must have double hulls to prevent spills from groundings.

5. Vessel Traffic Service authority – The Coast Guard now has enforceable authority over tanker navigation in sensitive waters.

6. “No lookout” is never acceptable – Minimum manning rules are now strictly enforc

In short, the Exxon Valdez did not run aground because of ice, a reef, or even a helmsman’s error. It ran aground because Exxon allowed a tired, single officer to sail a broken ship without a lookout, and the industry had no law requiring a basic spill response.

The Piper Alpha Disaster 1988

The Piper Alpha disaster (July 6, 1988) is the world’s deadliest offshore oil accident, killing 167 men. From a process safety perspective, it is the classic case of how permit-to-work failures, poor physical layout, and inadequate emergency response turn a small incident into a total loss.

🔧 The Direct Technical Cause: A Missing Blind Flange

The disaster began with a condensate pump (Pump A) being removed for maintenance. To isolate it, workers installed a blind flange—a solid plate that absolutely stops flow. However:

· That night, another shift tried to start the second pump (Pump B), which had failed.

· When Pump B didn’t work, they started the maintenance pump (Pump A) without checking if the blind flange was still in place.

· Result: Condensate (highly volatile liquid) erupted from the open pipe at high pressure. A gas cloud formed and ignited within seconds.

🔥 Why the Fire Became a Catastrophe

Unlike a normal fire, Piper Alpha had no firewalls between major modules. The initial blast ruptured an oil riser (a large pipe from another platform), feeding the fire like a blowtorch. Within minutes:

· Multiple risers failed → oil and gas from other platforms poured into the fire.

· Accommodation block was located next to the process area → no escape for sleeping workers.

· Emergency systems (firewater pumps) were in manual mode because divers were in the water earlier. No one turned them back on. The pumps never started.

📋 The Permit-to-Work (PTW) System Collapse

This is the most studied process safety failure from Piper Alpha:

Failure What Happened

Shift handover 

Night shift knew Pump A was incomplete, but the permit was not physically handed over or revalidated.

Missing pressure test 

No one verified the blind flange was still installed.

Simultaneous operations 

Permits for maintenance on Pump A and operation of other pumps were allowed to overlap.

Lost communication 

The control room could not see the blind flange status; they relied on verbal, unrecorded information.

No permit retrieval 

The permit for Pump A was not formally closed before the shift ended.

🏢 Systemic & Cultural Root Causes

· Physical siting: Critical safety equipment (fire pumps, control room, living quarters) was placed next to hydrocarbon sources.

· Emergency response: No pre-planned strategy for simultaneous riser fires. Lifeboats were inaccessible.

· Regulatory failure: No independent safety case was required. The UK government relied on voluntary codes.

· Normalized risk: Small gas leaks and pump problems were routine; alarms were often ignored or silenced.

📚 Key Process Safety Lessons (Now Industry Standard)

Piper Alpha fundamentally changed offshore safety worldwide:

1. Permit-to-work is sacred – A permit must be physically returned, revalidated each shift, and never assumed.

2. No simultaneous operations – Maintenance on safety-critical equipment must not overlap with production.

3. Firewater must be automatic – Fire pumps cannot rely on manual start; they must activate immediately.

4. Escape routes and accommodation – Living quarters must be isolated from process areas, with multiple escape paths.

5. Safety case regime – Operators must now prove (not just claim) that risks are reduced to as low as reasonably practicable (ALARP).

6. Emergency response for worst-case – Plan for multiple riser fires, not just a small leak.

In short, the Piper Alpha fire started with a missing blind flange, but the deaths were caused by a broken permit system, a platform designed like a bomb (no firewalls), and firewater pumps that never ran.

The Chernobyl 1986 Disaster

The 1986 Chernobyl disaster is the most severe nuclear accident in history. From a process safety perspective—applied here to a nuclear reactor—it’s a powerful example of how a poorly designed process combined with a flawed safety culture can defeat even multiple physical safety systems.

⚛️ The Direct Technical Cause: A Flawed Experiment

On April 26, 1986, operators were conducting a test on Reactor 4 of the Chernobyl Nuclear Power Plant in Ukraine (then USSR). The test was to see if the spinning turbine’s inertia could run emergency water pumps long enough during a power loss.

· Improper Reactor State: The reactor was operating at very low power (a highly unstable condition for the Soviet RBMK design) with safety systems either disabled or ignored.

· Critical Design Flaw – “Positive Void Coefficient”: In most reactors, coolant boiling slows the reaction (negative feedback). In the RBMK, boiling increased reactivity dramatically (positive feedback), making it prone to runaway.

· Loss of Cooling: Operators withdrew almost all control rods to boost power. When they then started the test, coolant flow dropped, causing steam bubbles to form.

· Runaway Reaction: The steam bubbles increased reactivity instantly. Power surged to 10x normal in seconds.

Berikut : The intense heat ruptured fuel rods, causing a steam explosion that blew the 1,000-ton reactor lid off. A second explosion (likely hydrogen or chemical) destroyed the building, releasing massive amounts of radioactive material.

🛑 Layer of Protection Failures (Bhopal & Texas City parallel)

Safety Layer What Failed

Inherently Safer Design 

The RBMK reactor had a dangerous positive void coefficient – a known flaw.

Control Rods 

Rods had a graphite tip that initially increased reactivity when inserted, causing a last-second power surge.

Emergency Protection System (AZ-5) 

The emergency shutdown button was pressed, but it triggered the deadly reactivity surge due to the rod design.

Containment Building 

The RBMK had no Western-style primary containment structure.

Operating Procedures 

The test violated multiple safety rules; no formal risk assessment was done.

🧠 Systemic & Cultural Failures (The Real Root Causes)

The physical flaws were compounded by deep organizational problems:

1. “Safety Culture” – The Opposite: Soviet nuclear management valued production over safety. Operators were punished for reporting problems. The test was approved despite known risks.

2. Silence of the Regulators: The state nuclear agency was not independent; it was part of the same ministry that ran the plants.

3. Poor Training: Operators did not fully understand the RBMK’s instability at low power because that information was classified as a state secret.

4. No Independent Oversight: Unlike the West, there was no external regulatory body or peer review.

5. Normalization of Deviance: Disabling safety systems for “convenience” had become routine at Chernobyl because nothing had gone wrong before.

☢️ Consequences & Process Safety Lessons

· Immediate Deaths: 31 directly (operators, firefighters) from acute radiation sickness. Many more later from radiation-induced cancers.

· Evacuation: 116,000 people permanently relocated; a 30-km exclusion zone remains.

· Environmental Contamination: Large parts of Europe received measurable fallout.

Key lessons for process safety (any industry):

· Design for failure: Assume safeguards will fail and design multiple, independent layers of protection.

· Safety functions must be independent and reliable: An emergency shutdown system should not be capable of causing an accident.

· Culture trumps hardware: The best design cannot survive a culture that punishes bad news and normalizes shortcuts.

· Transparency saves lives: Secrecy about hazards prevents proper risk understanding by both operators and the public.

In short, Chernobyl was not an “act of nature.” It was a disaster built into the reactor’s physics, then triggered by a test conducted without safety discipline, under a management system that treated safety as optional.

The Bhopal Disaster 1984

The Bhopal disaster (1984) is the world’s worst industrial catastrophe. From a process safety perspective, it’s a textbook case of how multiple, seemingly minor failures and cost-cutting decisions can combine into a lethal outcome. Over 2,000 people died immediately, with estimates later reaching 15,000–20,000 deaths.

☠️ The Direct Chemical Release

At a Union Carbide pesticide plant in Bhopal, India, water entered a storage tank containing methyl isocyanate (MIC)—a highly toxic and reactive chemical.

· Runaway Reaction: Water triggered a violent exothermic reaction, causing pressure and temperature to spike inside the tank.

· Safety Systems Failed: The tank’s pressure gauge was non-functional, the refrigeration unit (designed to keep MIC cool) was turned off to save money, and the vent gas scrubber (a chemical "scrubber" to neutralize toxic fumes) was on standby and ineffective.

· Massive Toxic Release: An estimated 40 tons of MIC gas erupted from the vent stack in under two hours, forming a dense cloud that drifted over nearby slums.

🧠 Systemic Process Safety Failures

The disaster was not a single accident but a collapse of multiple safety layers:

System Failure

Hazard Identification 

The company knew MIC was extremely hazardous but didn’t fully model a large-scale release scenario.

Layer of Protection 

All critical safety barriers (scrubber, flare, refrigeration, water curtain) were either off, undersized, or bypassed.

Management of Change (MOC) 

A cost-cutting program removed the refrigerant from the MIC tank and reduced staffing—without a formal risk review.

Maintenance & Inspection 

Corroded pipes, leaking valves, and malfunctioning instruments were ignored.

Emergency Response 

The community alarm was not sounded for over an hour, and the public had no evacuation plan or information.

Process Safety Information (PSI) 

The site lacked updated operating procedures and a credible emergency plan for a major MIC release.

Site Layout / Siting Slums had been allowed to grow within meters of the plant boundary—no buffer zone.

🌍 Root Causes: Corporate & Regulatory

· Short-term cost cutting: Reduced safety spending, maintenance deferrals, and inventory reduction (storing more MIC than needed to save on transport costs).

· Poor training: Operators were unfamiliar with MIC hazards and safety systems.

· Weak regulation: India had no effective process safety regulations or independent inspection at the time.

· Lower safety standards: The Bhopal plant was operated with significantly fewer safety systems than its sister plant in West Virginia, USA.

📚 Key Lessons for Process Safety

Bhopal permanently changed the industry:

1. Hazards do not respect borders – The same process requires the same safety standards globally.

2. Never disable a safety system – The scrubber, flare, and refrigeration were all inactive; each was a broken link in the chain.

3. Worst-case scenarios must be studied – Not just minor leaks.

4. Community awareness and emergency planning are non‑negotiable – People living nearby have a right to know the risks.

5. Cost cutting can kill – Every decision to bypass a safety layer must be reviewed by management of change.

In short, Bhopal was not a freak accident. It was the predictable result of degraded safety culture, broken equipment, inadequate training, and deliberate cost reduction over many years. The operators made the final error (allowing water into the tank), but the company built the trap.

10 Biggest Process Safety Incidents

Here’s a curated list of 10 of the biggest process safety incidents worldwide (≈ last 40–50 years), focusing on chemical, oil & gas, and major hazard industries (not natural disasters). These are widely cited in process safety literature and training.

---

🔟 Major Process Safety Incidents (1980s–2020s)

1. Bhopal Disaster (India, 1984)

• Type: Toxic gas release (MIC)

• Fatalities: 3,000+ immediate (15,000+ long-term)

• Impact: Worst industrial disaster in history

• Key lesson: Poor maintenance, lack of safety systems, weak safety culture

---

2. Chernobyl Disaster (Ukraine, 1986)

• Type: Nuclear reactor explosion

• Fatalities: Dozens immediate, thousands long-term

• Impact: Massive radioactive contamination across Europe

• Key lesson: Design flaws + unsafe operating practices

---

3. Piper Alpha Disaster (North Sea, 1988)

• Type: Offshore oil & gas explosion/fire

• Fatalities: 167

• Impact: One of the deadliest offshore accidents

• Key lesson: Permit-to-work failure & poor communication

---

4. Exxon Valdez Oil Spill (USA, 1989)

• Type: Oil spill

• Impact: ~11 million barrels spilled

• Key lesson: Human error + inadequate safeguards

---

5. Phillips Pasadena Explosion (USA, 1989)

• Type: Vapor cloud explosion (ethylene)

• Fatalities: 23

• Key lesson: Poor isolation and maintenance practices 

---

6. Esso Longford Gas Explosion (Australia, 1998)

• Type: Gas plant explosion

• Fatalities: 2 (but massive supply disruption)

• Impact: State-wide gas outage

• Key lesson: Lack of hazard awareness & training

---

7. BP Texas City Refinery Explosion (USA, 2005)

• Type: Refinery explosion (isomerization unit)

• Fatalities: 15

• Key lesson: Cost-cutting, poor process safety culture 

---

8. Deepwater Horizon Oil Spill (USA, 2010)

• Type: Offshore drilling blowout

• Fatalities: 11

• Impact: Largest marine oil spill in history

• Key lesson: Barrier failure + risk mismanagement 

---

9. West Fertilizer Company Explosion (USA, 2013)

• Type: Ammonium nitrate explosion

• Fatalities: 15

• Impact: Town-scale destruction

• Key lesson: Poor storage & land-use planning 

---

10. San Juanico LPG Explosion (Mexico, 1984)

• Type: LPG storage explosion (BLEVE)

• Fatalities: ~500–600

• Impact: Massive domino explosions

• Key lesson: Layout, inventory control, domino effect

---

🧠 Important Context (Process Safety Perspective)

• Many of these incidents directly shaped modern regulations like:

  • OSHA PSM (USA)

  • Seveso Directive (EU)

• Common recurring causes:

  • ❌ Poor management of change (MOC)

  • ❌ Weak safety culture

  • ❌ Inadequate hazard identification (HAZOP)

  • ❌ Failure of multiple barriers simultaneously

BP Texas City Refinery Explosion

From a process safety perspective, the 2005 BP Texas City refinery explosion is a landmark case study of how systemic failures—not just individual mistakes—can lead to catastrophic disasters. The incident killed 15 and injured 180 others.

It demonstrates that process safety is not just about preventing minor injuries, but controlling hazardous materials to prevent major accidents.

⚙️ The Direct Technical Failure

The immediate cause was a distillation tower (the Raffinate Splitter) being overfilled during startup:

· Malfunctioning Gauges: The main level transmitter was unreliable, the high-level alarm was faulty, and the sight glass was dirty, preventing operators from seeing the true level.

· Operating Errors: Operators followed an unofficial procedure and left an outlet valve closed, causing the tower to fill completely.

· The Release: This created excessive pressure, forcing a geyser of flammable liquid out of a blowdown stack (a safety relief system that vented directly to the atmosphere).

👥 A Failure of "Safety Culture"

The Baker Panel report found that BP had focused on personal safety (e.g., slip-and-fall rates) while neglecting process safety (e.g., managing equipment integrity). Key cultural issues included:

· Complacency: Managers mistakenly interpreted low personal injury rates as meaning the plant was safe.

· Normalization of Deviance: Using unofficial shortcuts became standard practice because "nothing bad happened" before.

· Poor Communication: A supervisor left during the startup without a replacement, leading to confusion.

🏢 Systemic Management Gaps

The root causes were embedded in broken safety management systems:

· Poor Trailer Siting: Temporary trailers were placed dangerously close (as near as 37 meters) to the blowdown stack, turning them into "death traps".

· Inadequate Mechanical Integrity: Critical alarms were broken for a long time, and no one fixed them.

· Weak Management of Change (MOC): Major decisions—like budget cuts and staffing report ductions—eroded safety layers without proper risk review.

💡 Key Lessons Learned

The disaster fundamentally changed the industry:

1. Metrics Matter: You must track process safety indicators (like alarm performance), not just injury rates.

2. Lead from the Top: Safety requires consistent leadership and resources from executive management.

3. Question "Normal": If informal procedures become the norm, the system is broken.

4. Control of Change: Organizational changes (like budget cuts) must be reviewed as strictly as hardware changes.

In short, while an operator made the final error, the disaster was "written" by years of corporate decisions that tolerated risk for the sake of production.

I hope this explanation helps clarify the process safety aspects of this important case. If you would like to dive deeper into a specific element, such as the Baker Panel's recommendations or the concept of "safety culture," feel free to ask.

The horse by the pond

You can lead a horse to the water, but you cannot make it drink.

I used to think the problem was the horse.

Stubborn. Egoistic. Unwilling to change.

Until one day, I realized… maybe the problem wasn’t the horse.

Maybe it was me.

---

I have a manager in my team. A few times, feedback came from top management about the way he communicated during meetings. The message reached me, so naturally, I took it upon myself to guide him.

I shared what I knew.

What to improve.
What to avoid.
How to structure his message.

I gave him tips—many tips. Perhaps too many.

Communication and leadership are topics I’m deeply passionate about, especially after my journey with Toastmasters. I’ve seen how it transformed me, so I was excited—maybe overly excited—to pass that knowledge on.

One day, after our monthly meeting, I gathered a few staff members. I introduced them to a simple Toastmasters-style exercise.

A three-minute speech.
A timer.
An “Ah-counter.”

After the speech, I gave my evaluation. Then others followed.

It felt productive. Structured. Meaningful.

At least, that’s what I thought.

---

Then I asked him,
“What do you think about this session?”

His response stopped me.

He said he had worked in many companies before, and no one had ever criticized the way he spoke. He felt uncomfortable—disappointed, even—with the amount of feedback he was receiving now.

“What is the real issue?” he asked.

His words hit deeper than I expected.

I paused.

That night, I went home and thought about it. For hours.

---

Lately, I had been hearing something similar from people closer to me.

My children said I talk too much.
That I “nag.”
That not everything I say is easy to accept.

My wife, too, would point out that when I speak, I often drift away from the main point.

Different people.
Different settings.
Same message.

That was not coincidence.

That was a mirror.

---

It was time to reflect—not on others, but on myself.

Maybe not all advice needs to be spoken.
Maybe not all knowledge needs to be shared immediately.
Maybe… advice that is not asked for often carries little value.

Or worse, it creates resistance.

---

I began to see it differently.

Perhaps I had been trying too hard to make the horse drink.

Standing there, pointing at the water.
Explaining how clear it is.
How important it is.
How thirsty the horse should feel.

But I never stopped to ask—

Is the horse ready?

---

So now, I choose a different path.

I listen more.
I speak less.
I ask before I advise.

Because sometimes, leadership is not about giving the best answers.

It is about creating the space for others to discover their own.

And maybe…

When the horse is truly thirsty,
it will drink on its own.

Bowtie in PSM (Process Safety Management)

In Process Safety Management (PSM), the Bowtie method is a risk assessment tool that visualizes the relationships between hazards, potential incidents, and the barriers preventing them. It gets its name from the bowtie shape formed by combining a fault tree (left side) and an event tree (right side).

Here’s a detailed breakdown.

1. Core Components of a Bowtie Diagram

A bowtie centers on a specific Top Event (the loss of control). Around it, you map:

· Hazard: Something with the potential to cause harm (e.g., a storage tank of gasoline).

· Top Event: The point where control is lost, but no harm has occurred yet (e.g., "Leak from tank").

· Threats: Causes or initiators that could lead to the top event (e.g., corrosion, overfilling, impact from vehicle).

· Consequences: Outcomes if the top event unfolds unchecked (e.g., fire, explosion, environmental damage, fatality).

· Prevention Barriers: Controls that stop a threat from causing the top event (e.g., level alarms, corrosion inspection).

· Mitigation Barriers: Controls that stop the top event from escalating into severe consequences (e.g., firewalls, emergency shutdown, evacuation alarms).

· Escalation Factors: Conditions that could defeat a barrier (e.g., "alarm ignored due to operator fatigue").

· Escalation Controls: Measures to prevent escalation factors (e.g., alarm management policy, shift rotation).

2. How the Bowtie is Constructed (Step-by-Step)

1. Identify the Hazard & Top Event: Choose a critical process hazard and define the exact moment of control loss.

2. List Threats (Left Side): Brainstorm all credible ways the top event could happen.

3. Draw Prevention Barriers: For each threat, list barriers that prevent reaching the top event.

4. List Consequences (Right Side): What outcomes are possible after the top event?

5. Draw Mitigation Barriers: For each consequence, list barriers that reduce severity.

6. Add Escalation Factors: For each barrier, ask: "What could make it fail?" (e.g., bypassed, poorly maintained).

7. Add Escalation Controls: Measures to ensure barriers remain effective.

3. Why Bowtie is Unique vs. Other PSM Tools

Tool Focus Limitation Bowtie Advantage

HAZOP Identify deviations and causes Can become cluttered; doesn't show barrier links Organizes causes and barriers visually around a single top event

LOPA (Layer of Protection Analysis) Quantifies risk reduction Numerical, less intuitive for operators Shows how layers interlock; better for communication

FMEA Component failure modes Narrow focus on equipment Broad view including human and organizational factors

Key Bowtie strengths:

· Visual & intuitive – Non-experts (operators, managers) grasp it quickly.

· Barrier-focused – Highlights what prevents accidents, not just causes.

· Links PSM elements – Connects procedures, training, maintenance, and emergency response in one picture.

· Identifies critical controls – Shows which barriers are most important (single barriers on many paths).

4. Practical Example (Fuel Storage Tank)

Hazard: Gasoline in atmospheric tank

Top Event: Tank overflow

Threats (Left side):

· Control system fails to close inlet valve

· Operator error during filling

· High level alarm fails

Prevention Barriers:

· Independent level transmitter + logic solver (SIS)

· Operator training and checklists

· Independent high-level switch (hardwired)

Consequences (Right side):

· Pool fire → injury/fatality

· Vapor cloud explosion → structural damage

· Soil/water contamination

Mitigation Barriers:

· Dike around tank (contains spill)

· Gas detection + firewater system

· Emergency response plan & drills

Escalation Factor: Level switch bypassed for maintenance

Escalation Control: Permit-to-work system with bypass tracking

5. Using Bowtie in PSM Systems

Under standards like OSHA PSM (29 CFR 1910.119) or CCPS RBPS, bowties support:

· Process Hazard Analysis (PHA): As a stand-alone method or supplement to HAZOP.

· Mechanical Integrity: Identifies which safety-critical equipment needs inspection frequencies.

· Management of Change (MOC): When a barrier is removed or altered, bowtie shows impacted paths.

· Operating Procedures: Clarifies when and how to interact with each barrier.

· Incident Investigation: After an incident, overlay actual barrier failures on the bowtie to find root causes.

· Auditing: Auditors can check each barrier and escalation control for effectiveness.

6. Limitations to Know

· Single top event focus – Complex facilities need many bowties.

· Static – Can become outdated without periodic review.

· Semi-quantitative – Not as precise as LOPA for risk ranking (though can be combined).

· Subject to bias – Missing a threat or barrier undermines the analysis.

7. Best Practices for Implementation

· Involve operators & maintenance – They know real barrier weaknesses.

· Keep barriers "SMART" – Specific, Measurable, Assignable, Realistic, Traceable.

· Review periodically – Update after incidents, MOC, or every 3-5 years.

· Use software – For large sites, bowtie software (e.g., BowtieXP, DNV Synergi) helps manage many diagrams and link to actions.

Summary

The bowtie method transforms a complex PSM study into a clear, actionable map. It answers: What can go wrong? How can we stop it? How can we reduce harm if it happens? And what could defeat our safeguards? For frontline workers, it shows why following a procedure matters. For managers, it reveals where risk is truly controlled—or not.

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."