Cognitive Biases Don't Hit You Randomly

I’ve watched good engineers make bad calls. Not junior engineers finding their footing, not people being careless. Experienced, thoughtful engineers, fully engaged in the conversation. They’re arguing in good faith. They think they’re reasoning. But ask them why the estimate is what it is, or why this architecture rather than another, and what comes back isn’t a reasoned argument. It’s a feeling dressed as a position.

The absence isn’t knowledge or intelligence. It’s signal.

Everyone who’s read a book about cognitive psychology can name a dozen biases. Confirmation bias. Anchoring. The planning fallacy. The naming doesn’t help. There’s no alarm that fires when you’re inside one. Knowing that confirmation bias exists doesn’t create the real-time awareness needed to catch yourself mid-investigation, narrowing your search toward the hypothesis you already hold.

The research on debiasing is sobering. Training people about biases improves their ability to identify biases in others and in hypothetical scenarios. It does much less to change their behaviour in live situations, under time pressure, when the stakes feel real.¹ The problem isn’t information. Signal that arrives after the decision has compounded isn’t useful.

Engineering makes this worse than most fields. The feedback loops are long. You won’t know your estimate was anchored until three weeks later when the deadline arrives. You won’t know the architecture was shaped by familiarity rather than fit until six months in, when the complexity that felt manageable has become the system’s dominant characteristic. By the time you have evidence, the decision is already compounding. It’s expensive to revisit.

This is the first thing worth accepting: you will not debias yourself in real-time. The goal isn’t to be more aware in the moment. The goal is to design process friction at the moments where unawareness is most costly.

Those moments are not randomly distributed.

Cognitive biases cluster where three conditions align: cognitive load is high, information is incomplete, and social pressure is present. In engineering work, all three peak at the same predictable points in the lifecycle. The estimation meeting. The architecture debate. The code review. The incident bridge. These aren’t just stages in a process. They’re the places where the highest-cost decisions are made under exactly the conditions that make bias hardest to catch.

Start with estimation. Most teams know their estimates are consistently optimistic, and most teams keep producing optimistic estimates anyway. The individual engineer sitting in the room often knows from experience that features like this take longer than they feel, and still gives the optimistic number, and believes it while saying it.

Three biases are running in the same direction at once. Anchoring:² whoever says a number first shapes every subsequent estimate in the room. The adjustment from an anchor is almost always insufficient. Everyone moves toward accuracy, but not far enough. The inside view, which Kahneman called the planning fallacy:³ we estimate this specific task as though it’s unique, rather than drawing on a reference class of similar work. The specific always feels different from the general, which means every estimate feels more favourable than the base rate justifies. And optimism bias trims any upward correction that survives the first two: we weight the good scenario more than the evidence warrants.

The interventions that work address the conditions, not the biases themselves. Written estimates before group discussion, so no anchor is spoken before everyone has committed a number. Pre-mortems:⁴ before the project starts, write the story of how it failed. Not to be pessimistic but to recruit the planning fallacy against itself; it’s much easier to construct a vivid failure scenario than to reason from base rates. Reference class: not “how long will this take?” but “how long have similar things actually taken, in this team, in this codebase?”

The architecture debate has a different character. The biases here aren’t compounding toward the same outcome. They’re amplifying each other through a different mechanism.

Complexity bias is the tendency to find sophisticated solutions more convincing than simple ones. It’s particularly acute in technical rooms, where complexity signals competence and simplicity can read as naivety. The engineer who proposes the boring option is implicitly suggesting the problem isn’t interesting enough to deserve an interesting solution. The social cost of that is real. This means that in most architecture discussions, the simple option isn’t seriously rejected. It just doesn’t get seriously considered. It’s crowded out before it’s heard.

The law of the instrument compounds this. An engineer who has spent two years building deep expertise in a particular technology will perceive problems through that lens. This isn’t malice and it isn’t laziness. It’s pattern recognition doing what it does. The problem looks like the right shape for the tool they know best. What they bring to the table is genuine expertise; the distortion is that the match between problem and tool gets evaluated by the person most likely to overestimate it.

These two together produce architecture that is more complex than the problem requires, built from familiar technology, in a room where the social dynamics discouraged the simpler question from being asked seriously. By the time this is visible, it’s usually structural.

Architectural Decision Records help, not because they slow things down but because they require articulating what was not chosen, and why. The absence of a written record of the alternatives means the room doesn’t have to justify the path taken against the path not taken. A deliberate “simplest possible thing” pass before the meeting gives the boring option a formal hearing it might otherwise never get.

Code review is where the social dynamics become the primary mechanism, and where a bias cluster creates a suppression loop.

The halo effect means that work from well-regarded engineers receives proportionally less scrutiny than the risk warrants. This is almost never conscious. The reviewer isn’t thinking “I’ll go easier on this because it’s from someone I respect.” They’re thinking, correctly, that this engineer has good judgment, and that inference is extending too far into the current PR. The result is that the senior engineer’s code gets reviewed less carefully precisely when it should be reviewed most carefully: when their influence is greatest and when a mistake will propagate furthest.

Authority bias closes the loop. When the senior engineer comments in the review thread, the discussion tends to end. The comment is treated as a verdict. This is rational in many cases: the senior engineer usually does have better judgment. But it means that dissent doesn’t surface, even when the dissenter has information the senior engineer doesn’t.

This is where shared information bias becomes the third element. In group discussion, people tend to spend most time on information that everyone already holds.⁵ The piece of information that only one person knows, often the most critical, often the thing that would change the outcome, gets proportionally less airtime. If that person is junior, and the information contradicts the senior engineer’s comment, authority bias and halo effect together make it very unlikely that information will be heard.

Three biases, one suppression loop. The person most likely to have the relevant dissent is least likely to be heard.

Async-first review culture reduces the real-time authority pressure. When the review happens asynchronously, the senior engineer’s comment can be processed against one’s own analysis rather than in the social context of a live conversation. Round-robin dissent, requiring every reviewer to articulate one plausible failure mode before any approval, makes the dissent structural rather than dependent on individual courage.

Debugging and incident response are the highest-pressure moments, and pressure is what makes the bias combination here so costly.

The availability heuristic⁶ shapes the hypothesis. Whatever is most cognitively available becomes the starting point, and in a live incident, the most recent deploy is almost always the most available. This is reasonable: recent changes are more likely to be the cause. But “more likely” is not “always,” and the availability heuristic doesn’t do probability. It trades in salience. The investigation starts from the most vivid candidate, not necessarily the most probable one.

Once the hypothesis forms, confirmation bias narrows the investigation to the confirming branch. You look for evidence that the deploy broke it. Evidence that it didn’t is processed as noise, or as something to explain away. Under incident pressure, cognitive load is highest and the window for reconsidering the frame is smallest. The loop is self-reinforcing: high pressure generates narrowed attention, narrowed attention finds confirming evidence, confirming evidence justifies staying in the frame.

The most effective intervention is almost embarrassingly simple: write down the hypothesis before you start investigating, and write down what would disprove it. This single step creates a reference point that’s outside the investigation loop. If fifteen minutes pass and the disconfirming evidence hasn’t come, the written hypothesis is a visible flag that the frame may need to change. Timeboxed pivots: if not confirmed in N minutes, generate a second independent hypothesis and investigate it in parallel. Give the disconfirmation a forcing function.

Blameless retrospectives have a related purpose. When the retrospective is structured around narrative rather than blame, the failure chain gets documented as it actually occurred, not as the post-hoc story that survivorship bias and social pressure would produce. That documentation is what lets teams learn rather than rehearse reassurance.

None of this requires memorising a taxonomy of biases. The useful question isn’t which biases do I have. Everyone has all of them; that’s what makes them biases rather than idiosyncrasies. The useful question is: which of these moments does our process have friction for, and which ones does it leave open?

Most engineering processes were designed for technical constraints: deployment safety, test coverage, code quality. This is appropriate. What’s less common is a process designed with both technical and cognitive constraints in mind. The two aren’t in competition. They operate on different parts of the problem. But most teams audit their technical process regularly and audit their cognitive failure modes almost never.

The audit starts with recognising that the moments above are not generic risk areas. They’re specific conditions, and the biases that fire in them are predictable. The engineer who anchors in estimation isn’t uniquely susceptible to anchoring. They’re responding to a social context that makes anchoring very likely, in a meeting format that does almost nothing to counteract it. Change the format and the anchoring drops. The bias doesn’t go away. It just doesn’t have the conditions it needs.

A brief note on AI tools, since they’re now part of how most of these moments run. The same biases apply, and some of them amplify. Anchoring gets stronger when an AI model produces an estimate first. The number feels authoritative in a way a colleague’s number doesn’t. Automation complacency in debugging means the AI-generated hypothesis gets less scrutiny than a human-generated one, even when there’s no reason to believe it’s more accurate. If you’re interested in that specific territory, I wrote about it at length in the piece on automation bias.

The engineers I’ve watched make those calls aren’t going to develop a new real-time self-awareness that flags the moment a bias fires. That’s not how cognition works. But if the estimation meeting doesn’t allow verbal anchoring, if the architecture decision requires a written record of what wasn’t chosen, if the code review happens asynchronously rather than in a live social context, those engineers don’t need the signal. The process provides the friction instead.

That’s a more honest goal than awareness. And a more achievable one.