Anchoring & Survivorship Bias

Anchoring and survivorship bias are two cognitive biases that distort engineering decisions in predictable, measurable ways. Anchoring means the first number you encounter disproportionately influences your subsequent estimates, even when that number is irrelevant. Survivorship bias means you study the winners and ignore the losers, leading to distorted conclusions about what causes success. Both are pervasive in engineering culture and both have concrete antidotes.

Anchoring

Anchoring was first demonstrated by Tversky and Kahneman in 1974. They showed that even random numbers influence subsequent estimates. When people were asked to estimate the percentage of African countries in the United Nations after spinning a wheel that landed on either 10 or 65, those who saw 65 estimated significantly higher than those who saw 10. The number on the wheel was completely irrelevant, but it anchored their thinking.

The anchoring effect in estimation:

  Setup: "I think this should take about 2 weeks."
  (Said by a manager in a planning meeting)

  Without the anchor:
    Engineer A estimates: 6 weeks
    Engineer B estimates: 5 weeks
    Engineer C estimates: 8 weeks
    Average: 6.3 weeks

  With the anchor ("2 weeks"):
    Engineer A estimates: 3 weeks
    Engineer B estimates: 4 weeks
    Engineer C estimates: 3.5 weeks
    Average: 3.5 weeks

  The anchor pulled every estimate toward it.
  Nobody wants to say "8 weeks" when the manager said "2 weeks."
  The true estimate (6+ weeks) never surfaces.

How Anchoring Shows Up in Engineering

Sprint planning:
  Tech lead says: "This looks like a 3-point story"
  Team anchors on 3, estimates cluster around 2-5
  Without the anchor, estimates might range from 3-13

  Fix: Use planning poker where everyone reveals
  simultaneously. No anchoring from early speakers.

Salary negotiation:
  First number on the table anchors the negotiation.
  Recruiter: "The range is $120K-$150K"
  Candidate now negotiates within that range,
  even if market rate is $170K.

  Fix: Research market rates independently before
  hearing any offer. Your research becomes your anchor.

Project proposals:
  Previous similar project took 3 months.
  New project is more complex but the team anchors on 3 months.
  Actual complexity warrants 6-9 months.

  Fix: Estimate from first principles without referencing
  the previous project timeline. Compare afterward.

Performance targets:
  "Last quarter we achieved 99.5% uptime"
  Team anchors on 99.5% for next quarter target.
  But the business actually needs 99.99%.
  The historical number anchors the target too low.

Anchoring in Technical Design

Database capacity:
  "The current table has 10M rows"
  Engineer designs for 50M rows (5x current)
  Actual growth over 3 years: 500M rows (50x)

  The current size anchored the capacity plan.
  Better: Project growth from the growth rate,
  not from the current absolute number.

API rate limits:
  "Other APIs use 100 requests per minute"
  Team sets limit at 100 rpm without analyzing
  their actual traffic patterns.

  The "other APIs" number is an irrelevant anchor.
  Better: Analyze your traffic distribution and
  set limits based on your infrastructure capacity.

Infrastructure sizing:
  "The staging environment uses 4 CPUs and 8GB RAM"
  Production is sized at 8 CPUs and 16GB (2x staging)
  Actual production load requires 32 CPUs and 64GB

  Staging specs anchored production sizing.
  Better: Load test to determine actual requirements.

De-Anchoring Techniques

1. Estimate before you hear anyone else's number
   Write your estimate down before the meeting.
   Compare afterward.

2. Use independent estimation
   Have 3 engineers estimate separately, then combine.
   Planning poker enforces this.

3. Estimate from first principles
   Break the work into components and estimate each.
   Do not start from a total number and adjust.

4. Use multiple reference points
   "Similar project A took 3 months, but similar project
   B took 8 months. The range is 3-8 months."
   Multiple anchors dilute the effect of any single anchor.

5. Explicitly challenge the anchor
   "The manager said 2 weeks. Let us ignore that and
   estimate as if nobody had said a number."

Survivorship Bias

Survivorship bias occurs when you draw conclusions from a dataset that only includes successes, ignoring the failures that did not survive to be observed. It is one of the most common reasoning errors in technology decision-making.

The classic example: during World War II, the military examined returning bomber aircraft for bullet holes and planned to armor the most-hit areas. Abraham Wald pointed out the error: the planes that returned were the survivors. The planes that did not return were hit in different places — the places where bullet holes were fatal. You should armor the areas with NO bullet holes on surviving planes, because those are the areas where hits are fatal.

Survivorship bias in tech:

  Observation: "Successful companies use microservices"
  (Google, Netflix, Amazon)

  Invisible data: 1000 companies that tried microservices
  and failed, pivoted back to monoliths, or went out of
  business. You never hear about them.

  Correct framing: "Some companies succeed with microservices.
  Some fail. What differentiates the winners from the losers?"

Engineering Examples of Survivorship Bias

Technology adoption:
  "Spotify uses this architecture, so we should too"

  What you see: Spotify's successful architecture
  What you do not see:
    - The 50 companies that copied Spotify's model and failed
    - Spotify's own failed experiments before this one worked
    - The context (scale, team size, culture) that made it work

  Fix: Ask "What conditions make this succeed?" and "What
  conditions make this fail?" not "Who uses this?"

Startup advice:
  "Drop out of college like Gates, Zuckerberg, and Jobs"

  What you see: 3 wildly successful dropouts
  What you do not see: Millions of dropouts who are not
  billionaires. The base rate for "dropout becomes billionaire"
  is vanishingly small.

  Fix: Look at the full distribution of outcomes, not the
  visible tail of extreme success.

Framework selection:
  "React has the most GitHub stars and the most jobs"

  What you see: React's popularity
  What you do not see:
    - Projects that chose React and regretted it
    - Teams that switched away from React
    - Use cases where React was the wrong choice
    GitHub stars measure popularity, not suitability.

  Fix: Evaluate frameworks against your specific requirements,
  not against popularity metrics that are subject to
  survivorship bias.

Survivorship Bias in Engineering Practices

Code review culture:
  "Google does thorough code reviews and ships great software"

  What you see: Google's code review process
  What you do not see:
    - Google projects that failed despite code reviews
    - Companies with light code review that ship great software
    - The cost/benefit ratio of Google's review thoroughness
      at Google's specific scale vs. your scale

Post-mortem analysis:
  "We reviewed our last 10 successful deploys. They all
   followed the standard process. The process works."

  Survivorship bias: You only looked at successes.
  What about the 3 failed deploys? Did they also follow
  the standard process? If yes, the process is not what
  differentiates success from failure.

  Fix: Study failures equally or more than successes.
  What differentiates successful outcomes from unsuccessful
  ones? That is the signal.

Hiring:
  "Our best engineers all have CS degrees from top schools"

  What you see: Your current best engineers
  What you do not see:
    - Excellent engineers you rejected because they lacked
      a CS degree
    - Engineers with CS degrees from top schools who failed
      at your company
    - The selection bias in your hiring pipeline that
      pre-filters for pedigree

  Fix: Track the performance of ALL hires, including those
  from non-traditional backgrounds. Compare outcomes, not
  credentials.

Survivorship Bias in Architecture Decisions

"Monoliths are dead. Everyone is moving to microservices."

The survivors: Companies that migrated to microservices
and are vocal about it (Netflix, Uber, Airbnb)

The invisible majority:
  - Companies that tried microservices and went back
    (Segment famously moved back to a monolith)
  - Companies that run successful monoliths quietly
    (Shopify, Basecamp, Stack Overflow)
  - Companies that failed during the migration and
    you never heard about them

The truth: Architecture choice depends on context.
Microservices solve specific problems at specific scales.
The "everyone is doing it" perception is survivorship bias.

Combining the Two Biases

Anchoring and survivorship bias often work together:

Scenario: Planning a system migration

Survivorship bias:
  "Company X completed their migration in 4 months"
  (You do not hear about the 10 companies whose
   migrations took 18 months or were abandoned)

Anchoring:
  "4 months" becomes the anchor for your estimate.
  You plan for 6 months (adding a buffer to the
  survivorship-biased anchor).
  Actual time: 14 months.

  The survivorship-biased data point anchored your
  estimate at a misleadingly low number.

Fix: Look for migration failure stories as actively
as success stories. Use the full distribution of
outcomes as your reference, not just the visible wins.

Practical Antidotes

For Anchoring

1. Blind estimation: Estimate before exposure to anchors
2. Planning poker: Simultaneous reveal prevents anchoring
3. Reference class forecasting: Use statistical base rates
   from many similar projects, not one data point
4. Range estimates: "4-12 weeks" resists anchoring better
   than "8 weeks"
5. Explicit de-anchoring: "Let us set aside that number
   and estimate from scratch"

For Survivorship Bias

1. Seek out failure stories: For every success story,
   find 3 failure stories with the same approach
2. Study the full dataset: Look at all companies that
   tried X, not just the ones that succeeded
3. Ask "what about the ones that failed?": Make this
   a standard question in architecture reviews
4. Track your own failures: Post-mortems on failed
   projects are more valuable than celebrating successes
5. Invert: Instead of "what do successful teams do?"
   ask "what do teams that fail do?" and avoid those things

Common Pitfalls

Anchoring on the first estimate you hear: In planning meetings, sprint ceremonies, and design reviews, the first number spoken anchors everyone. Use blind estimation techniques to avoid this.
Copying winners without studying losers: "Netflix uses Cassandra" is not a reason to use Cassandra. You need to know why Netflix succeeds with Cassandra AND why other companies fail with it. The difference is the signal.
Anchoring on your own past experience: "My last project took 3 months" anchors your estimate for a different project in a different context. Treat each project as its own estimation problem.
Conference talk survivorship bias: Conference speakers present their successes. Nobody gives a talk titled "How Our Microservices Migration Failed and Cost Us $2M." The conference circuit is a survivorship-biased dataset.
Anchoring on round numbers: Teams anchor on sprint boundaries (2 weeks), quarter boundaries (3 months), and year boundaries. Real work does not conform to calendar units. Estimate in days, not in sprint-shaped chunks.
Ignoring the invisible graveyard: For every visible success, there is an invisible graveyard of failures using the same approach. Train yourself to ask: "Where are the bodies?"

Key Takeaways

Anchoring: the first number you hear influences your estimate, even when it is irrelevant. Use blind estimation, planning poker, and explicit de-anchoring to counteract it.
Survivorship bias: you see the winners and not the losers, creating a distorted picture of what works. Actively seek failure stories and study the full distribution of outcomes.
In planning, separate estimation from discussion. Estimate independently first, then discuss.
For technology decisions, study failures as rigorously as successes. The difference between winners and losers is the real signal.
These biases compound when combined: a survivorship-biased data point becomes an anchor that distorts your planning.
Build team practices (blind estimation, failure analysis, pre-mortems) that structurally counteract these biases. Individual awareness is not enough.