Here’s something most people don’t realize about how the brain works: it isn’t a camera. It doesn’t passively record what’s in front of it and then form an opinion. It does something more like the opposite.
The brain is constantly generating predictions about what it’s about to experience. When reality matches the prediction, the signal gets dampened — treated as expected, unremarkable. When reality doesn’t match the prediction, you get what neuroscientists call a prediction error: a signal that something worth paying attention to has happened.
This architecture is genuinely useful. It’s why you don’t have to consciously process every detail of a familiar room. The brain has a model, the model is accurate, and cognitive resources get freed up for things that actually need attention.
The trouble starts when the predictions are wrong, and the brain doesn’t flag it.
The formal research on this idea started in the early 1960s with psychologist Robert Rosenthal, who was studying something surprisingly mundane — lab rats navigating mazes. He told one group of student researchers their rats were genetically superior at finding their way through, and another group that theirs were not. The rats were identical. The results weren’t. The students who expected better performance got better performance — not because the rats were different, but because the students were. Their expectations had quietly changed how they handled, coached, and observed the animals.
That finding sent Rosenthal in a direction that would shape his entire career.
He partnered with elementary school principal Lenore Jacobson to test whether the same dynamic played out with people. Teachers were told that a new assessment had flagged certain students as likely to make significant academic gains in the coming year. The students were randomly chosen — the test was fictional. But those students improved more than their peers over the following year, with the strongest effects showing up in the youngest kids. The expectation had become the outcome.
Rosenthal and Jacobson published their findings as Pygmalion in the Classroom in 1968, named for the myth of a sculptor whose belief in his creation was so complete that it came to life. The parallel was intentional: what we believe about someone can quietly make it true.
What Rosenthal demonstrated in labs, we can observe in teams every day.
Expectation Bias is often discussed alongside confirmation bias, and the two are related — but they’re not the same. Confirmation bias describes what you go looking for. Expectation Bias describes what you notice when the evidence is already in front of you.
Together, they form a tight loop. You expect something, you notice what matches, you ignore what doesn’t, and your expectation gets reinforced. Repeat, indefinitely.
The reason this matters for teams specifically is that most team processes assume a certain level of perceptual neutrality. We assume that when we review research, evaluate a design, or assess a project’s progress, we’re working from a shared reality. We’re often not. We’re each working from our own model, shaped by what we expected to find before we walked into the room.
The mechanism behind it isn’t mysterious. Rosenthal found that teachers were changing their behavior in small but consistent ways — offering more encouragement, more patience, more chances to participate — without realizing they were doing it at all. The expectation didn’t stay internal. It leaked out through every interaction, and the students responded to it. Intention had nothing to do with it.
Expectation Bias rarely feels like bias. It feels like experience. It feels like pattern recognition. It feels like knowing your team, knowing the work, knowing what good looks like. And that’s exactly what makes it so hard to catch — by the time it’s shaping a decision, it’s already been mistaken for judgment.
In team dynamics, it often shows up as a label that outlasts its evidence. Once a teammate gets filed away — “the strong one,” “the one who overcomplicates things,” “the one who’s still finding their footing” — that label starts doing the evaluating. A well-regarded engineer’s PR gets waved through. A newer designer’s concept gets interrogated before it gets considered. The work hasn’t changed. The filter has.
It shows up in how work gets reviewed, too. A feature that leadership has championed gets generous interpretation — rough edges get noted and moved past. A project that’s been quietly doubted gets scrutinized at every turn. Teams present the same quality of progress and get fundamentally different responses, not because the work is different, but because the expectations aren’t.
And it shows up in research. A usability session gets conducted with a mental model of how users will respond — and that model shapes what registers as signal. A participant’s hesitation barely makes it into the notes. A moment of confusion becomes “they figured it out.” The problem isn’t that the team is ignoring the evidence. It’s that the expectation has already changed what the evidence looks like before anyone decides what to do with it.
The cost is the same regardless of where it shows up: decisions made on distorted observations, people evaluated against fixed labels, and research that reflects what the team predicted rather than what users actually experienced.
🎯 Here are some key takeaways:
Notice when you've already made up your mind before the work begins
One of the clearest signals of Expectation Bias is when feedback feels like a formality. If you're going into a design review, a code review, or a performance conversation with the outcome already settled, that's worth pausing on. Being experienced isn't the same as being objective. Ask yourself what you expect to see and why before you see anything.
Agree on what you're looking for before you start looking
Decide what "good" looks like before the work is in the room. In usability research, define success and failure before sessions begin. In design reviews, agree on the questions the work needs to answer before it gets presented. This gives the evaluation something to anchor to other than whoever walked in with the strongest priors.
Watch how your read on a person shapes your read on their work
Once you've decided someone is strong or weak, that label follows their output around. A sharp engineer's PR gets lighter scrutiny. A newer designer's concept gets questioned before it gets considered. The work hasn't changed — the filter has. Ask yourself whether you'd evaluate this differently if you didn't know who made it.
Write your research questions before you write your hypotheses
Most teams do it backward. They form a point of view and then design research to test it. That sequence almost guarantees the questions will favor the hypothesis. Draft questions first, from genuine curiosity about what you don't know. Research designed to explore tends to find things. Research designed to validate tends to confirm things.
Separate who collects the research from who interprets it
When the people who designed the feature are the same people facilitating the usability sessions, expectation bias is baked in from the start. They're not neutral observers. They're invested in a particular outcome. Even a small degree of separation between the team doing the work and the team running the research significantly reduces the angle at which bias enters.
📚 Keep exploring
To dive deeper into the topic of attentional bias and its implications for decision-making, check out these resources: