Every engineering team has a few questions that tell you more about its health than any dashboard. Does the junior engineer say "I do not understand this design" in the review meeting, or nod along? When the on-call engineer realizes at 2 a.m. that their own change caused the outage, do they say so immediately, or spend twenty minutes hoping it was something else? When the plan is wrong, does anyone tell the person who made it?

The answer depends less on the people than on what happened the last time someone spoke up. That is psychological safety: the shared belief that it is safe to take interpersonal risks in this team. It is one of the most studied ideas in organizational psychology, and one of the most misunderstood.

This cheatsheet is for engineering leads and managers. It covers what psychological safety is (and the common misreadings), what the evidence says, how to measure it, and the specific behaviors that build or destroy it in meetings, code reviews, incidents and one-on-ones.

1. What it is, and what it is not

Amy Edmondson, who introduced the team-level concept in a 1999 study, defines psychological safety as "a shared belief held by members of a team that the team is safe for interpersonal risk taking."

Interpersonal risks are the everyday ones: asking a question that might sound naive, admitting a mistake, disagreeing with someone senior, proposing an idea that might be bad, asking for help.

It is It is not
Safe to raise problems, questions and mistakes Being nice all the time, or avoiding conflict
Candor, including uncomfortable disagreement Lower standards or less accountability
A property of the team climate A personality trait of individuals
Something built through repeated experience Something declared in a values document
Compatible with high pressure and high standards A guarantee that everyone agrees or feels comfortable

Safety and standards: the four zones

Edmondson pairs psychological safety with accountability for demanding goals:

Low standards High standards
High safety Comfort zone: pleasant, low effort, little learning Learning zone: candid, ambitious, high performing
Low safety Apathy zone: people do the minimum Anxiety zone: pressure plus fear, problems get hidden

Most leaders who worry that safety means "soft" are picturing the comfort zone. The target is the learning zone: high standards and the safety to say when you are not meeting them.

2. What the research says

Study What it found
Edmondson (1996, 1999), hospital units and manufacturing teams In an early hospital study, better-led units reported more medication errors, not because they made more, but because people felt able to report them. The 1999 study of 51 work teams in a manufacturing company linked team psychological safety to learning behavior (asking for feedback, discussing errors, experimenting), and learning behavior to performance.
Google's Project Aristotle (published 2015) Studied what made Google teams effective. Five dynamics stood out, and psychological safety was the most important, "the underpinning of the other four": dependability, structure and clarity, meaning, and impact. Who was on the team mattered less than how the team worked together.
Frazier et al. (2017), meta-analysis Across 136 independent samples (over 22,000 people and nearly 5,000 groups), psychological safety was associated with information sharing, learning behavior, engagement and task performance. Leader behaviors (supportive, inclusive leadership) and peer support were among its strongest antecedents.
Westrum (2004) and DORA research Westrum's typology classifies organizations as pathological, bureaucratic or generative by how they handle information. DORA's research on software teams finds that a generative, high-trust culture predicts software delivery and organizational performance.
Edmondson and Bransby (2023), review Two decades of research confirm psychological safety as a robust predictor of learning and performance, especially in complex, uncertain and interdependent work.

That last point matters for software. The more uncertain and interdependent the work, the more performance depends on people sharing what they know and what they got wrong. Software engineering is exactly that kind of work.

Westrum's culture types, applied to engineering

Pathological Bureaucratic Generative
Orientation Power Rules Performance
Messengers (bearers of bad news) Punished Neglected Trained
Responsibilities Shirked Narrow Risks are shared
Failure leads to Scapegoating Justice Inquiry
New ideas Crushed Lead to problems Implemented
Engineering example Incident review hunts for whoever to blame Incident review fills a template, nobody reads it Incident review finds system causes and the fixes get done

3. How to measure it

You cannot manage what you only guess at, and leaders are usually the last to know their team does not feel safe. People do not tell the boss "I am afraid to tell you things".

Edmondson's survey items

Edmondson's original scale uses seven statements, rated on agreement. Three are reverse-scored (R):

  1. If you make a mistake on this team, it is often held against you. (R)
  2. Members of this team are able to bring up problems and tough issues.
  3. People on this team sometimes reject others for being different. (R)
  4. It is safe to take a risk on this team.
  5. It is difficult to ask other members of this team for help. (R)
  6. No one on this team would deliberately act in a way that undermines my efforts.
  7. Working with members of this team, my unique skills and talents are valued and utilized.

Practical use: run it anonymously, on a team large enough that answers cannot be traced back (at least five or six people), and look at the spread and the trend, not just the average. A team average of 4 out of 5 with two people at 1 tells a different story from everyone at 4.

Behavioral signals (no survey needed)

Signal Healthy Warning
Questions in meetings Frequent, including "basic" ones Silence, then side conversations afterwards
Disagreement with the lead Happens openly, with reasons Never happens, or only in private
Incident reports People self-report their own mistakes quickly Causes are vague; "the system" did it, nobody did anything
Code review Authors ask for help, reviewers ask questions Rubber-stamping, or reviews used to score points
Estimates and status Bad news arrives early Projects are "on track" until suddenly very late
Retrospectives Concrete, sometimes uncomfortable topics Same safe topics every time, or no topics at all
Who speaks Spread across the team The same two or three senior voices

4. Leader behaviors that build it

Edmondson's practical advice for leaders comes down to three moves: frame the work, invite participation, respond productively.

Frame the work as a learning problem

  • Say explicitly that the work is uncertain: "We have never built this at this scale. We will get things wrong, and we need to hear about it early."
  • Distinguish kinds of failure. A preventable failure in routine work (skipping a checklist) is different from a complex failure (many factors lining up) and from an intelligent failure (a well-designed experiment that did not work). Treat them differently.
  • Set expectations: "Raising a risk early is part of the job, not a sign of weakness."

Invite participation

  • Admit your own fallibility first. "I might be missing something here. What am I not seeing?" A lead who never says "I was wrong" teaches the team never to say it either.
  • Ask real questions, not rhetorical ones. "What concerns do you have?" works better than "Any concerns?", which invites silence.
  • Ask the quiet people directly, and ask early, before the senior voices anchor the discussion. Round-robin and written input before discussion both help.
  • Create structures for dissent: pre-mortems ("imagine this project failed; why?"), a rotating devil's advocate, written design reviews where comments are expected.

Respond productively

This is where safety is actually built or destroyed: in the moment after someone takes a risk.

Someone... Destructive response Productive response
Admits a mistake Sigh, "how did that happen?", visible annoyance "Thanks for flagging it fast. What do we need to do now? Then let's look at how the system let it happen."
Asks a basic question "That's in the docs." Answer it, then fix the docs if others likely had the same question
Disagrees with you in a meeting Defend, dismiss, or move on "Say more. What would you do instead?"
Brings bad news about a deadline "We committed to this date." "Thank you for telling me now rather than later. What are the options?"
Proposes an idea that will not work Explain why it is wrong Explore it first; credit what is useful in it

The rule: the messenger is never punished for the message. If you remember one line from this post, make it that one.

5. Where it matters most in engineering

Incidents and postmortems

  • Run blameless postmortems: focus on how the system made the failure possible, not on who pressed the button. Google's SRE book describes blameless postmortem culture as assuming that everyone involved had good intentions and acted reasonably given the information they had.
  • Thank the person who self-reports. Publicly, if they are comfortable with it.
  • Follow through on action items. A postmortem whose fixes never ship teaches people that reporting is pointless.

Blameless does not mean consequence-free. Repeated, reckless disregard of agreed practices is a performance issue, and it is handled privately, separately from the learning review.

Code review

  • Review the code, not the person. "This function does three things" instead of "You always write huge functions".
  • Leads and seniors should request reviews from juniors and act on their comments. It shows that review is about the code, not about rank.
  • Normalize "I don't understand this part" as a valid review comment. Confusion is a finding.

Planning and estimates

  • Reward early bad news. The cost of a slipped date discovered in week two is a fraction of one discovered in the last week.
  • Separate estimates from commitments. If every estimate becomes a promise, people will pad estimates or hide slippage.

One-on-ones

  • Ask regularly: "What is something I could do differently?" and "What is something the team is not talking about?"
  • When you get feedback, the response is "thank you", not a defense. Act on at least some of it, visibly.

6. Why AI-assisted work raises the stakes

AI coding assistants and agents change the kinds of interpersonal risk engineers take every day:

  • "I don't understand this code." More code now arrives generated, and more of it is reviewed by people who did not write it. A team where admitting confusion feels risky will approve code nobody understands.
  • "The AI made a mistake I didn't catch." Errors in AI-assisted changes are often subtle. If reporting them feels like admitting incompetence, they get quietly patched instead of discussed, and the team never learns where the tools fail.
  • "I am not sure I should use AI for this." Some engineers worry about being seen as slow if they do not use AI; others about being seen as lazy if they do. Both need to be able to say so.
  • Experiments with new tools fail often. Teams that treat a failed tool experiment as an intelligent failure learn which practices work; teams that punish failure stop experimenting, or hide what they tried.

The leader's job is to make these statements normal: "I used an assistant for this part and I am not fully confident in the error handling" should be a welcome comment in a pull request, not a confession.

7. How leaders destroy safety without noticing

Behavior Message the team hears
Interrupting, finishing people's sentences Your input is not needed
Visible frustration at bad news Hide bad news
Asking "who did this?" first in an incident Self-reporting is dangerous
Praising heroics (the all-nighter that saved the release) The system is fine; individual sacrifice is how we cope
Deciding in private, then asking for "feedback" Opinions are theater
Sarcasm and jokes at someone's expense You could be next
Always having the answer Questions are for people who do not know things
Responding to criticism of a decision with your seniority Do not disagree with the boss
Only the same people get the interesting work Speaking up does not change anything

Most of these are not malicious. They come from time pressure and habit. That is why safety needs deliberate attention: the defaults of a busy lead tend to erode it.

8. A quick team check

Use this in a retro or a one-on-one, adapted to your team:

  1. When was the last time someone on this team said "I was wrong" in a meeting? Who was it?
  2. If you made a change that caused an incident, how would you expect people to react?
  3. Is there a topic we avoid in retrospectives?
  4. Who on the team do you hear least from in technical discussions? Why might that be?
  5. When you disagree with a decision from the lead, what do you do?

If the answer to the first question is "never" or "only the junior people", start with yourself.

Why this matters

  • Safety is about learning, not comfort. It is what lets a team find out what is wrong in time to fix it.
  • High standards and high safety together produce the learning zone. Either one alone does not.
  • Leaders shape it most, through how they respond the moment someone takes a risk.
  • Engineering is complex, interdependent work, exactly where the research shows safety matters most.
  • AI-assisted development adds new interpersonal risks: admitting confusion, reporting tool-caused mistakes, experimenting in public. Make those normal.

Final Thoughts

Psychological safety is not a program you roll out or a slide in the team charter. It is built one interaction at a time: the question you answered without irony, the mistake you thanked someone for reporting, the time you said "I was wrong" in front of the team.

It is also fragile. A single dismissive reaction to bad news can undo months of good intentions, because people remember what happened to the last messenger far better than what the values document says. The good news is that the levers are entirely in a lead's hands. Frame the work as learning, invite people in, and respond well when they speak up. Then do it again tomorrow.

Sources