What It Actually Is

Amy Edmondson's definition is precise and worth quoting exactly: psychological safety is "a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes." It is a property of a team, not an individual. It is a shared belief about what is safe to do in this group.

That definition is narrow enough to be useful. Notice what it does not say.

It does not say that people feel comfortable. Comfort is about the absence of challenge. Psychological safety is compatible with - and in fact requires - high standards and hard feedback. A team can have high psychological safety and still have brutal code reviews, direct performance conversations, and unambiguous accountability for outcomes.

It does not say that people agree. Psychological safety enables disagreement. When people feel safe to challenge ideas, you get better decisions, not consensus. Confusing psychological safety with harmony is one of the most damaging misreadings of the concept.

It does not say that people feel good. A team can have high psychological safety and low morale - if, for example, the business context is genuinely difficult. What psychological safety provides is the conditions for honest conversation about that difficulty, rather than silent disengagement.

What It Is Not

The confusion is not trivial. Leaders who think psychological safety means being nice will try to eliminate friction and conflict, producing teams where nobody disagrees, nobody surfaces problems early, and everyone smiles in meetings and fixes things quietly behind the scenes. This is the opposite of what Edmondson's research describes.

The Evidence

Project Aristotle

Google's Project Aristotle was a two-year study launched in 2012 to identify what made their highest-performing teams effective. The hypothesis going in was that the composition of the team would matter most - the right mix of skills, experience, and personality types.

The finding was different. Composition mattered much less than the norms of the group - how the team interacted. And the most powerful predictor of team effectiveness was psychological safety. Teams where members felt safe to take interpersonal risks consistently outperformed teams where they did not, regardless of individual capability.

The other factors that mattered were dependability, structure and clarity, meaning, and impact - but psychological safety was the foundation. Without it, the other conditions could not establish themselves.

Edmondson's Medical Team Research

Edmondson's original research context was hospital units. The counter-intuitive finding: the units with the highest psychological safety reported the most errors. The initial reaction was that these were worse teams. The actual finding was that they were better teams - safer environments produced more error reporting, which enabled learning and prevention. The low-safety units had the same rate of errors but a much lower rate of reporting.

This has direct application to engineering teams. In low-safety environments:

• Bugs are fixed quietly without post-mortems.
• Outages are blamed on infrastructure rather than process failures.
• Production incidents are cleaned up before leadership finds out.
• Blockers are hidden until they become crises.

In high-safety environments, the same volume of problems becomes visible earlier and gets addressed more systematically. The team looks messier from the outside - more reported failures, more uncomfortable conversations - but it is actually functioning better.

The Link to Learning, Innovation, and Retention

The research connections are consistent:

Learning - learning requires admitting what you do not know. In low-safety environments, admitting ignorance is risky. People pretend to understand rather than ask questions. Knowledge gaps persist.

Innovation - innovation requires proposing ideas that might be wrong. In low-safety environments, the cost of a bad idea is social humiliation. People stop proposing ideas. Incremental thinking dominates.

Error correction - mistakes get reported and fixed when reporting is safe. In low-safety environments, the cost of admitting a mistake exceeds the cost of hiding it. Mistakes compound.

Retention - people who feel unsafe do not stay. The best engineers - who have the most options - leave first. The ones who stay are either the most resilient or the most risk-averse.

High Safety, High Standards

The most important analytical tool for understanding psychological safety is a simple two-by-two:

The Comfort Zone

High safety with low standards produces teams that are pleasant to work in and produce unremarkable work. People feel safe but do not feel challenged. Standards drift. Nobody calls out poor work because the social cost of doing so feels disproportionate to the gain.

This is where leaders who mistake psychological safety for niceness end up. They create a team where everyone feels good and the work is mediocre.

The Anxiety Zone

Low safety with high standards produces exactly what you would expect: anxiety. People are held to high standards but feel unsafe raising problems, admitting failure, or proposing alternatives. The result is a combination of stress, compliance, and suppressed creativity. Engineers do what they are told, hide mistakes, and leave for somewhere better as soon as they can.

This is the "brilliant but bruising" engineering culture that many high-output organisations accidentally create. The output looks good until the people start leaving.

The Apathy Zone

Low safety with low standards is the most dysfunctional quadrant. Nobody cares, nobody feels safe, nobody takes risks, nothing improves. This is where teams end up after the best people have left and the remaining culture has calcified.

The Learning Zone

High safety with high standards is where sustainable high performance lives. People take risks because the cost of failure is learning, not punishment. Standards are clear and enforced because the feedback environment is honest. Problems surface early because raising problems is safe. Disagreement is productive because challenging ideas does not mean attacking people.

The leader's job is to manage both axes simultaneously. Raising standards without raising safety produces anxiety. Raising safety without raising standards produces comfort. The combination is non-trivial and requires sustained, consistent behaviour.

How Leaders Create It

Psychological safety is not an HR programme or a value statement. It is built through specific, repeated behaviours by leaders. The team infers what is safe from what they observe, not from what they are told.

Modelling Vulnerability

When a leader says "I don't know" without apparent discomfort, they signal that not knowing is acceptable. When a leader says "I got that wrong - here's what I've learned from it," they signal that mistakes are survivable. When a leader asks for help, they signal that asking for help is normal.

The alternative - the leader who always has an answer, never admits uncertainty, and frames mistakes as other people's problems - signals clearly that the same is expected of the team. People adapt. They stop admitting what they do not know.

Specific practice: In your next team meeting, name something you are uncertain about. Not vaguely - specifically. "I'm not confident we've thought through the failure modes on the caching layer. I want to think about this more before we commit." Watch how the team responds over time.

Responding Well to Bad News

The most important moment for psychological safety is the moment when someone brings bad news. Not an abstract aspiration to bring bad news - actual bad news, right now, when it is inconvenient.

If your response to bad news is calm, curious, and focused on understanding, you are building safety. If your response involves visible frustration, blame-seeking, or pressure to find someone responsible, you are destroying it - regardless of what you say afterwards about your door always being open.

The test is simple: after the last time someone told you about a significant problem, what did that person do next? Did they tell you about the next problem earlier? Or did they sit on the next problem longer before surfacing it?

Specific practice: When someone surfaces a problem, your first question should be about the situation, not the person. "Tell me more about what you're seeing" is better than "How did this happen?" The first is curiosity; the second is blame, even when it is not intended that way.

Separating the Person from the Idea

Challenging an idea is not challenging a person. But in many team environments, the two are conflated - the person who proposed an idea takes criticism of the idea personally, and others learn that proposing ideas creates personal risk.

Leaders who model the separation - "I think there's a problem with this approach, not with your thinking" - build teams that can have harder conversations about technical decisions without it becoming personal.

Specific practice: When giving feedback on technical work, make the distinction explicit. "I want to push back on the architectural choice here - not on the work itself, which is solid." This sounds pedantic when you first do it. Over time it changes the norms.

Rewarding Honesty, Not Just Success

When only successes are celebrated, the incentive is to hide failures. When honest surfacing of problems is explicitly valued - "I'm glad you raised this early" - the incentive shifts.

This means that the engineer who catches a problem in review deserves as much recognition as the engineer who shipped the feature. The person who identifies a gap in the approach during planning is doing as much value-added work as the person who has the shiny solution.

How Leaders Destroy It

Leaders destroy psychological safety through specific, repeated behaviours - usually without realising it. The damage is cumulative. Each incident adds evidence to the team's model of what happens when you speak up.

Shooting the Messenger

When someone raises a problem and the response is to question why they did not raise it sooner, why they let it get this far, or what they were doing while this was building up - the actual message received is: raising problems creates personal risk.

The fact that the leader did not intend this is irrelevant. What the team observes is that the person who raised the problem is now in an uncomfortable conversation. The rational response is to raise fewer problems.

Public Criticism

Criticising individuals in team settings - in a stand-up, in a meeting, in a review - is one of the fastest ways to reduce psychological safety for the entire team. Not just for the person being criticised. For everyone watching.

The observers are asking: if this is what happens when someone makes a mistake, what is the risk that this happens to me?

Specific behaviour to eliminate: Correcting technical decisions in team settings in a way that implies the person making the decision was careless or incompetent. Even if the decision was poor, this is a conversation to have privately, not publicly.

Inconsistency

Safety depends on predictability. If some people get supportive responses to failures and others get blamed, the team cannot build a reliable model of what is safe. They default to the worst case - assuming that any mistake might be the one that gets the punishing response.

Inconsistency is particularly damaging when it tracks identity dimensions - different people receiving different responses based on seniority, gender, background, or personality type. This signals clearly that safety is conditional, not structural.

Favouritism

When some people's ideas are received with curiosity and others' with scepticism, when some people are included in decisions and others are not, when some people's concerns are acted on and others' are dismissed - the team learns that psychological safety is not a property of the group. It is distributed unevenly, and they learn quickly where they sit.

Impatience With Questions

Questions signal that someone does not know something. In a high-safety environment, not knowing something and asking about it is unremarkable - it is just how you get information. In a low-safety environment, asking a question reveals ignorance and creates risk.

Leaders who respond to questions with visible impatience, or who answer questions in a way that implies the question was obvious, are training the team not to ask. The long-term cost is a team that pretends to understand things it does not, implements based on assumptions, and discovers the gaps late.

How to Measure It

Edmondson's 7-Item Scale

The most validated measurement tool is Edmondson's seven-item scale, rated on a five-point agreement scale:

1. If you make a mistake on this team, it is often held against you.
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.
4. It is safe to take a risk on this team.
5. It is difficult to ask other members of this team for help.
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 utilised.

Items 1, 3, and 5 are reverse-scored. The mean provides a team-level score. Run this quarterly or after significant changes to team composition or leadership.

The more important use of this scale is not the absolute number - it is tracking changes over time and comparing responses across subgroups within the team.

Behavioural Indicators in Engineering Teams

The following are observable signals of low psychological safety - they do not require a survey:

Nobody raises blockers in standups. People report what they did yesterday and what they are doing today. Problems are invisible. This is not because there are no problems - it is because raising a problem in a group setting feels risky.

Post-mortems produce only surface findings. The incident report says "the deployment pipeline was not configured correctly" but does not ask why, does not name systemic pressures, does not acknowledge that the underlying problem had been seen before. The real root causes are socially unsafe to name.

Nobody speaks in refinement or architecture sessions. The lead speaks, others listen, a few nod. If you want to find out what the team actually thinks, check the conversations happening in Slack after the meeting.

"Safe" estimates - always optimistic, never challenged. Engineers pad estimates not to deceive but to create buffer against failure. In low-safety environments, being wrong about a timeline is risky. So estimates become defensive rather than honest.

Incidents are cleaned up quietly. The team fixes production problems without escalating because they have learned that escalating creates more uncomfortable conversation than the problem itself.

Calibrating Your Read

Ask yourself these questions honestly:

• When was the last time someone told you about a problem before it became a crisis?
• When was the last time someone disagreed with you directly in a meeting?
• When was the last time someone said "I don't know" without apologising for it?
• When was the last time a post-mortem named a systemic issue and you acted on it?

The pattern of answers tells you more than a survey.

Building It Over Time

Psychological safety is not created by a team offsite, a vulnerability exercise, or an announcement that "this is now a safe team." It is built through consistent behaviour over time, and it is fragile - it can be significantly damaged by a single high-visibility incident that contradicts the norm.

The Starting Point: Acknowledge the Current State

If your team has low psychological safety - or you suspect it does - the worst move is to pretend otherwise or to declare it fixed. The best starting point is honesty: "I think we have work to do to create an environment where it feels safe to raise problems and take risks. I'm going to focus on that."

Then behave consistently with the statement.

The Mechanism: Small Consistent Signals

Safety is built through the accumulation of small, consistent signals over time. The leader who responds well to bad news, every time. The leader who admits uncertainty, regularly. The leader who challenges ideas without challenging people, visibly and repeatedly.

The calculation the team is doing - consciously or not - is: what is the pattern of responses when people speak up? If the pattern is consistently positive over many data points, safety builds. If the pattern is inconsistent, it does not.

Recovering When It Has Been Damaged

Safety can be damaged by a significant incident - a public reprimand, a visible scapegoating, a leadership change that produced anxiety. Recovery is harder than building from scratch because the team has updated evidence that speaking up is dangerous.

Recovery requires:

1. Explicit acknowledgement that something happened that reduced safety - not vague, specific.
2. A visible change in behaviour, sustained over time.
3. Time - probably more time than feels reasonable.

What does not work: a single conversation where you say "I know I handled that badly, but going forward..." The team has updated their model. They will need many data points of new behaviour before they revise it.

Common Failures

Confusing Psychological Safety With No Accountability

The most damaging misreading in engineering organisations: leaders who interpret "psychological safety" as "we can't hold people accountable because that creates fear." This gets it exactly backwards.

Psychological safety is the condition under which accountability is possible. When it is safe to admit mistakes, accountability conversations can be honest and productive. When it is not safe, people become defensive, hide information, and compliance replaces ownership.

High accountability and high psychological safety are not in tension. They are mutually reinforcing. The engineer who knows mistakes will not be punished but will be examined is in a position to be genuinely accountable - to own what happened and contribute to fixing it. The engineer who fears punishment is in survival mode.

Leaders Who Say "Bring Me Problems" and React Badly

This is the most common failure pattern, and it is catastrophic because it is so visible. The leader states clearly that they want to know about problems early. The first time someone does this, the response is not calm and curious - it is frustrated, or blame-seeking, or politically inconvenient.

The team remembers this for a long time. The gap between what the leader says and what the leader does is the thing they act on. Every subsequent statement about wanting to know about problems early is discounted against the observation of what actually happened.

The fix is not better communication. It is different behaviour.

Culture Surveys That Measure Nothing

The 48-question engagement survey sent out annually, analysed at an aggregate level, presented in a slide to the team with an action plan that never changes anything. The team fills it in because they are asked to. Nothing changes. The survey becomes a ritual that actively undermines safety because it demonstrates that raising issues through legitimate channels produces no response.

If you run a survey, you must do something visible with the results. If you cannot commit to that, do not run the survey.

Declaring It Done

"We've worked on psychological safety a lot this year." Safety is not a project with a completion date. It is a property of the environment, maintained by ongoing behaviour. The team that felt safe six months ago, with a different leader or under different pressures, may not feel safe now. It needs ongoing attention, not a one-time intervention.

Connection to Your Operating Model

Psychological safety is not a people initiative separate from engineering practice. It is the conditions under which good engineering happens.

When safety is low:

• Engineers do not raise technical concerns early, so problems compound.
• Post-mortems produce superficial findings, so systemic issues repeat.
• Knowledge is not shared openly, so capability is siloed.
• Risk-taking is avoided, so technical improvement stagnates.
• The best people leave because they have options.

When safety is high:

• Problems surface early when they are cheap to fix.
• Learning is shared openly across the team.
• Technical challenges are examined honestly, not politically.
• Engineers take the risks that produce improvement and innovation.
• People stay because the environment is worth staying in.

The operating model in this framework - distributed decision-making, high autonomy, continuous improvement, honest feedback loops - cannot function in a low-safety environment. Every structural element depends on people being willing to speak up, admit what they do not know, and take interpersonal risks.

If you invest in one thing as a leader, invest in this.

Psychological Safety in Specific Contexts

The principles are consistent, but the application varies by context. Engineering teams face a number of situations where psychological safety is particularly under pressure.

During Incidents

Incidents are the highest-stakes test of psychological safety in an engineering team. When a system is down and pressure is high, the natural instinct is to find someone responsible quickly. This is exactly the wrong instinct if you care about learning.

A team with high psychological safety during incidents:

• Reports the incident internally as soon as it is identified, not after it is fixed
• Communicates honestly about uncertainty during diagnosis, not only when confident
• Runs post-mortems that examine process and system failures, not human failures
• Names the real root causes, including systemic pressures, not just the immediate technical trigger
• Follows up on post-mortem actions rather than treating the document as the end point

A team with low psychological safety during incidents:

• Sits on incidents until they have a diagnosis or fix, to minimise exposure
• Runs post-mortems that produce surface technical findings and avoid naming the real contributors
• Identifies a proximate cause quickly and closes the post-mortem before the systemic questions are examined
• Treats the on-call engineer as personally responsible for the failure, rather than as the person who happened to be holding the pager

The post-mortem is the most visible artifact of your safety culture in the engineering context. If your post-mortems are honest, systemic, and followed through on - this signals that the environment is safe enough for honesty. If they are political and surface-level, this signals that honesty carries cost.

During Code Review

Code review is a daily psychological safety test. The question every engineer is implicitly asking when they submit a pull request is: "Is it safe to get this wrong?"

In high-safety environments, code review is a collaborative process. Reviewers ask questions more than they make declarations. Authors explain their reasoning and invite challenge. Disagreements are discussed and resolved through argument. Neither submitting a flawed PR nor asking "why did you do it this way?" carries personal cost.

In low-safety environments, code review becomes a social game. Submitters hedge their PRs with excessive inline comments explaining their choices pre-emptively. Reviewers are diplomatically vague about problems to avoid conflict. Or the opposite - reviews become opportunities for demonstrating superiority, with aggressive comments that teach the submitter to be defensive rather than curious next time.

The leader's role: Review how you behave as a reviewer, and how others review each other. The tone and approach of senior engineers in code review sets the standard. Direct your attention there.

During Planning and Estimation

Planning sessions are where psychological safety shows up as estimation honesty. Engineers in low-safety environments do not give honest estimates. They give safe estimates - padded enough to survive the expected pressure to commit to less, or optimistic enough to satisfy the manager who pushes back on anything that seems slow.

The result is planning based on numbers that do not represent anyone's honest assessment, which means the plan is not useful as a management tool.

In high-safety environments, engineers can say "I don't know how long this will take - there's a lot of uncertainty in this approach" without that being treated as a competence failure. Uncertainty is a legitimate input to planning, not a problem to be hidden.

The Leader's Own Psychological Safety

Most discussions of psychological safety focus on what the leader creates for the team. The leader's own psychological safety - within their organisation - is equally important and receives less attention.

Leaders who feel psychologically unsafe within their own organisation:

• Share sanitised information with their teams ("I can't tell you more than this")
• Make defensive decisions designed to protect their own position rather than serve the team
• Do not challenge senior leaders' decisions even when they believe them to be wrong
• Manage up in a way that prioritises looking good over being accurate

The effect on the team is significant. A leader who does not feel safe being honest within their organisation cannot fully model the safety they want to create for their team. The team picks up the dissonance.

If you are a senior leader: creating psychological safety for your engineering managers is as important as expecting them to create it for their teams. The questions to ask:

• When an engineering manager brings you a problem, what is your actual response?
• When an engineering manager disagrees with a direction you have set, how do you respond?
• When something goes wrong in a team, do the managers in that team feel safe being honest with you about the causes?

The chain runs all the way up. Safety is either present throughout or it is not fully present at any level.

Sustaining Psychological Safety Through Change

Organisational change - restructures, leadership transitions, strategy shifts, layoffs - is the most significant threat to psychological safety. Change introduces uncertainty, and uncertainty makes people risk-averse. In a risk-averse environment, people stop speaking up.

What Happens to Safety During Change

When a team learns that colleagues have been laid off, that the organisational structure is changing, or that leadership is changing, the rational response is to reduce risk-taking until the new environment is better understood. This is self-protective and understandable.

The problem is that this is exactly when honest communication, problem-surfacing, and honest risk assessment are most needed. A team that goes quiet during a change is a team that is hiding information that leadership needs to navigate the change well.

What Leaders Can Do

Communicate more, not less, during uncertainty. The instinct is to wait until you have complete information. The cost of waiting is that the team defaults to worst-case interpretations of the silence. Regular brief communications - even "no news yet, still expecting to hear by end of week" - are significantly more useful than silence.

Be explicit about what has changed for the team and what has not. "The team structure is changing but the team's mission is unchanged" gives people something stable to hold. "I don't know what this means for you yet, and I'll tell you as soon as I do" is honest and more reassuring than pretending to certainty you don't have.

Do not paper over the difficult emotions. If the change is genuinely difficult - if people are anxious, if someone has left the team, if the direction has shifted in a way that feels disorienting - acknowledging that directly is more useful than positivity that nobody believes. "I know this is a difficult period. I think we'll come through it well, and I also understand if it doesn't feel that way right now."

Watch for safety indicators closely after change. The signals that safety has degraded - quiet retrospectives, less speaking up in meetings, sanitised status updates - are worth monitoring more closely in the months following significant change. Act on them early.

Practical Experiments for Leaders

Reading about psychological safety is significantly easier than building it. The following are concrete experiments - specific changes to behaviour or structure that can be made in a short time frame and that have observable effects.

These are experiments, not programmes. Try them, observe the effect, and iterate.

Experiment 1: The Failure Debrief

What to do: In your next team meeting, share something you got wrong recently - specifically, what happened, what you believed at the time, and what you learned. Not vaguely - a specific decision, with specific reasoning, and a specific update to your thinking.

What to observe: How does the team respond? Do they engage? Do others share similar experiences? Does the energy in the room change?

What it signals: That admitting mistakes is normal and does not carry personal cost. That the leader is a person who learns, not a person who is always right.

Time frame for observable effect: One to four sessions.

Experiment 2: Rewarding the Problem-Raiser

What to do: The next time someone raises a problem - a blocker, a risk, a mistake, a concern - respond with explicit appreciation before anything else. "I'm really glad you raised this. Tell me more." Then act on the problem.

What to observe: Does the person seem surprised? Does anyone else in the team notice and comment? Does the same person raise the next problem faster?

What it signals: That raising problems is valued, not penalised. This is the single most direct signal you can send about what is safe in your team.

Time frame for observable effect: Two to six weeks of consistent repetition.

Experiment 3: The Genuine Question

What to do: In your next technical discussion, ask a question to which you genuinely do not know the answer - and make your uncertainty visible. "I'm not sure how the load balancer handles this edge case - does anyone know?"

What to observe: How does the team respond to the leader not knowing? Is there surprise? Does it open up others to share uncertainty?

What it signals: That not knowing things is acceptable. That the leader is a learner, not an authority to whom all ignorance must be hidden.

Time frame for observable effect: Observable in the session.

Experiment 4: The Retrospective Safety Check

What to do: At the start of your next retrospective, ask everyone to rate anonymously (1-5) how safe they feel raising concerns in this team. Do not discuss the scores in the session - just note the distribution and revisit it in three months.

What to observe: What is the range? Are there outliers at the low end? Does the distribution change over three months?

What it signals to the team: That you are paying attention to safety as a property of the environment worth measuring and improving.

Time frame for observable effect: Use as a longitudinal measure over two to four quarters.

The Language of Psychological Safety

Language is a mechanism through which safety is built or eroded, in specific, observable ways. The words leaders choose in common situations send consistent signals about what is safe.

Language That Builds Safety

Language That Erodes Safety

The list is not exhaustive. The principle is: language that focuses on curiosity and forward movement builds safety. Language that focuses on blame, impatience, and authority erodes it.

Many of the eroding patterns are habits. They happen fast, before the leader has consciously processed the situation. Slowing down - taking a breath before responding to unexpected news or uncomfortable information - is one of the most effective safety-building practices available, precisely because it creates space to choose language deliberately rather than reactively.