The First Number Wins
When you're asked to estimate something — how long a feature will take, how much traffic a system can handle, how many servers you need — the first number you encounter disproportionately influences your final answer. This is anchoring bias. Your brain treats the first piece of information as a reference point and adjusts insufficiently from it, even when that first number was arbitrary, uninformed, or stated casually.
How It Manifests in Engineering
- Sprint planning: A product manager says "This seems like a 3-point story." Even if the engineer thinks it's more complex, they're now anchored at 3. They might negotiate up to 5, but the true complexity might warrant an 8. The PM's casual comment — made without technical knowledge — has just shaped the team's delivery commitment.
- Capacity planning: "The old system handled 1,000 RPS." The new system is fundamentally different, but every estimate starts from 1,000 and adjusts. The actual capacity might be 200 RPS or 10,000 RPS — the anchor prevents accurate estimation from first principles.
- Incident timelines: "We should have this fixed in 30 minutes." That number, once spoken, becomes the expectation. Two hours later, stakeholders are frustrated — not because two hours is unreasonable for the actual problem, but because it's far from the anchor.
- Salary negotiation: The first number mentioned in a compensation discussion anchors the entire negotiation range. Whoever names a number first sets the frame.
The Fix — Process Patches
- Blind Estimation: In planning poker or estimation sessions, have everyone write down their estimate before anyone speaks. This prevents the first voice from anchoring the room. Tools like Planning Poker apps enforce this by hiding estimates until all are submitted simultaneously.
- Estimate in Ranges: Instead of "This will take 3 weeks," say "Best case: 2 weeks. Expected: 4 weeks. Worst case: 8 weeks." Ranges resist anchoring because they force consideration of multiple scenarios and make uncertainty explicit rather than hidden inside a false-precision single number.
- Reference Class Forecasting: Instead of estimating from scratch (where anchoring thrives), look at how long similar past projects actually took. "The last three features of comparable complexity took 4, 6, and 5 weeks. So our base estimate is 5 weeks." Historical data is a better anchor than gut feeling or a stakeholder's wishful thinking.
- Separate Estimation from Discussion: When a stakeholder asks "How long will this take?" in a meeting, the correct answer is "Let me estimate independently and get back to you by end of day." Estimating in real-time, in response to an anchor, is the highest-risk scenario.
If asked "How do you handle estimation in your team?" describe anchoring bias explicitly. Say: "We use blind estimation — everyone submits a number before discussion — because the first number spoken in a room anchors everyone else's thinking, even experienced engineers. When estimates diverge significantly, that divergence is itself valuable information: it means team members have different mental models of the problem, and we need to surface and resolve that disagreement before committing to a timeline." This demonstrates process maturity beyond "we use story points."
Key Point: Anchoring is especially dangerous in cross-functional meetings where a non-technical stakeholder casually says "This should be quick, right?" That throwaway comment anchors the entire room. Senior engineers learn to say "Let me estimate independently and get back to you" rather than reacting to an anchor in real-time. The discipline to defer estimation is not indecisiveness — it's accuracy.