The real secret to high-performing teams - Joseph Pelrine | Craft 2025

June 04, 2026

The real secret to high-performing teams (Crew Resource Management) - Joseph Pelrine (Talk Outline)

A Craft 2025 (Budapest) talk by Joseph Pelrine — psychologist, one of the pioneers/top experts in agile methods (per Cognizanti), 30+ years refining processes, PhD in forensic psychology and psycholinguistics, and a self-described “CTO/CIO/CDO whisperer.” He has Hungarian ancestry (his grandfather owned a restaurant in Hungary and made great pálinka), delivered SAP’s first Scrum-master training in Budapest 20 years ago, and shared a Munich flat with Kent Beck for half a year during Europe’s first XP project. Sitting down because “I’m not hip anymore” (a hip operation is booked for end of June). Thesis: the real secret to high performance isn’t technical skill or even psychological safety as a prerequisite — it’s Crew Resource Management (CRM), a set of ground rules (from NASA → aviation → medicine) for how a team acts and interacts so it can apply its technical skills even “when the [stuff] hits the fan.” Structure: the problem → three error classes → CRM → the systems view of error → the CRM protocols → how to start → Q&A.


1. The Problem: Talent ≠ Team Performance

1.1 The recurring failure mode

  • You gather really talented individuals expecting a great team — and “they act like a bunch of idiots.”
  • Running example: the Swiss national football team does this every year.

1.2 Functional vs. non-functional, for teams

  • Just as a product must meet functional and non-functional requirements, a team needs technical and non-technical skills.
  • Technical skills make a high-performing individual; non-technical skills make a high-performing team — they are not the same thing.

1.3 Why hiring doesn’t fix it

  • HR and management keep hiring for technical skill because they don’t know how to test for people who work well in a team.
  • They also don’t know how to set up an environment in which a team can become high-performing — which is what the talk is about.

2. The Three Classes of Non-Technical Error (from psychological research)

  • He frames it from “hardcore psychological research,” not the usual “shared goal / psychological safety blah blah.”
  • Three areas: human-factor errors, fixation errors, communication errors.

2.1 The Stroop test — inducing cognitive overload live

  • Classic psychological test: each slide shows a color word printed in a different color; say the color it’s written in, not the word.
  • After warming up, he speeds up and starts switching languages mid-sequence.
  • Effect: cognitive overload by corrupting three sensory inputs — the words, the colors, and the language.

2.2 How often we err (the research on error rates)

  • Routine task, no stress: a mistake roughly every 30 minutes (often too subtle to notice).
  • Complex task, no stress: every 5 minutes.
  • Complex task, with stress: every 30 seconds.
  • Extremely stressful task (like the Stroop test): research shows 95% of people make mistakes — “the other 5% are liars.”
  • During the test people shut down and cope by narrowing focus onto just the color.

2.3 Fixation errors (cognitive tunneling)

  • Narrowing focus leads to cognitive tunnelingfixation error: doing more of the same.
  • The (mis-attributed) “definition of insanity” quote — “attributing this damn quote to Albert Einstein over and over again.”
  • Google research: developers debugging spend 50% of the time on the wrong thing — too fixed to change track.
  • Police fixate on a single suspect.
  • Visual gags: the “yellow triangle in the middle” that isn’t there; the woman “eating a sandwich” who is actually holding a shoe — “once you see it, you can’t unsee it.”

2.4 Communication errors

  • “Perfect translation from Finnish into Hungarian” — a classic; “my wife and I do this every weekend.”

2.5 Individual vs. team level

  • Some of these are individual problems, some are team problems.
  • Because it’s hard to hire for high performers, the goal is to set up an environment that helps people become high-performing — via CRM.

3. Crew Resource Management (CRM)

3.1 Definition

  • Developed by NASA for space flight.
  • “A set of ground rules for action and interaction among people in a team that give the team the ability to do their technical skills as well as possible even when the [stuff] hits the fan.”
  • The team trusts that everyone acts the same way, so they can focus on doing their technical work best.

3.2 Where he learned it — the hospital

  • He works as a psychologist at his local (small) Alpine hospital, where everyone is trained/certified as an emergency responder (in a catastrophe, everyone rides an ambulance).
  • Topical: 1,000 cubic metres of glacier came down and wiped out a Swiss village the night before; a village ~20 km from him is “just waiting to happen.”
  • He knows that if disaster strikes he’ll be called in, and everyone must be able to trust each other to do their best work.

3.3 Everyone has a role

  • He is not a doctor — he has hematophobia (can’t look at blood) — but a crew is like football: everyone plays a role, and his is being “very good in managing these things.”

3.4 Where CRM is used

  • Aviation (he’s worked for Lufthansa and Swiss), Formula 1 (“that red team down in Italy” — Ferrari), football (Swiss national champion team in Basel), and ER/operating teams.
  • His definition of high performance: “you have to be able to trust each other with your life.”

4. Turning Psychological Safety On Its Head

4.1 The reframe

  • The last-decade orthodoxy says psychological safety is the prerequisite for high performance.
  • CRM flips it: what if psychological safety is the result of something?

4.2 Kurt Lewin’s first equation

  • B = f(P, E) — behavior of a person is a function of the person and their environment.
  • For a psychologist: to change behavior, work with the person (therapy) or change the environment.

4.3 Extending it to teams (Cloyd/Shepard et al., ~1964)

  • Team behavior is a function of the people, their actions, and their interactions with each other and the environment.
  • To optimize team performance without acting as a psychotherapist, change what you can in the environment — echoing Cat Hicks’ morning talk (“I do research, I’m not going in as a psychotherapist for software developers”).

4.4 Self-organization → culture as a derivative

  • In complexity theory, self-organization = emergence of macro-level behavior from micro-level actions/interactions.
  • In human systems, that macro-level emergent property is culture.
  • Culture is the first derivative of a change in behavior over time” — a derivative property you cannot change directly; it changes as a result of something.
  • Ground rules/behavior that build trust (an interpersonal construct) → psychological safety emerges in the culture.

4.5 XP as a set of ground rules

  • Extreme Programming is “a set of ground rules that tells a software development team how to interact to produce better software” — it says little about technical skills (program together, write tests first).
  • The XP team that turned practices “up to 11 or 12” under stress: most teams get sloppy under stress (skip tests, break CI/CD); the best team he coached did the opposite — because the only way to work well under stress is to trust everyone is doing the same thing for quality, so they don’t have to think about it.

4.6 CRM stories from the field

  • Sandra (Lufthansa purser & CRM instructor): Lufthansa always mixes crews so you never fly with someone you’ve flown with before — it levels the playing field (same starting situation every time). Her job: take strangers and, in a 15-minute pre-flight briefing, make them a high-performing team she can trust with her life. Crews do recurrent training (a week or two of simulations every year). “Without CRM it would be impossible with all the egos.”
  • The anesthesiologist friend (head of anesthesiology & emergency medicine; formerly head of Berlin’s emergency rescue team; 9,000+ ambulance rescues, 3,000+ helicopter rescues) who trained him and will be present for Pelrine’s own hip operation. His quotes: “I need to have everyone speak up” (building psychological safety); “I need to hear everyone’s opinion” (building diversity); “How else can I see my own blind spot?”
  • The ambulance question: arriving at a rescue, who does he ask first? Not the assistant doctors — the ambulance driver: “Can I get back to that hospital or is the road closed? Is that hospital taking patients? Do I need to call a helicopter?”
  • The ethos: ”We watch out for each other. I watch out for you, you watch out for me.” It is expected that you speak up and say “I see this differently.”

5. The Four Things a Team Does (McGrath & Larson)

  • Not “what the boss says,” “implement Jira tickets,” or “provide shareholder value.”
  • (1) Bring in new ideas and have them heard and accepted by the whole team — the opposite of “Shut up, that’s a stupid idea” (which destroys psychological safety).
  • (2) Be aware of the situation around you and share it so the whole team knows.
  • (3) Decide between alternatives.
  • (4) Divide up the work and execute on it.
  • Underneath all four: communication, verbal and non-verbal.

6. The CRM Practices (~15 guidance rules)

A downloadable checklist is offered via a QR code at the end. You don’t memorize all 15; pick one or two.

6.1 Situational awareness

  • Know your environment and the whole situation around you; know what resources you have available.
  • Be aware of what you’re focusing on.

6.2 You’re a crew, not a pseudo-agile democracy

  • Not one of those “self-organizing teams where everybody has equal power and you discuss so long that nothing gets done.”
  • eBay-Amsterdam anecdote (he was CTO): every meeting reached a decision in 15 minutes, then spent 3 hours going around until everyone had spoken, only to return to the original 15-minute decision.
  • Accept that someone takes responsibility as leader (official or unofficial/meritocratic); be aware of your role.

6.3 Communicate and support

  • Communicate clearly and precisely; speak up; be a good team member.
  • Coordinate your work; support and help others.

6.4 Decide and re-evaluate

  • Use all available information for decisions; be aware when you have a fixation error; cross- and double-check (challenge/response); never assume.
  • Keep re-evaluating because things change; anticipate and plan ahead; call for help early (ego stops developers from admitting a problem).
  • Distribute the workload sensibly; use memory aids/checklists, look things up, and set priorities dynamically.

7. The Systems View of Error

7.1 Person-centered vs. system-centered

  • Person-centered: errors happen because people are bad/sloppy/untrained → countermeasures based on fear and punishment (manager talks, extra check sheets, reprimands).
  • System-centered: human error is a consequence, not a cause — it happens for systemic reasons.

7.2 The (incomplete) list of error causes

  • Mental issues (tired, not concentrating), physical issues (hungry, “old like me”), workplace problems, team problems — including missing shared goals and poor teamwork.
  • The “oops” is a consequence of some root cause.

7.3 The Swiss cheese model (James Reason)

  • An error becomes an incident only when contributing factors aren’t blocked.
  • Systemic barriers are like Swiss cheese (Emmentaler) — full of holes that constantly move; when the holes line up, the error gets through.
  • Design systemic barriers/boundaries so an error doesn’t become an incident.
  • This is harder, which is why organizations prefer to blame people rather than admit “our systems and processes are screwed up” (per Reason).

7.4 The reframed question

  • High-performing teams don’t ask “how can we get better?” — they ask “How can we make it systematically more difficult for errors to become an incident?” This unlocks creative ideas and makes the work fun.

7.5 Example — Finnish reindeer

  • ~4,000 reindeer killed by cars each year in Lapland (Oulu, Rovaniemi), often at night by drunk drivers.
  • Person-oriented fix: raise fines (Finland’s fines already scale with income).
  • Systemic fix: paint the reindeer’s antlers with reflective paint. (Honest caveat: it worked for a while, then drivers assumed it was “just a person wearing reflective stuff” who wouldn’t step into the road.)

7.6 Example — the Swiss pharmacy

  • Doctor picks a medicine from a database of all Swiss medicines and prints a prescription with a QR code.
  • Pharmacy scans the QR code → confirms the medicine and stock → prints a slip → medicines are stored so they can’t be confused by name or packaging → the person scans the barcode to confirm → a second person verifies → sign → hand over.
  • Extra time for the systemic intervention: about a minute — “but it works.”

8. Fixation-Error Countermeasure: 10-for-10

  • His trainer’s line: “Every second counts.” If you think “every second counts,” you drop into Kahneman’s System 1 — quick, intuitive, often wrong.
  • 10-for-10: stop for 10 seconds, take a deep breath, and with the team discuss what you’ll do for the next 10 minutes (symbolic — could be longer or shorter if something changes).
  • Sequence: diagnosis/problem → stop → discuss (problem, team availability, facts, plan, distribute) → act.

8.1 FORDEC (from Lufthansa)

  • Facts → Options → Risks/benefits → Decide → Execute → Check, then loop back.
  • “If this happens to look like an iterative process — yes, it’s exactly the same” — essentially doing Scrum on medicine.

9. Communication-Error Countermeasures: Closed-Loop Protocols

9.1 SBAR

  • Standard medical handoff protocol seen on TV when an ambulance brings a patient in: Situation, Background, Assessment, Recommendation.

9.2 Challenge/response (aviation)

  • One person says something; the other reflects it back to confirm understanding; the first confirms “it’s clear that you understood it.”

9.3 Restaurant kitchen

  • His grandfather (“nagypapa”) was a chef: the sous-chef calls an order, the grill chef repeats it back — “Oui, chef” — confirming understanding.

10. Why Care, and How to Start

10.1 The business case

  • 70% of production problems come from human factors, not technical errors.
  • CRM is not just for crisis — it’s for performance.

10.2 Normalizing the behaviors

  • Normalize saying ”I need help” or ”Are you sure about that?
  • Prevent cognitive tunneling with rules like “if you’re debugging longer than half an hour, switch pairs.”

10.3 How to begin

  • Download the checklist (QR code on the last slide); pick just one habit — don’t try to memorize/practice all 15.
  • Treat them as ideas to try, then use retrospectives to learn and internalize them.
  • Reframe retrospectives: when something happens, don’t ask who’s to blame — ask “how did our systems defenses mess up?”
  • CRM won’t stop your product manager from changing requirements — “it’ll help you survive them doing so.”
  • As with anything a psychologist does, there are references.

10.4 Closing joke

  • A teacher asks “Does anyone have a question?” — all hands up. She redefines a question as wanting more information (vs. a discussion / telling her how you’d do it) — all hands go down. ”What questions do you have?

11. Q&A

11.1 Q1 — Most important skill of a manager building a high-performing team (besides getting out of the way)?

  • Trust — trusting his people.
  • Role-modeling the behavior he wants from the team.
  • In all his transformations, the key was getting the manager to be a leader, not a manager, and to model the behavior — not “do what I say, not what I do.”

11.2 Q2 — Balancing over-democratization vs. military-style decision-making when the “captain” isn’t professionally respected?

  • He has “a serious problem with all these military metaphors” (e.g., “turn the ship around”) — we’re not in the military; you can’t be jailed or shot for insubordination, so different rules apply.
  • If the leader isn’t recognized, there’s a serious issue to be dealt with outside the team.
  • Aside: he tries to keep it away from HR — “the only reason for HR’s existence is to stop management from being sued.”

11.3 Q3 — Are the rules decided by the team or by an expert? (and does it apply to SAFe?)

  • The set of rules can be decided by the team — like XP, which the team must decide on.
  • What he learned from Kent Beck (also a good psychologist): never tell a team “do this” — say “let’s try this.”
  • Always give a sunset date (“let’s try this for a sprint / the next month”) so it’s clear when it stops; then review and let them decide — you can’t force people, but you can hold them to their commitment.
  • Introduce rules not all at once so you don’t overwhelm/scare them.
  • He declined to answer the SAFe part.

11.4 Q4 — Ways to enhance a leader–team relationship?

  • At eBay he “actually had a budget for alcohol.”
  • Becoming a leader/manager after being a team member is a hard role shift (part of why they get their own offices).
  • Again: be a leader and role model, not a manager. He’s trying to role-model this for the audience — “real life, proven to work in the highest-performing teams.”

11.5 Q5 — Where’s the line of a manager’s responsibility to build/maintain the high-performance environment?

  • Aviation is better off than emergency medicine here, because in a plane everyone’s life (including the captain’s) is on the line.
  • If he lacked an answer he’d call his friends Sandra (purser) or Andreas (pilot) — the captain has a clear role and shares the risk.
  • Lots of research and material exist; contact him on LinkedIn (“probably the only person with that weird name”) and he writes a free weekly newsletter on these topics (his only self-promotion).

People & References Cited

  • Joseph Pelrine — speaker; psychologist; agile pioneer; PhD in forensic psychology & psycholinguistics; Hungarian ancestry; hospital emergency responder; writes a weekly newsletter.
  • Kent Beck — flatmate in Munich during Europe’s first XP project; “also a good psychologist”; source of “let’s try this” + sunset-date coaching.
  • Cat Hicks — earlier Craft speaker; “I’m not going in as a psychotherapist for software developers.”
  • Kurt Lewin — B = f(P, E), the first equation of social/complexity theory.
  • Cloyd/Shepard et al. (~1964) — extended Lewin’s equation to teams.
  • McGrath & Larson — the four things a team does.
  • James Reason — the Swiss cheese model of accident causation.
  • Daniel Kahneman — System 1 / System 2 thinking.
  • Sandra — Lufthansa purser and CRM instructor.
  • Andreas — pilot friend.
  • The anesthesiologist friend — head of anesthesiology & emergency medicine; former Berlin rescue chief; trained Pelrine in CRM.
  • Organizations/domains named: NASA (origin of CRM), aviation (Lufthansa, Swiss), Formula 1 (Ferrari), football (Swiss national team, FC Basel), medicine/ER, SAP (first Budapest Scrum training), eBay Amsterdam (Pelrine as CTO).
  • Concepts/tools: Crew Resource Management (CRM), Stroop test, cognitive overload/tunneling, fixation errors, Swiss cheese model, 10-for-10, FORDEC, SBAR, challenge/response, Extreme Programming (XP), psychological safety.
  • Examples: Finnish reindeer reflective antlers, Swiss pharmacy QR/barcode double-check.

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


Profile picture

Written by Tony Vo father, husband, son and software developer Twitter