Why Egocentric Bias Makes You a Worse Developer, Leader, and Collaborator Than You Think

The Default Setting Most Professionals Never Question

Egocentric bias in teams is one of the most well-documented yet least-discussed forces shaping how software developers, product managers, and IT decision-makers actually work. You might recognise the colleague who dominates every sprint retrospective, the team lead who quietly believes they write the cleanest code, or the policy professional who is certain their risk assessment is more rigorous than everyone else's. But decades of peer-reviewed psychology suggest that the most important person exhibiting this behaviour is, with considerable likelihood, you.

This is not a moral indictment. It is a structural description of what it means to have a single, fixed vantage point — to be, in the most literal sense, the centre of your own perceptual universe. The evidence for this is extensive, replicated across multiple research programmes, and directly relevant to how technical and analytical professionals make decisions, assign credit, and evaluate their own blind spots. Ignoring it is, ironically, one of the clearest examples of the very bias in question.

The Spotlight Effect: Why Your Code Review Comment Was Not That Noticeable

In a now-classic set of studies published in 2000, psychologists Thomas Gilovich, Victoria Medvec, and Kenneth Savitsky demonstrated what they called the spotlight effect. They asked university students to wear a deliberately embarrassing t-shirt — featuring the face of singer Barry Manilow — and walk into a room full of peers. Before entering, participants guessed how many people would notice. They estimated close to half the room. The actual figure was around a quarter.

The gap between perceived and actual attention is not trivial. It reveals a consistent overestimation of how closely others are monitoring us. For developers and technical professionals, this has direct operational implications. That awkward moment when you pushed a breaking change to main, or the meeting where you stumbled over an explanation of your architecture decision — you likely overestimate how much your colleagues noted, discussed, or remembered it. The research, as reviewed by Silicon Canals, suggests the audience is mostly preoccupied with their own performance.

The liberating reading of this finding is that nobody is losing sleep over your deployment incident. The more unsettling reading is that you assumed they were watching so closely in the first place — and that assumption shapes how you communicate, how you justify decisions, and how much cognitive overhead you devote to managing your own image at the expense of actually solving the problem in front of you.

Why Every Team Member Thinks They Did Most of the Work

A second landmark finding is even more consequential for anyone who works in collaborative environments. Back in 1979, researchers Michael Ross and Fiore Sicoly published a study in the Journal of Personality and Social Psychology asking married couples to estimate how much each partner contributed to shared household tasks — cleaning, planning, and even starting arguments. When the two partners' self-estimates were combined, the totals routinely exceeded 100 per cent.

The explanation is not dishonesty. It is availability. Your own contributions are viscerally present in your memory: the documentation you wrote at 11pm, the edge case you caught in someone else's pull request, the Slack message you sent to unblock a teammate. Their equivalent efforts are, at best, secondhand knowledge. Your contributions are vivid; theirs are hearsay.

Scale this dynamic from a household to an agile development team, an open-source project, or a GDPR compliance working group, and you get a room full of competent professionals who each, privately, believe they are carrying more than their fair share. According to research published in the Journal of Personality and Social Psychology, this pattern is not a sign of vanity or dysfunction — it is a predictable output of how human memory is structured. It does not require anyone to be unusually self-important. It only requires a memory that indexes its own material first.

The Bias Blind Spot: Why Knowing About Cognitive Bias Does Not Make You Immune

Perhaps the most directly relevant finding for analytically trained professionals is what psychologists Emily Pronin, Daniel Lin, and Lee Ross documented in 2002: the bias blind spot. Across several studies, participants readily acknowledged that other people are susceptible to self-interest and distorted reasoning. They simultaneously rated themselves as significantly less affected than average — less biased than their classmates, their colleagues, and strangers sitting nearby.

This is the finding that makes the rest of them sting. The natural reaction when reading about the spotlight effect or contribution inflation is to think, reasonably, that it describes others more than it describes you. Developers and data professionals are particularly susceptible to this version of the blind spot because their training emphasises analytical rigour, which can create a false sense of immunity to psychological bias. Research published in the Journal of Personality and Social Psychology by Pronin and colleagues suggests that introspective ability — the very skill technical professionals pride themselves on — is precisely what the bias blind spot exploits. We look inward, find no obvious evidence of bias, and conclude we must not have any.

Egocentric Bias Is Not Vanity — It Is the Architecture of a Single Viewpoint

It is worth being precise about what this research does and does not claim. These biases are not evidence that people are narcissistic, dishonest, or incompetent. They are a structural consequence of having exactly one vantage point. You are the only person whose internal monologue you can hear, whose physical discomfort you can feel, and whose intentions you know directly rather than inferring from behaviour. Everyone else, no matter how well you know them, you perceive from the outside.

This means the human mind necessarily builds its model of the world from a fixed camera position — and then, crucially, forgets the camera is there at all. We do not experience our perspective as a perspective. We experience it as simply the way things are. For professionals making high-stakes decisions — about infrastructure design, compliance frameworks, security threat models, or team structures — this is not a philosophical curiosity. It is an operational variable.

Research by organisational psychologists, including work discussed in the Harvard Business Review, consistently identifies self-serving attribution — the tendency to claim credit for successes and attribute failures to external factors — as one of the principal sources of dysfunction in technical and creative teams. It is not the only driver, but it is one that is structurally guaranteed to be present whenever two or more people share a task.

What Developers, PMs, and Policy Professionals Can Actually Do About This

The point of understanding egocentric bias in teams is not to induce guilt — guilt is, as the original research framing notes, simply the spotlight swinging back on yourself from a more self-critical angle. It does not correct the underlying structural problem. The more productive response is systemic and specific.

For developers and engineers, this means treating your own certainty about a technical decision as a signal to seek a second opinion rather than a signal to stop questioning. Code review processes, architectural decision records (ADRs), and blameless post-mortems are, at their best, institutional responses to egocentric bias — systems designed to make collective reasoning visible when individual cognition is structurally limited.

For privacy professionals and GDPR compliance leads, the bias blind spot is particularly consequential. A data protection impact assessment written by a single author, reviewed only internally, is an instrument that will consistently underweight the interests of data subjects — not because the author is negligent, but because the author's own operational perspective is simply more vivid and available than the abstract interests of people they will never meet. Independent review, structured stakeholder consultation, and adversarial red-teaming of privacy frameworks are not bureaucratic overhead. They are corrections for a cognitive architecture that cannot see itself.

For IT decision-makers and small business owners evaluating tools, vendors, or cloud infrastructure options, the research suggests a concrete heuristic: when you are most certain that a decision is straightforward, that is precisely when to slow down and ask whose perspective is missing from the analysis. The most dangerous version of egocentric bias is not the overt kind. It is the invisible kind, operating at full strength in moments when you feel most objectively rational.

Awareness helps, but less than we would prefer — the biases continue operating even when you know their names. What awareness buys is a pause. And in technical environments where decisions compound over time, a moment's hesitation before assuming you did most of the work, or that everyone noticed your mistake, or that your risk model is less distorted than your colleague's,

Originally reported by Silicon Canals. Summarised and curated by European Purpose.