The Psychology of Software Teams - Cat Hicks (Talk Outline)

Cat Hicks — PhD in quantitative psychology, “psychologist for software teams,” research architect, “defender of the mismeasured” — behind the Developer Thriving, AI Skill Threat, and Code Review Anxiety frameworks. Central question: “How are we doing at being technical?” — and how the industry does bad psychology about developers.

1. The Opening Story & the Visibility Gap

• A party: she meets a terrified engineer (“I’m not a couch psychologist — I don’t need your childhood”). His work “helps ships talk to each other,” benefiting several thousand people a day in his city — yet his own problem is “how do I convince my boss to let us talk to each other more?” (“You help ships communicate, and the people doing that can’t communicate.“)
• Quantitative version: across a study of 465 engineering managers, 88–90% say “making technical effort seen/visible is part of my job.” But <24% of developers (across measures) say it actually happens — a perception misalignment, worse for less-prototypical roles (DevOps/infra/platform, work “falling between” visible roles).
• Distress: 43–45% report AI skill threat (deep worry your current skills will become irrelevant — and that others’ judgments of you will get inaccurate). Code-review anxiety is costly: each 1-unit increase raises the probability of avoidance behaviors (40% more) — checking out, not giving full feedback, going through the motions.
• Developer voices: “so much of my work never sees the light of day”; “we build castles in our minds, then an email demolishes what you built for years”; ”I’m not convinced leadership even thinks we’re people.”

2. The Brains-in-Jars Model (bad psychology)

• We carry networks of beliefs and run little hypothesis tests about the world (parallel to Kent Beck’s desert/forest); mental models can change (like codebases).
• The bad model — “brains in jars”: developers are isolated, fungible, antisocial brains on a shelf, producing discrete units of work; social/collaborative work is invisible. People don’t fully endorse one extreme, but orgs lean into these assumptions.
• Learning debt (from her cafe study of 25 engineers thinking aloud while coding): developers have deep learning strategies their orgs ignore or actively discourage — social cues (“don’t document to survive here,” “I don’t care about the thing you tried that failed”) teach people (esp. juniors) to keep their heads down and not share learning → the cycle compounds until teams can’t leverage their own problem-solving history.
• Brittle vs. resilient productivity: brains-in-jars orgs fixate on short-term productivity (“number go up” fast) that shatters catastrophically when things go wrong (people quit, projects fail, communication breaks). Resilient productivity builds long-term mastery — numbers look slower, but the psychological structures empower human problem-solving when things go wrong.
• Why we get pulled to short-term cycles (with citations, blog post accompanies): performance ≠ learning (Bjork — good long-term learning strategies can degrade immediate performance); a performance orientation (making the grade) is brittle (eventually you avoid challenge → bad for innovation); the brilliance belief (“you must be born brilliant”) leads fields to weed people out and kills inclusive innovation.
• Cat’s Law: “The more a software team fixates on demonstrating short-term performance, the less it is able to protect the foundation on which long-term performance depends.”

3. Psychological Affordances — Breaking Up With Brains-in-Jars

• Our minds seek affordances (a kayak lets her body reach the open ocean; the environment lets us be a certain version of ourselves). Mindset-by-context / “seed and soil” (Walton & Yeager): the seed = adaptive beliefs enabling resilient cycles; the soil = the social context that reinforces them (you’re not constantly told “you can’t be that here”).
• We continually ask “what does it mean to be successful/productive/belonging here?”, run small experiments, and calibrate — so culture can change (“we only have a culture because we’re all creating it all the time”).
• Four affordances (LABS / Developer Thriving) picked from a big lit review for robust evidence that they drive long-term achievement and are changeable: Learning culture, Agency (my action connects to a real outcome, not immediately blocked), Belonging (accepted for who I am), Self-efficacy (I can overcome challenge) — plus motivation.
• Measured across 10,000+ developers/leaders (statistical model, not just correlation): a strong positive link — each increase in dev thriving ≈ a 25% gain in self-reported productivity (people are good at reporting whether they achieved the productivity that mattered), holding across 12+ industries, many roles, and demographics.

4. AI Skill Threat vs. Contest Culture

• New vocab: identity threat (will my work lose meaning / be evaluated unfairly / be categorized in ways I reject?) and contextual sensemaking (does “being a developer” still make sense under GenAI?).
• The AI Skill Threat study (done rigorously): recruited ~5,000 real developers doing real GenAI adoption, inclusively (women, many countries), with new adapted measures, and pre-registered hypotheses (some of which didn’t pan out — reported anyway).
• Findings: high rates of AI skill threat. Comparing a contest culture (constant tiny weeding-out contests from the brilliance belief — “are you really technical enough?”) vs. a thriving culture (esp. learning + belonging, which psychology shows de-escalates threat): in a contest culture you’re ~2× as likely to feel AI skill threat — even though both camps report similar levels of change/fear (thriving-culture people just feel they have the affordances to overcome it).
• Crucial distinction: AI skill threat is not impostor syndrome — contest cultures drive both, but even people with no impostor syndrome feel worse AI skill threat inside a contest culture. Contest culture is a big lever to intervene on.

5. Software Is Pro-Social; the 10x Myth; Evidence It’s Changeable

• Reject “developers are antisocial” — software is inherently pro-social/collaborative (you engage others’ work, history, legacy). 90%+ of developers agree “it matters that my work helps people” (a pro-sociality measure).
• Endorsing the solitary innate-genius stereotype has a measurable, cumulative, persistent cost to our beliefs about ability. The 10x-engineer myth (traced to 1960s–70s task-time studies that “round up to 10×”) is boring and wrong; our brains fall for it because individualistic explanations are cognitively accessible and (esp. individualistic American) tech culture, plus meritocracy messaging, actually makes evaluations more biased.
• Cycle-time analysis (led by John Flora): anonymized activity data from 11,000+ people, 216 orgs, hierarchical modeling (org, team, within- and between-individual variance). Takeaway: heterogeneity is the expectation, not a fluke; more coding time → shorter cycle time (a classic belief confirmed); but a developer’s own past cycle time doesn’t predict their future average (work is highly variable). So push back on “your team must hit this average / benchmark” — ask how it was calculated. “Look for shared/environmental explanations; do less individual blame and praise.” (“Change is an opportunity to strengthen cultures.“)
• You can do real-world experiments: a distributed, online RCT on code-review anxiety produced statistically significant reductions vs. control (and gains in self-compassion/self-efficacy); participants who did the workshop in their own companies later showed clinically significant reductions — proof psychological environments are measurable and changeable.

6. Close

• Yes, we can break the brains-in-jars model — via observation, understanding environments, testing interventions, and rigorous analysis (psychologists do a lot of math; bring them into your activity data). With these tools we can protect ecosystems of healthy problem-solving. (Book on the psychology of software teams forthcoming.)

People, Frameworks & References Cited

• Cat Hicks — speaker; Developer Thriving (LABS), AI Skill Threat, Code Review Anxiety frameworks; John Flora (cycle-time study).
• Bjork (performance ≠ learning), Walton & Yeager (“seed and soil” / mindset-by-context), plus cross-cultural brilliance-belief research.
• Concepts: visibility gap, brains-in-jars, learning debt, brittle vs. resilient productivity, Cat’s Law, psychological affordances, developer thriving, identity threat / contextual sensemaking, contest culture, AI skill threat ≠ impostor syndrome, pro-sociality, 10x myth, real-world RCTs.

Video: https://www.youtube.com/watch?v=HbLDv_FwtaE — Transcript via yt-transcript.sh; outline generated from the transcript.