Welcome to Chapter 11: Building Adaptive Organizations

We’ve learned how to move fast with small batches (Chapter 9) and how to grow sustainably (Chapter 10). Now comes the ULTIMATE challenge: How do you maintain your startup speed as your organization grows?

The Central Problem

Every successful startup faces this paradox:

• Day 1: 3 founders in a garage → Move incredibly fast!
• Year 1: 10 employees → Still pretty fast!
• Year 3: 50 employees → Things start slowing down…
• Year 5: 200 employees → Bureaucracy everywhere! Slow as a big corporation!

The Question Eric Ries Answers: How do you grow from 5 to 500 employees WITHOUT losing the speed and agility that made you successful?

The Answer: Build an ADAPTIVE organization that can adjust its processes automatically based on current conditions!

---

The Five Whys: Root Cause Analysis

Eric Ries introduces the most powerful tool for building adaptive organizations: The Five Whys! This technique comes from Toyota and helps you dig deep to find the ROOT CAUSE of any problem!

What is The Five Whys?

The Concept: When a problem occurs, ask “Why?” five times to get to the root cause!

Why Five Times?

• First “Why” → Usually reveals a symptom
• Second “Why” → Gets a bit deeper
• Third “Why” → Starting to see the real issue
• Fourth “Why” → Getting close to root cause
• Fifth “Why” → Usually hits the ROOT CAUSE!

Eric’s Example from IMVU:

Problem: A new feature caused the website to crash!

Question 1: Why did the website go down?
Answer: A database query in the new feature was poorly written.

Question 2: Why was the query poorly written?
Answer: The engineer who wrote it didn’t know how to write efficient database queries.

Question 3: Why didn’t the engineer know how to write efficient queries?
Answer: He had never been trained in database optimization.

Question 4: Why had he never been trained?
Answer: We don’t have a training program for new engineers.

Question 5: Why don’t we have a training program?
Answer: We’ve been growing so fast that we prioritized hiring over training!

ROOT CAUSE IDENTIFIED: Lack of systematic training for new engineers!

The Solution: Don’t just fix the bad query! Create a training program so this never happens again!

☕ Hamed’s Analysis: Why Most Companies Stop at “Why #1”

When I teach Five Whys to Iranian startups, I see the same pattern:

The Typical Response:

• Problem happens
• Team asks “Why?” ONCE
• Finds surface-level cause
• Applies quick fix
• Same problem happens again next month!

Real Example – E-commerce Startup:

Problem: Customer complained that their order was delayed!

Typical Response (Asking Why Only Once):

• Question: Why was the order delayed?
• Answer: The warehouse staff forgot to ship it.
• “Solution”: Tell the warehouse staff to be more careful!
• Result: Same problem happens again the next week!

Five Whys Approach (What I Made Them Do):

Why #1: Why was the order delayed?
The warehouse staff forgot to ship it.

Why #2: Why did they forget?
The order wasn’t on their packing list.

Why #3: Why wasn’t it on the packing list?
The order management system didn’t send it to the warehouse system.

Why #4: Why didn’t the system send it?
There’s a bug that prevents orders placed after 6 PM from syncing until the next morning.

Why #5: Why does this bug exist?
When we added the warehouse integration, we didn’t test late-night orders!

ROOT CAUSE: Inadequate testing procedures for system integrations!

Real Solution:

• Fixed the bug
• Added automated tests for 24-hour order flow
• Created a checklist for all future integrations
• Problem NEVER happened again!

Key lesson: Don’t treat symptoms! Dig until you find the ROOT CAUSE!

---

Proportional Investment: The Secret to Adaptive Organizations

Here’s where Eric Ries reveals the GENIUS of Five Whys: It’s not just about finding problems – it’s about making proportional investments in prevention!

The Proportional Investment Rule

Eric’s Formula: For every problem that occurs, invest time proportional to the severity of the problem in preventing it from happening again!

How It Works:

Small Problem:

• A minor bug affects 10 users
• Takes 1 hour to fix
• Investment: Spend 1 hour writing a test to prevent it!

Medium Problem:

• A feature causes crashes for 1,000 users
• Takes 1 day to fix
• Investment: Spend 1 day improving your testing process!

Major Problem:

• The entire site goes down for 4 hours
• Costs $100,000 in lost revenue
• Investment: Spend 1 week building better monitoring and alerting systems!

Why This is BRILLIANT:

• Small problems → Small investments in prevention (not overwhelming!)
• Big problems → Big investments in prevention (totally justified!)
• The organization AUTOMATICALLY adapts to its most critical problems!

Example: How IMVU Used Proportional Investment

The Situation at IMVU:

They were deploying 50 times per day (as we learned in Chapter 9). Sometimes deployments broke things!

Traditional Response:

• Every time something breaks → Panic!
• Add more approval processes
• Slow down deployments
• Eventually, you’re only deploying once per month!

IMVU’s Five Whys Response:

Problem: A deployment broke the login system!

Five Whys Analysis:

1. Why did login break? A code change altered the authentication flow.
2. Why wasn’t this caught in testing? We didn’t have a test for that specific login scenario.
3. Why didn’t we have that test? The engineer didn’t know that scenario needed testing.
4. Why didn’t they know? We don’t have documentation of critical user flows.
5. Why don’t we have documentation? We’ve never prioritized creating it!

Proportional Investment:

• Fixed the immediate bug (2 hours)
• Added test for that login scenario (2 hours)
• Documented the 10 most critical user flows (1 day)
• Made it a rule: Before deploying changes to these flows, check the documentation! (ongoing)

Result: Login-related bugs decreased by 80%! And they could STILL deploy 50 times per day!

Eric’s insight: “We didn’t slow down to prevent problems – we got SMARTER about preventing them!”

☕ Hamed’s Real Example: Iranian Fintech Startup

Let me share a PERFECT example of proportional investment in action:

Client: Mobile Wallet App

Problem #1 (Minor): A user couldn’t update their profile picture.

Traditional Response:

• Fix the bug
• Move on

My Five Whys Session:

1. Why couldn’t they update it? The image upload function timed out.
2. Why did it time out? Their image was 10MB (too large!).
3. Why did we allow 10MB uploads? We never set a file size limit.
4. Why no limit? The developer didn’t think about it.
5. Why didn’t they think about it? We don’t have design specifications for file uploads!

Proportional Investment:

• Fixed the bug (30 minutes)
• Added file size validation (30 minutes)
• Created a guideline document for file uploads (1 hour)
• Total investment: 2 hours for a minor problem ✓

Problem #2 (Major): A bug caused incorrect transaction amounts for 500 users!

Traditional Response:

• Fix the bug
• Manually correct 500 transactions
• Apologize to users
• Hope it doesn’t happen again!

My Five Whys Session:

1. Why were amounts incorrect? A rounding error in the currency conversion code.
2. Why wasn’t this caught? We don’t have automated tests for currency conversions.
3. Why no tests? The finance module is “too complex to test” (engineer’s excuse!).
4. Why is it too complex? The code wasn’t designed with testability in mind.
5. Why not? We don’t have coding standards that require testable code!

Proportional Investment:

• Fixed the bug (4 hours)
• Corrected all affected transactions (6 hours)
• Wrote comprehensive tests for currency module (3 days)
• Refactored currency code for better testability (1 week)
• Created company-wide coding standards (2 weeks)
• Trained all engineers on the new standards (1 week)
• Total investment: 1 month for a MAJOR problem ✓

Results:

• Currency bugs: ZERO in the next 12 months!
• Overall code quality improved
• Engineers became better at writing testable code
• Customer trust increased (no more transaction errors!)

The key insight: Minor problems deserve minor investments. Major problems deserve major investments. This is how you build an adaptive organization!

---

Avoiding the Blame Game: Creating a Culture of Learning

Eric Ries addresses the BIGGEST challenge with Five Whys: How do you prevent it from turning into a witch hunt?

The Five Whys Trap: Blaming People

The Problem:

When you ask “Why?” repeatedly, you ALWAYS end up at a person!

Example:

1. Why did the feature break? The code had a bug.
2. Why was there a bug? The engineer made a mistake.
3. Why did the engineer make a mistake? They weren’t careful enough.
4. Why weren’t they careful? They’re lazy/incompetent!
5. Conclusion: Fire the engineer! ❌

This is WRONG and TOXIC!

Eric’s Rule: The Five Whys should NEVER result in blaming a person! Instead, it should reveal SYSTEMIC problems!

How to Do Five Whys Correctly:

Wrong approach: “Why did SARAH make this mistake?”

Right approach: “Why did our SYSTEM allow this mistake to happen?”

Reframing the Questions:

1. Why did the feature break? The code had a bug.
2. Why was there a bug? The code wasn’t reviewed before deployment.
3. Why wasn’t it reviewed? We don’t have a code review process for this module.
4. Why don’t we have a process? We haven’t documented which modules need mandatory reviews.
5. Why haven’t we documented it? We lack a system for identifying high-risk code areas!

Solution: Create a risk assessment system for code changes! ✓

Notice the difference? We went from “blame Sarah” to “improve our system!”

Eric’s Rule: Make the Person Who Caused the Problem Lead the Five Whys!

This is COUNTERINTUITIVE but BRILLIANT!

Why This Works:

Traditional approach:

• Engineer breaks something
• Manager conducts Five Whys
• Engineer feels defensive and blamed
• Toxic culture develops!

Eric’s approach:

• Engineer breaks something
• THAT SAME ENGINEER leads the Five Whys session!
• Engineer takes ownership of finding the root cause
• Engineer proposes systemic improvements
• Learning culture develops! ✓

The Psychology:

• People are less defensive when they’re in control
• Engineers become invested in preventing future problems
• The whole team learns together!

Eric’s Example from IMVU:

When an engineer deployed code that crashed the site, Eric asked THAT ENGINEER to:

• Lead the Five Whys session
• Identify the root cause
• Propose preventive measures
• Implement those measures!

Result:

• The engineer felt empowered (not blamed!)
• They came up with better solutions than management would have!
• They became the company’s champion for deployment safety!

Eric’s insight: “Transform the person who caused the problem into the person who solves it!”

☕ Hamed’s Experience: Implementing Blame-Free Five Whys

Let me share how I helped an Iranian startup implement this!

Client: SaaS Company (30 employees)

Their Culture Before Five Whys:

• When something broke → Find who did it
• Public shaming in team meetings
• Engineers terrified of making mistakes
• Innovation stalled (everyone played it safe!)

The Transformation Process:

Step 1: Set the Ground Rules

I made the CEO announce these rules to the ENTIRE company:

• “We will never fire someone for making an honest mistake”
• “Every problem is a learning opportunity”
• “The person involved in the problem will lead the analysis”
• “We focus on fixing SYSTEMS, not blaming PEOPLE”

Step 2: The First Five Whys Session

Problem: A junior developer accidentally deleted a production database table!

Traditional Response: Fire the junior developer! ❌

My Response: Let the junior developer lead the Five Whys! ✓

The Session:

(I facilitated, but the junior developer asked the questions!)

1. Why was the table deleted? I ran a DELETE command on the wrong database.
2. Why did you run it on the wrong database? Production and staging databases look identical in the admin panel.
3. Why do they look identical? We use the same admin tool for both environments.
4. Why don’t we have visual differentiation? No one thought to add it when we set up the tool.
5. Why didn’t anyone think of it? We don’t have a checklist for setting up admin tools safely!

The Junior Developer’s Proposed Solutions:

• Add color coding: Production = RED, Staging = GREEN
• Require typing “CONFIRM” before any DELETE command in production
• Create a database operations checklist
• Schedule monthly training on database safety

CEO’s Response: “These are EXCELLENT ideas! Let’s implement all of them!”

Results After 6 Months:

• ZERO production database incidents!
• The junior developer became the team’s database safety expert!
• Engineers felt SAFE to experiment and innovate!
• Product development speed increased 3X!

The lesson I told the CEO: “That ‘mistake’ cost you 4 hours of downtime. But firing that developer would have cost you a year of fear and slow innovation. Instead, you gained a safety expert and a culture of learning!”

---

End of Part 1

In Part 2, we’ll cover: The Five Whys Meeting Format, Common Pitfalls and How to Avoid Them, Speed vs. Quality (Finding the Right Balance), Adaptive Organizations at Scale, and Real-World Examples of Companies Using Five Whys!

 

🔧 Chapter 11: Adapt – PART 2A

---

The Five Whys Meeting: A Step-by-Step Framework

Eric Ries provides a detailed framework for conducting effective Five Whys meetings. This isn’t just theory – it’s a practical playbook!

The Five Whys Meeting Format

When to Hold a Five Whys Meeting:

Trigger Events:

• Production outage or major bug
• Customer complaint about a systemic issue
• Missed deadline or project failure
• Repeated problems in the same area
• ANY problem where you want to prevent recurrence!

Timing: Hold the meeting SOON after the problem (within 24-48 hours while details are fresh!)

Who Should Attend:

• The person(s) most directly involved with the problem (they lead!)
• Their immediate manager
• Anyone with relevant technical knowledge
• A facilitator (usually someone senior who keeps discussions productive)
• Keep it small: 5-8 people maximum!

The Meeting Structure:

Step 1: State the Problem Clearly (5 minutes)

• What happened?
• When did it happen?
• What was the impact?
• Write it down where everyone can see it!

Step 2: Ask the Five Whys (20-30 minutes)

• Start with “Why did this problem occur?”
• For each answer, ask “Why?” again
• Write down EVERY answer!
• Keep going until you hit a ROOT CAUSE (usually around the 5th Why)

Step 3: Identify Proportional Investments (10 minutes)

• Based on the severity, how much time should we invest in prevention?
• What specific actions will address the root cause?
• Assign owners and deadlines!

Step 4: Follow Up (Ongoing)

• Track the preventive actions
• Verify they were completed
• Measure whether similar problems decreased!

Eric’s Real Example: IMVU’s Five Whys Meeting

The Problem: The site went down for 15 minutes due to a database query timing out!

Meeting Participants:

• The engineer who wrote the query (leads the meeting)
• The database administrator
• The product manager
• Eric Ries (as facilitator)

The Five Whys Session:

Why #1: Why did the site go down?
Answer: A database query for the user profile page took 30 seconds to execute, causing timeouts.

Why #2: Why did the query take 30 seconds?
Answer: The query was scanning millions of rows instead of using an index.

Why #3: Why wasn’t it using an index?
Answer: The necessary index doesn’t exist on that table.

Why #4: Why doesn’t the index exist?
Answer: When we added the new feature, we didn’t analyze the query performance.

Why #5: Why didn’t we analyze query performance?
Answer: We don’t have a standard process for performance testing before deployment!

ROOT CAUSE: Lack of performance testing in the deployment process!

Proportional Investment (Problem caused 15 minutes of downtime):

• Immediate: Add the missing index (30 minutes)
• Short-term: Analyze and optimize all existing slow queries (1 day)
• Long-term: Create automated performance tests that run before every deployment (3 days)
• Document query performance standards (1 day)

Total Investment: About 1 week of work to prevent future performance issues!

Result: Database-related outages dropped by 90% over the next 6 months!

☕ Hamed’s Meeting Template for Iranian Startups

I’ve run hundreds of Five Whys meetings. Here’s my tested template:

The “Five Whys Meeting Agenda” Template:

PART 1: Problem Statement (5 min)

• What happened? [Describe the problem in one sentence]
• When? [Date and time]
• Impact? [Number of users affected, revenue lost, time wasted, etc.]
• Current Status? [Is it fixed? Partially fixed? Still broken?]

PART 2: The Five Whys (20-30 min)

[Person who was involved leads this section!]

• Why #1: Why did this problem occur?
  Answer: _______________
• Why #2: Why did [answer #1] happen?
  Answer: _______________
• Why #3: Why did [answer #2] happen?
  Answer: _______________
• Why #4: Why did [answer #3] happen?
  Answer: _______________
• Why #5: Why did [answer #4] happen?
  Answer: _______________

ROOT CAUSE: _______________

PART 3: Proportional Investment (10 min)

Severity Assessment:

• ☐ Minor (affected < 10 users or < 1 hour of impact)
• ☐ Medium (affected 10-100 users or 1-8 hours of impact)
• ☐ Major (affected 100+ users or > 8 hours of impact)

Preventive Actions:

1. Immediate fix: [What needs to be done right now?]
   Owner: ___ | Deadline: ___
2. Short-term prevention: [What can we do this week?]
   Owner: ___ | Deadline: ___
3. Long-term prevention: [What systemic improvements are needed?]
   Owner: ___ | Deadline: ___

PART 4: Follow-Up (Ongoing)

• Next Review Date: _______________
• Success Metric: [How will we know this worked?]

Pro Tip: I require my clients to keep a “Five Whys Log” – a shared document where all sessions are recorded. This creates institutional knowledge and prevents repeating the same root cause analysis!

---

Common Pitfalls and How to Avoid Them

Eric Ries warns about common mistakes teams make when implementing Five Whys. Learn from others’ failures!

Pitfall #1: The Blame Game

The Problem: Five Whys turns into “Who screwed up?”

Warning Signs:

• Questions focus on people instead of processes
• “Why did John make this mistake?” (WRONG!)
• People become defensive and stop participating
• Team morale drops

How to Avoid:

• Reframe questions: “Why did our SYSTEM allow this mistake?”
• Have the person involved LEAD the session (they can’t blame themselves!)
• If someone tries to blame a person, interrupt and redirect!
• Focus on: “What can we change to prevent this?”

Eric’s Rule: If anyone leaves a Five Whys meeting feeling blamed or attacked, you did it WRONG!

Pitfall #2: Stopping Too Early

The Problem: Teams stop at the first or second “Why” and miss the root cause!

Example of Stopping Too Early:

Problem: Customer data was lost!

Why #1: Why was data lost?
Answer: The backup system failed.

“Solution”: Fix the backup system! ❌

This is TOO SHALLOW! Keep asking Why!

Why #2: Why did the backup system fail?
Answer: The backup server ran out of disk space.

Why #3: Why did it run out of space?
Answer: Old backups weren’t being deleted automatically.

Why #4: Why weren’t they being deleted?
Answer: The cleanup script wasn’t configured.

Why #5: Why wasn’t it configured?
Answer: We don’t have a checklist for setting up new servers!

REAL ROOT CAUSE: Lack of server setup procedures!

Real Solution: Create a comprehensive server setup checklist! ✓

How to Avoid:

• Always ask AT LEAST 5 Whys (sometimes you need 6 or 7!)
• Keep asking until you hit something SYSTEMIC
• If the answer is a simple task, you’re not deep enough!

Pitfall #3: Disproportionate Responses

The Problem: Over-investing or under-investing in prevention!

Example of OVER-investing:

Minor Bug: A typo in an error message affected 5 users for 10 minutes.

Disproportionate Response:

• Implement a 10-person approval process for all error messages
• Hire a dedicated “Error Message Quality Assurance Team”
• Create a 50-page style guide for error messages

Cost: Thousands of dollars and weeks of work for a trivial issue! ❌

Proportionate Response:

• Fix the typo (5 minutes)
• Add error messages to the spell-check process (15 minutes)

Cost: 20 minutes! ✓

Example of UNDER-investing:

Major Issue: A security breach exposed 10,000 user passwords!

Disproportionate Response:

• Reset the passwords
• Send an apology email
• Move on

This is NEGLIGENT! ❌

Proportionate Response:

• Immediate password reset and user notification
• Complete security audit (1-2 weeks)
• Implement encryption for passwords
• Hire a security consultant for ongoing audits
• Train all engineers on security best practices
• Implement automated security testing

Cost: Significant time and money, but ABSOLUTELY JUSTIFIED for this severity! ✓

How to Avoid:

• Before deciding on actions, assess severity objectively
• Ask: “What’s the realistic worst-case if this happens again?”
• Match your investment to the risk!

📄 Continue to Part 2B for Speed vs. Quality, Scaling, and Real-World Examples…

 

🚀 Chapter 11: Adapt – PART 2B

---

Speed vs. Quality: The Counterintuitive Truth

One of the biggest debates in startups is: Should we move fast or focus on quality? Eric Ries argues this is a FALSE DICHOTOMY!

Eric’s Radical Claim: Quality Enables Speed!

The Traditional View (WRONG!):

• “We need to move fast, so we can’t worry about quality!”
• “Quality slows us down – we’ll fix technical debt later!”
• “Testing and processes are for big companies, not startups!”

The Lean Startup Truth:

Quality systems don’t slow you down – they ACCELERATE you by preventing problems that would force you to stop and fix things!

Eric’s Evidence from IMVU:

Before Quality Systems:

• Deployments took 4 hours
• Frequent outages (2-3 per week)
• Engineers spent 40% of time fixing bugs
• Customer complaints were high
• Team morale was low

After Implementing Quality Systems:

• Deployments took 20 minutes (automated!)
• Outages dropped to < 1 per month
• Engineers spent 10% of time on bugs
• Customer satisfaction increased
• Team could ship 50+ times per day!

The Quality Systems They Built:

1. Automated Testing: Every code change runs through 1000+ tests automatically
2. Continuous Integration: Code is integrated and tested constantly
3. Instant Rollback: If something breaks, one button rolls back instantly
4. Monitoring & Alerts: Problems are detected within seconds
5. Five Whys Process: Every problem is analyzed to prevent recurrence

Result: IMVU became one of the FASTEST shipping companies in the world, with HIGHER quality than most competitors!

☕ Hamed’s Speed vs. Quality Framework

I’ve seen Iranian startups struggle with this constantly. Here’s my framework:

The Four Stages of Speed & Quality:

Stage 1: Chaos (Most Early Startups)

• Speed: Slow (despite trying to go fast!)
• Quality: Poor
• Characteristics: No tests, no processes, constant firefighting
• Why it feels fast: You’re always “doing” something!
• Why it’s actually slow: 50% of time is spent fixing yesterday’s problems!

Stage 2: Process Hell (Misguided “Quality” Focus)

• Speed: Very Slow
• Quality: Moderate
• Characteristics: Too many meetings, approvals, bureaucracy
• The mistake: Copying big company processes without automation!

Stage 3: Smart Quality (Where You Want to Be!)

• Speed: Fast
• Quality: High
• Characteristics: Automated testing, Five Whys, continuous deployment
• The key: Quality is built into the SYSTEM, not manual checks!

Stage 4: Over-Engineered (Rare in Startups)

• Speed: Moderate
• Quality: Excessive
• Characteristics: Gold-plating everything, premature optimization
• The problem: Building for problems you don’t have yet!

Goal: Get to Stage 3 as fast as possible!

My Recommendation for Iranian Startups:

Month 1-3: Accept Stage 1 chaos, but start building ONE quality system (usually automated testing)

Month 4-6: Add monitoring and the Five Whys process

Month 7-12: Implement continuous deployment and automated quality checks

After Year 1: You should be solidly in Stage 3!

---

Adaptive Speed Regulation

Here’s the magic of Five Whys: It automatically regulates your speed based on quality!

How Five Whys Creates Adaptive Speed

The Concept:

When quality is LOW (lots of problems):

• You hold MORE Five Whys meetings
• These meetings identify MORE systemic investments needed
• Your team spends MORE time on quality improvements
• This FORCES you to slow down and fix foundations!

When quality is HIGH (few problems):

• You hold FEWER Five Whys meetings
• Less time is spent on preventive investments
• Your team can focus MORE on new features
• You naturally SPEED UP!

This is SELF-REGULATING!

The system automatically balances speed and quality based on real feedback!

Real Example: IMVU’s Adaptive Speed

Scenario 1: High-Quality Period

Month: March 2009

Problems Encountered:

• 2 minor bugs
• 0 outages
• 1 customer complaint

Five Whys Meetings: 1 meeting (30 minutes total)

Preventive Investments: 2 hours of work

Time Available for New Features: 99% of engineering time!

Result: Shipped 47 features that month! 🚀

Scenario 2: Low-Quality Period

Month: June 2009 (after a major architecture change)

Problems Encountered:

• 15 bugs
• 3 outages
• 20 customer complaints

Five Whys Meetings: 8 meetings (4 hours total)

Preventive Investments Identified:

• Refactor the new architecture (40 hours)
• Add more automated tests (20 hours)
• Improve monitoring (10 hours)

Time Available for New Features: 60% of engineering time

Result: Shipped only 12 features BUT fixed underlying problems!

Scenario 3: Return to High Quality

Month: July 2009

Problems Encountered:

• 3 minor bugs
• 0 outages
• 2 customer complaints

Five Whys Meetings: 2 meetings

Result: Back to shipping 40+ features per month! 🎉

The Pattern: Five Whys automatically slowed them down when quality dropped, then sped them back up once quality was restored!

☕ Hamed’s Real Example: Food Delivery App

Background: A Tehran-based food delivery startup I consulted with was struggling with speed.

The Situation When I Arrived (Month 1):

• Shipping 1-2 features per week (slow!)
• BUT: 10-15 bugs reported per week
• Customer complaints were through the roof
• Engineers working 70+ hours per week
• CEO frustrated: “Why are we so slow?!”

What I Implemented:

Week 1: Introduced Five Whys meetings for every problem

Result: They held 8 Five Whys meetings in the first week!

Root Causes Discovered:

• No automated testing (every deploy broke something)
• No staging environment (testing in production!)
• No code reviews (quality issues not caught early)
• Database queries weren’t optimized

Month 2-3: The “Slowdown”

Following proportional investment, they spent:

• 40% of time building automated tests
• 30% of time setting up proper deployment pipeline
• 20% of time on code review process
• Only 10% on new features!

CEO’s Reaction: “Hamed, we’re even SLOWER now!”

My Response: “Trust the process. This is TEMPORARY investment.”

Month 4-6: The Payoff

Problems Dropped:

• Bugs: From 15/week to 2/week
• Outages: From 3/week to 1/month
• Customer complaints: Down 80%

Five Whys Meetings: Down to 1-2 per week

Feature Velocity: Now shipping 8-10 features per week!

This is 4-5X FASTER than before! 🚀

Additional Benefits:

• Engineers working normal 45-hour weeks
• Team morale dramatically improved
• Customer satisfaction scores up 60%
• Less stress for everyone!

The Lesson: Five Whys made them SLOW DOWN initially to fix foundations, then enabled them to SPEED UP dramatically!

---

Scaling Five Whys: From Small Teams to Large Organizations

Eric Ries addresses a common question: How do you scale Five Whys as your company grows?

Scaling Five Whys: The Framework

Stage 1: Small Team (1-10 people)

• Frequency: Hold Five Whys for EVERY problem
• Participants: Everyone attends (builds the muscle!)
• Duration: 30 minutes per meeting
• Documentation: Simple notes in a shared doc

Stage 2: Growing Company (10-50 people)

• Frequency: Five Whys for significant problems only
• Participants: Relevant team members + one senior leader
• Duration: 30-45 minutes
• Documentation: Dedicated Five Whys log with follow-ups tracked
• Training: New hires learn the process in onboarding

Stage 3: Mid-Size Company (50-200 people)

• Frequency: Each team conducts their own Five Whys
• Coordination: Monthly cross-team Five Whys review
• Documentation: Structured database of Five Whys sessions
• Metrics: Track number of problems, root causes, recurrence rates
• Training: Dedicated Five Whys facilitators in each department

Stage 4: Large Company (200+ people)

• Decentralization: Each department runs Five Whys independently
• Executive Review: Quarterly review of systemic patterns
• Tooling: Dedicated software for tracking Five Whys
• Culture: Five Whys is part of company DNA

☕ Hamed’s Scaling Advice for Iranian Startups

Most Iranian startups won’t reach 200+ people for years, so here’s practical advice for the early stages:

When You’re 1-5 People:

• Hold Five Whys as a team for EVERY bug or problem
• This builds the habit and trains everyone
• Takes 15-20 minutes per session
• Document in a simple Google Doc

When You’re 5-20 People:

• Start filtering: Only hold Five Whys for problems that affect multiple people OR repeat more than once
• Create a simple template (use mine from earlier!)
• Assign one person as “Five Whys Champion” to facilitate
• Review the Five Whys log monthly in all-hands meetings

When You’re 20-50 People:

• Split into teams (Product, Engineering, Sales, etc.)
• Each team conducts their own Five Whys
• Hold monthly cross-team sessions for systemic issues
• Start tracking metrics: problems per month, root cause categories, resolution rates

Critical Rule: Don’t over-complicate! The beauty of Five Whys is its SIMPLICITY. Keep it lightweight until you’re forced to add structure!

---

Chapter 11 Summary: Building an Adaptive Organization

🎯 The Core Principles

1. Five Whys is Your Root Cause Tool

• Ask “Why?” five times to dig to systemic root causes
• Prevents treating symptoms instead of diseases
• Builds institutional knowledge over time

2. Proportional Investment is Critical

• Match prevention effort to problem severity
• Don’t over-invest in trivial issues
• Don’t under-invest in serious problems

3. Create a Blame-Free Culture

• Have the involved person LEAD the Five Whys
• Focus on fixing SYSTEMS, not punishing PEOPLE
• Build psychological safety

4. Quality Enables Speed

• Automated testing speeds you up, not down
• Good processes prevent problems that would slow you down
• IMVU shipped 50x per day WITH high quality!

5. Five Whys is Self-Regulating

• More problems → More Five Whys → More quality investment → Slow down temporarily
• Fewer problems → Fewer Five Whys → More feature work → Speed up!
• The system automatically balances speed and quality

6. Start Simple, Scale Gradually

• Begin with basic Five Whys meetings
• Add structure only as you grow
• Don’t over-engineer the process

📋 Your Action Plan

This Week:

1. The next time a problem occurs, hold a Five Whys meeting using the template
2. Focus on finding the ROOT CAUSE, not just the surface issue
3. Assign clear owners and deadlines for preventive actions

This Month:

1. Hold Five Whys sessions for 3-5 problems
2. Start a “Five Whys Log” to track sessions and outcomes
3. Train your team on the process

This Quarter:

1. Make Five Whys a regular part of your culture
2. Start building automated quality systems based on root causes discovered
3. Measure the impact: Are problems decreasing? Is velocity increasing?

---

✅ End of Chapter 11: Adapt

Ready to move on to Chapter 12: Innovate? 🚀