Documented Psychological & Behavioral Categories in Software Teams¶

This is a reference catalog of real, researched psychological and behavioral patterns — not invented terminology — organized by level: individual cognition, individual psychological state, interpersonal dynamics between specific people, group-level phenomena, and organizational/team culture. Several entries link to companion guides already written on this site where the topic has its own in-depth treatment.

Part 1: Individual cognitive biases that shape engineering decisions¶

These are well-studied cognitive biases from behavioral psychology and decision science, applied to the specific decisions software engineers make daily.

Dunning-Kruger effect¶

Origin: Justin Kruger and David Dunning, 1999 (Cornell University), "Unskilled and Unaware of It." What it is: People with low competence in a domain tend to overestimate their ability, because the same skills needed to perform well are needed to recognize good performance — so the least skilled lack the tools to see their own gaps. In software teams: A junior developer confidently overriding a senior's architectural concern, or someone new to a codebase dismissing existing design decisions as "obviously wrong" without yet understanding the constraints that produced them. The flip side — skilled people underestimating their relative expertise because a task feels easy to them — is also part of the original finding and shows up as experienced engineers being reluctant to mentor because "anyone could do this."

Planning fallacy¶

Origin: Daniel Kahneman and Amos Tversky, 1979. What it is: The tendency to underestimate the time, cost, or risk of future actions, even when a person has firsthand experience with past tasks of the same type running over. In software teams: Chronic sprint overcommitment and estimate underruns aren't (usually) individual incompetence — they're a well-documented bias that persists even among experienced estimators, which is why techniques like reference-class forecasting (comparing to actual past similar tickets, not reasoning from scratch) outperform pure intuition.

Sunk cost fallacy¶

What it is: Continuing an endeavor because of previously invested resources (time, money, effort) rather than the future value of continuing. In software teams: Refusing to abandon a failing architecture or library migration because "we've already put six months into this," rather than evaluating the path forward on its own merits.

Not Invented Here (NIH) syndrome¶

What it is: A documented bias in organizational behavior research toward avoiding the use of existing products, research, or solutions because they originated outside the group, often reinventing comparable solutions from scratch. In software teams: Rejecting a well-maintained open-source library in favor of an internal rewrite, or distrust of a solution a previous team or a different office built, independent of its actual quality.

Confirmation bias¶

What it is: The tendency to search for, interpret, and recall information in a way that confirms a pre-existing belief. In software teams: Debugging while convinced the bug is in a particular module, and subconsciously discounting evidence pointing elsewhere; a code reviewer looking for proof that a disliked approach is wrong rather than evaluating it on its own terms (this can shade into premeditated resentment if it's directed at a specific person rather than an idea).

Anchoring bias¶

What it is: Over-relying on the first piece of information encountered (the "anchor") when making decisions. In software teams: An initial, rough estimate given early in a project becomes the reference point that later, better-informed estimates struggle to move away from, even once more information is available.

Part 2: Individual psychological states¶

These describe a person's internal experience, often invisible to teammates unless named.

Impostor syndrome¶

Origin: Pauline Clance and Suzanne Imes, 1978, originally studied in high-achieving women, later found across genders and professions. What it is: Persistent internal belief that one's success is undeserved or due to luck, accompanied by fear of being "found out" as a fraud, despite external evidence of competence. In software teams: Especially common given the field's visible meritocracy signals (certifications, GitHub stars, conference talks) — a competent engineer attributing a successful project to "the team carrying me" or avoiding speaking up in design reviews out of fear their question will reveal a gap everyone else supposedly doesn't have.

Burnout¶

Origin: Formally recognized by the WHO's ICD-11 as an "occupational phenomenon" (not a medical condition) resulting from chronic unmanaged workplace stress, characterized by exhaustion, cynicism/detachment from the job, and reduced professional efficacy. In software teams: On-call fatigue, chronic overtime during "crunch," and the always-on expectation of distributed/remote engineering work are well-documented contributors; the cynicism dimension often shows up specifically as sarcasm about the product or leadership that wasn't there a year earlier.

Learned helplessness¶

Origin: Martin Seligman, 1967, originally from animal studies on inescapable negative stimuli, later extended to human motivation. What it is: A state in which a person stops trying to change a negative situation because repeated past attempts to do so failed, even once circumstances change and action would actually help. In software teams: Engineers who stop raising concerns about known technical debt or process problems because previous attempts were ignored — "why bother, nothing changes here" — even on a new team or under new leadership where raising it might actually work.

Compassion fatigue and decision fatigue¶

See the dedicated guide: Compassion Fatigue & Decision Fatigue — covers the depletion of empathy and decision-making capacity respectively, both relevant to on-call rotations, incident response, and high-decision-volume roles like tech leads and EMs.

Workplace embitterment¶

Origin: Studied in occupational health psychology, notably linked to "illegitimate tasks" (work perceived as unreasonable or beneath one's role) and organizational injustice. What it is: A chronic negative affective state distinct from simple frustration — rooted in a specific perceived injustice, persisting even once the triggering event is past. In software teams: Covered in depth, alongside its software-specific manifestations, in Premeditated Resentment and How It Manifests in Software Development Teams.

Part 3: Interpersonal dynamics between specific people¶

These are patterns between two (or a few) specific people, as opposed to broad group phenomena.

Double standards¶

What it is: Applying different rules or scrutiny to comparable situations based on something other than the merits involved. In software teams: Disproportionate code review rigor applied to one person; inconsistent deadline enforcement. Full treatment: Addressing Double Standards: A Comprehensive Guide.

Premeditated resentment¶

What it is: Resentment that's deliberately cultivated over time (through rumination) or anticipated before an offense even occurs, as distinct from ordinary situational frustration that fades on its own. In software teams: Review weaponization, sandbagging, gatekeeping, strategic silence on doomed plans. Full treatment: Premeditated Resentment and How It Manifests in Software Development Teams.

Knowledge hoarding / information gatekeeping¶

What it is: Deliberately withholding expertise, documentation, or context to maintain personal indispensability or leverage over others — studied in knowledge-management literature as a barrier to organizational learning. In software teams: The classic "bus factor of one" engineer who never documents the deploy process, sometimes out of habit or lack of incentive, but sometimes deliberately, to make themselves irreplaceable or to maintain power over a specific colleague.

The "brilliant jerk" pattern¶

Origin: Popularized by Netflix's public 2009 culture deck and subsequent leadership writing (including Reed Hastings), describing a high performer whose technical output is excellent but whose interpersonal conduct (condescension, public humiliation of others, hoarding credit) actively damages the team. In software teams: The senior engineer everyone defers to technically, whose code reviews are feared rather than respected, and who is retained despite behavior that would get anyone else managed out — specifically because their individual output metrics look good in isolation.

Passive-aggressive communication¶

What it is: Indirect expression of negative feelings through actions rather than direct communication — procrastination, sullenness, deliberate inefficiency, or backhanded compliments — as opposed to open conflict or direct assertiveness. In software teams: "Sure, I'll get to it" followed by indefinite deprioritization; a Slack response of just "k" to a disagreed-with decision instead of raising the disagreement; approving a PR with a comment that technically agrees but clearly signals disapproval.

Tall poppy syndrome¶

Origin: Term with roots in Australian/New Zealand English (though the underlying phenomenon — cutting down those who stand out — is referenced as far back as classical antiquity), describing social pressure to discredit or disparage people who've attained success or prominence beyond their peers. In software teams: A colleague's promotion, conference talk, or public recognition triggers increased criticism of their work from peers, sometimes subtle ("must be nice to have time to write blog posts instead of fixing bugs"), as a way of symbolically cutting them back down.

Audience-dependent behavior (front stage / back stage)¶

Origin: Erving Goffman, 1959, The Presentation of Self in Everyday Life — his "dramaturgical" model of social interaction, which likens everyday behavior to theatrical performance. What it is: Goffman's central distinction is between front stage behavior — performed when one knows an audience is present and is actively managing the impression being created — and back stage behavior, which occurs away from that audience, where the performance drops. Goffman argued this isn't dishonesty exactly; it's a universal feature of social life that everyone does it, tuning behavior to the setting and who's watching. A performance is considered to have "failed," in his framework, specifically when back-stage information or conduct leaks into the front-stage setting. The related individual-difference research: Mark Snyder's self-monitoring theory (1974, later extended in his 1987 book Public Appearances, Private Realities) found that people differ in a measurable, stable trait-like way in how closely they track and adjust their self-presentation to fit the audience. High self-monitors are typically more socially skilled at reading a room and adapting — but also more behaviorally inconsistent across situations, specifically because they're optimizing for each audience's impression rather than for a single consistent persona. In software teams: This is the direct research basis for the exact pattern of a colleague being warm and engaged in front of the team or a manager, but cold, dismissive, or obstructive one-on-one with no audience present. A few specific tells follow directly from the theory: - Behavior correlates with who's watching, not with the working relationship itself. Since front-stage performance is audience-dependent, the clearest sign isn't the warmth itself — it's that the warmth reliably tracks visibility (manager present, group call, public channel) rather than tracking how the actual collaboration is going. - The "performance failure" moment is diagnostic. Per Goffman, a performer is most exposed exactly when back-stage conduct accidentally surfaces where an audience can see it — e.g., a Slack DM meant privately gets screenshotted or forwarded, or a comment made assuming privacy is overheard. What leaks in that moment is generally a more reliable signal than either the front-stage or back-stage behavior alone, because it wasn't curated for an audience. - High self-monitors are harder to "catch," not because they're worse people, but because the trait is specifically about skill at this kind of adaptive performance. This doesn't mean the back-stage behavior is less real or less worth addressing — the research's point is that the inconsistency itself is the expected behavior of this trait, not a sign you're misreading the situation. - This connects directly to premeditated resentment and double standards: audience-dependent behavior is often the delivery mechanism for both — a person can maintain a double standard or nurse a resentment toward a specific colleague for a long time precisely because the front-stage performance in front of shared witnesses (standups, group reviews, the manager) never reveals it, leaving only the back-stage, one-on-one interactions as evidence — which is exactly why documentation (see the double-standards guide's approach) matters more here than in more visibly public conflict.

Part 4: Group-level phenomena¶

These require a group — they don't make sense applied to a single individual's behavior.

Groupthink¶

Origin: Irving Janis, 1972, from case studies of major policy fiascoes (Bay of Pigs, Pearl Harbor). What it is: A mode of thinking that emerges in highly cohesive groups where the desire for unanimity overrides realistic appraisal of alternatives. Janis identified eight symptoms across three categories: overestimation of the group (illusion of invulnerability, belief in inherent morality), closed-mindedness (collective rationalization, stereotyping dissenters/outsiders), and pressure toward uniformity (self-censorship, illusion of unanimity, direct pressure on dissenters, "mindguards" who shield the group from dissenting information). In software teams: A tight-knit team unanimously approving a risky architecture decision in a design review where everyone privately has doubts but no one wants to be the one who derails consensus — especially likely when the team is insulated (no external review), under time pressure, and led by someone who's already signaled a preferred direction.

Social loafing¶

Origin: Max Ringelmann, 1913 (rope-pulling experiments), later formalized by Bibb Latané and colleagues in the 1970s–80s. What it is: The tendency for individuals to exert less effort on a task when working in a group than when working alone, because individual contribution is harder to measure and accountability is diffused. In software teams: Shared-ownership code with no clear individual accountability tends to accumulate neglect faster than code with a clear owner; large standing meetings with many attendees and vague action items are a classic venue, since no one individually feels responsible for follow-through.

Bystander effect / diffusion of responsibility¶

Origin: John Darley and Bibb Latané, 1968, following public reaction to the Kitty Genovese case. What it is: Individuals are less likely to intervene in a problem when other capable people are present, because responsibility is perceived as shared rather than individually owned. In software teams: A visibly broken build or an obvious security issue sits unaddressed because everyone assumes someone else — with more context, more seniority, or more "ownership" — will handle it.

Bikeshedding (Parkinson's Law of Triviality)¶

See the dedicated guide: Bikeshedding (Parkinson's Law of Triviality) — disproportionate debate time spent on trivial, easy-to-have-an-opinion-about details relative to complex, high-stakes ones.

Part 5: Organizational and team culture patterns¶

These describe a sustained climate or norm across a team, rather than a single person's behavior or a one-time group event.

Psychological safety (and its absence)¶

Origin: Amy Edmondson, Harvard Business School, 1999 ("Psychological Safety and Learning Behavior in Work Teams"), later popularized further by Google's internal "Project Aristotle" research identifying it as the single strongest predictor of team effectiveness among the teams studied. What it is: A shared belief that the team is safe for interpersonal risk-taking — that one won't be punished or humiliated for speaking up with ideas, questions, concerns, or admitted mistakes. Edmondson's framework explicitly distinguishes this from mere niceness or lowered standards: high psychological safety paired with high accountability is what she calls the "learning zone"; high safety with low accountability is "comfort," not the same thing. In software teams: Whether an engineer feels able to say "I don't understand this" in a design review, flag a production risk before a launch, or admit they introduced a bug — without fear it will be held against them. Low psychological safety is strongly linked (in both Edmondson's original manufacturing-team study and later software-specific replications) to reduced information-sharing and slower learning from incidents.

Blame culture¶

What it is: An organizational norm where the response to failure centers on identifying who is at fault rather than what systemic or process factors contributed — the direct opposite of the "blameless postmortem" practice that originated in site-reliability engineering. In software teams: Incident retrospectives that focus on "who pushed the bad deploy" rather than "what allowed a bad deploy to reach production without being caught" — which both damages psychological safety and, per incident-review research, produces worse systemic learning because people are incentivized to hide information rather than share it.

Toxic positivity¶

What it is: An organizational or interpersonal norm that suppresses legitimate negative feedback or concerns in favor of forced optimism — "stay positive," "let's not dwell on it" — even when the underlying problem is real and needs addressing. In software teams: A team lead who shuts down a legitimate concern about a rushed timeline with "I just love this team's energy, let's keep the momentum going" rather than engaging with the substance of the concern — functionally similar to low psychological safety, but specifically achieved through enforced cheerfulness rather than open hostility.

Hero culture / martyr complex¶

What it is: An organizational pattern (documented in DevOps and SRE literature as a known anti-pattern) where individual heroics during incidents or crunches are celebrated and implicitly rewarded, rather than the systemic fixes that would prevent the crisis recurring. In software teams: The engineer who stays up all night fixing a production outage gets public praise and gratitude; the engineer who quietly prevented the same class of outage through unglamorous preventive work months earlier gets none — creating a perverse incentive toward firefighting over prevention.

Chilling effect¶

What it is: The broader deterrent impact when visible punishment of one person's legitimate speech or complaint discourages others from raising their own concerns. In software teams: Covered as part of the vocabulary around retaliation in What People Call It When Speaking Up at Work Backfires — directly relevant to psychological safety, since a single retaliatory incident can suppress a whole team's willingness to flag problems.

Quick reference: which category for which observation¶

Most real team dysfunction is several of these compounding rather than one in isolation — low psychological safety, for instance, is both a direct cause of groupthink (people won't voice dissent) and a precondition that lets premeditated resentment and double standards go unaddressed for longer than they otherwise would.