Anchoring bias in engineering decisions: what it is and how to defeat it
Why the first opinion in any technical discussion shapes the rest, what the research says, and three concrete protocols that remove anchoring from your architecture decisions.
Anchoring bias is the tendency to over-weight the first piece of information encountered when forming a judgment. In engineering decisions, the first opinion stated frames every contribution after it. Three protocols defeat it: independent private submission (strongest), reverse seniority order, and devil's advocate rotation.
If your engineering team has a senior staff engineer who is usually right, you have a problem. Not because they are usually right — that is a feature. The problem is that once they have spoken, no one else's reasoning is independent. This is anchoring bias, and it is the single biggest cognitive failure mode in technical decision-making.
What is anchoring bias?
Anchoring is the tendency for humans to weight the first piece of information they encounter on a topic, then adjust insufficiently from it. Tversky and Kahneman first documented it in 1974 by asking subjects to estimate the percentage of African nations in the UN after spinning a wheel of fortune — subjects who saw a high spin gave higher estimates than subjects who saw a low spin, despite the spin being obviously irrelevant.
In engineering decisions, the anchor is whatever the most senior or most vocal engineer says first. Once stated, every subsequent contribution is an adjustment from that anchor. Engineers who would have started from a different premise instead start from the staff engineer's premise and tweak the edges.
This is not a junior-engineer problem. It is a humans problem. Studies have shown anchoring affects judges in sentencing decisions, doctors in diagnosis, and venture capitalists in valuations. Engineers are not magically immune.
Why is anchoring worse in distributed engineering teams?
On a co-located team, the senior engineer is one voice among several in a room. Body language, side conversations, and the social cost of agreeing too quickly all dampen the anchor.
On a distributed team, the senior engineer's anchor is a Slack message that everyone reads in isolation, with no social signal that anyone disagrees. The anchor is purer, and so it bites harder.
This is why distributed teams need explicit anti-anchoring protocols. The implicit ones do not work.
Protocol 1: Independent private submission
Before any discussion happens, every engineer submits their position privately. Nobody sees anyone else's input until they have submitted their own.
This is the gold standard. It is also the hardest to enforce in tools that were not built for it. Slack does not support it. Notion comments do not support it. A Google Doc requires honor-system discipline that real teams do not maintain under deadline pressure.
KFC enforces this by default. Other tools (Polly, decision-making frameworks like RAPID) implement it partially.
Protocol 2: Reverse seniority order
If you must run a sync meeting, ask the most junior engineer for their position first. Then the next most junior. Senior engineers speak last.
This is well-documented in the Amazon two-pizza-team playbook and Jeff Bezos's narrative memo culture. It works because the anchor is set by the most-junior reasoning, which is closer to first-principles than the senior-engineer pattern-match.
Limitation: it still produces anchoring, just from a junior anchor instead of a senior one. Better than the default, worse than independent submission.
Protocol 3: Devil's advocate rotation
Assign one engineer per decision the explicit role of arguing against the leading position, regardless of their actual view. Rotate the assignment.
This does not remove anchoring, but it forces the anchored-against-position to be articulated in full. It surfaces the costs that the converged team would have ignored.
Pairs well with Protocol 1. After independent submission, the synthesis often shows one or two dissenters. Make them the devil's advocates for the follow-up discussion if one is needed.
How do you diagnose anchoring on your team?
Three diagnostic signs: (1) your team's decisions tend to align with whoever spoke first. (2) Engineers in retros say 'I had concerns but didn't raise them.' (3) Decisions that turned out wrong have post-mortems in which someone says 'I thought about that but assumed someone smarter had checked.'
If any of these are familiar, you have an anchoring problem. The good news is that anchoring is a process problem, not a people problem — and process problems have process fixes.
The best engineering teams do not have smarter engineers than the average team. They have processes that extract the independent reasoning that already exists in every team. Defeating anchoring is the first move.