January 2026 10 min read Opinion + Source Reference

Psychological Safety has completed the full journey from research concept to corporate buzzword in under a decade. It now appears in team charters, leadership competency frameworks, and HR training programmes worldwide. Most of the organisations using the term have not created the thing it describes. Some of them have made it worse by trying.


The Hook: The Term Everyone Uses and Nobody Understands

Ask a room of managers to define Psychological Safety and you will get a range of answers. “It means people feel comfortable speaking up.” “It means we have a blame-free culture.” “It means everyone’s opinion is valued.” These answers are not wrong, exactly. But they miss the precision of what the research actually describes – and that precision matters, because without it, attempts to create psychological safety often create something else entirely.


The Reality: What the Research Actually Says

The concept of psychological safety was developed by Harvard Business School professor Amy Edmondson, whose research in the 1990s on medical teams produced a counterintuitive finding: the teams that reported the most errors were not the worst-performing teams. They were the best-performing ones. The high-performing teams were not making more mistakes – they were reporting them more honestly. The difference was the team climate: in high-performing teams, people believed it was safe to speak up about problems without fear of punishment or humiliation.

Edmondson defined psychological safety as “a shared belief held by members of a team that the team is safe for interpersonal risk-taking.” The key words are shared, interpersonal, and risk. It is not about comfort. It is not about harmony. It is about the specific belief that you can take interpersonal risks – speak up, disagree, admit ignorance, flag a problem – without negative consequences to your standing in the group.

The Google Reinforcement

Psychological safety reached mainstream business awareness through Google’s Project Aristotle – a multi-year research project that studied 180 Google teams to identify what made some teams significantly more effective than others. The finding, published in 2016, was striking in its clarity: psychological safety was by far the most important factor in team effectiveness, more important than individual talent, team composition, or any other variable the researchers measured.

Google’s definition aligned with Edmondson’s: psychological safety was the belief that the team would not embarrass, reject, or punish you for speaking up. Teams with high psychological safety performed better on virtually every measure the research tracked.

Worth reading: Google’s Project Aristotle research is available at rework.withgoogle.com. Amy Edmondson’s book “The Fearless Organisation” (2018) is the most comprehensive treatment of the research and its organisational implications. Both are worth reading before designing any intervention intended to improve psychological safety.


The Checksum: What Psychological Safety Is Not

The gap between the research concept and its organisational application is significant. Here are the most common misapplications.

It Is Not Niceness

The most common misapplication. Organisations that conflate psychological safety with a pleasant, conflict-free environment create teams where difficult conversations do not happen – which is the opposite of what psychological safety enables. High psychological safety does not mean everyone agrees or that disagreements do not occur. It means disagreements can be expressed honestly without personal consequences.

A team where everyone is polite and nobody challenges each other is not psychologically safe. It is psychologically comfortable – which is a very different thing. Comfort preserves the status quo. Safety enables honest challenge of it.

It Is Not Achieved by a Workshop

The second most common misapplication. Organisations run a half-day workshop on psychological safety, create team ground rules, and consider the problem addressed. The workshop may be well-facilitated and the ground rules may be thoughtfully written. They will not, by themselves, create psychological safety.

Psychological safety is built through accumulated experience of what actually happens when people take interpersonal risks. If someone speaks up in a meeting and is dismissed, interrupted, or later excluded from decisions, that experience is more powerful than any ground rule. If someone admits a mistake and the response is supportive rather than punitive, that experience builds the belief that risk-taking is safe. No workshop creates that belief. Only consistent behaviour over time does.

It Is Not the Leader’s Job to Make People Feel Safe

Closer to the truth, but still imprecise. The leader’s job is not to make people feel safe – it is to behave in ways that make it genuinely safe to take interpersonal risks. These sound similar. They are not.

Making people feel safe can be achieved through reassurance, through positive framing, through creating an atmosphere of warmth. This produces comfort, not safety. Genuine psychological safety requires leaders to actually respond without punishment or humiliation when people take interpersonal risks. The behaviour, not the intention, is what matters. And the behaviour has to be consistent – one instance of a leader responding defensively to criticism can undo months of trust-building.

“Psychological safety is not built in workshops. It is built in the moments after someone says something difficult. What happens in those moments is what the team actually learns about safety.” Markus – agile-checksum.com


Why It Matters for Agile Teams Specifically

Psychological safety is not an Agile-specific concept. But it is particularly critical for Agile teams because every Agile ceremony assumes it exists.

  • Daily Standups require team members to honestly report blockers and struggles – which requires believing that honest reporting will not be used against them.
  • Sprint Reviews require honest feedback from stakeholders – which requires stakeholders to believe their critical feedback is welcome rather than threatening.
  • Retrospectives require teams to surface real problems rather than safe ones – which requires a genuine belief that raising problems leads to resolution rather than blame.
  • Sprint Planning requires honest estimation rather than optimistic commitment – which requires team members to believe that saying “I don’t know” or “this is more complex than it looks” is acceptable.

Run any of these ceremonies in a low-psychological-safety environment and you get the theater versions described elsewhere in this blog. The ceremonies happen. The honest exchange they depend on does not. The format is correct. The substance is missing.


Real-World Examples: The Gap Between Intent and Reality

The Blame-Free Culture That Was Not

A technology company had “blame-free culture” as one of their stated values. It appeared on the company website, in the employee handbook, and in the onboarding programme. A post-incident review process had been designed specifically to identify systemic causes rather than individual fault.

In practice, when a significant production incident occurred, the post-incident review was thorough and well-facilitated. The systemic causes were identified. The recommendations were documented. And then, in a separate conversation that was never formally acknowledged, the engineer whose code change had triggered the incident received feedback at their next performance review that cited “poor judgement” as a development area.

Nobody announced that the blame-free culture was a fiction. Nobody needed to. The team learned the lesson without being taught it: the formal process was blame-free. The informal consequences were not. People adjusted their behaviour accordingly.

The Retrospective That Got Real

A Scrum team I coached had been running retrospectives for six months with consistently shallow output. The problems discussed were real but minor. The significant issues – a dysfunctional relationship between the tech lead and the Product Owner, a workload that was genuinely unsustainable, a technical architecture decision that the team believed was wrong but had been imposed from above – were not surfaced.

In the seventh retrospective, I changed the format. Instead of the usual structured exercise, I asked one question: “What is the one thing you would fix about how this team works if you knew there would be no consequences for saying it?” I left the room for ten minutes and asked them to write their answers individually before sharing.

The answers named every significant problem the team had been avoiding for six months. The tech lead and Product Owner relationship. The unsustainable workload. The architectural decision. In subsequent weeks, with careful facilitation, those issues were addressed – not perfectly, not without difficulty, but addressed. The team’s performance improved measurably in the following quarter.

What changed was not the team’s situation. It was the temporary creation of a safer condition for honest disclosure. The question “if there were no consequences” explicitly suspended the interpersonal risk for one conversation. The team used the opening.

The Leader Who Changed the Dynamic

A department head at an insurance company had a team with consistently low engagement scores and high turnover. Retrospectives produced surface-level outputs. One-to-ones were polite and uninformative. She could not identify the source of the problem.

On the advice of an executive coach, she tried an experiment. In the next all-hands meeting, she described a significant strategic decision she had made the previous year that had not produced the expected outcomes. She explained what she had been thinking, what had gone wrong, and what she had learned. She did not minimise the error or reframe it as a learning opportunity in a way that softened the accountability. She was specific and honest about having been wrong.

The effect on the team was significant and rapid. Within two weeks, she received more honest feedback in one-to-ones than she had in the previous six months. The retrospectives in the following sprints surfaced problems that had apparently been present for over a year. The engagement scores improved measurably within one quarter.

Nothing structural had changed. One act of genuine leadership vulnerability had demonstrated, more powerfully than any workshop could, that honest disclosure was safe.


How to Actually Build It

There is no shortcut. But there are conditions that consistently support the development of genuine psychological safety.

  • Model the behaviour you want to see. Leaders who admit uncertainty, acknowledge mistakes, and express genuine curiosity about team perspectives demonstrate what safety looks like in practice. This is the single most powerful lever available to leaders.
  • Respond to bad news with curiosity, not blame. The response to a mistake, a missed target, or a delivered piece of bad news is more powerful than any stated policy. Teams watch what actually happens. Respond with “what happened and what can we learn?” rather than “whose fault is this and what are the consequences?”
  • Make it safe to disagree with you specifically. General encouragement of disagreement is less powerful than visibly welcoming disagreement with your own positions. When a team member challenges a leader’s idea and the leader engages with the challenge seriously rather than defending the original position, that interaction is observed and remembered by everyone in the room.
  • Follow through on what is raised. People raise issues when they believe raising issues leads somewhere. If problems surfaced in retrospectives, one-to-ones, or team meetings are consistently acknowledged and then forgotten, the implicit message is that raising them was not worth the risk.

The measurement question: Psychological safety can be measured. Edmondson’s original research used a seven-item scale that is widely available. Team health check tools like the Spotify model include psychological safety dimensions. If you want to know whether your interventions are working, measure the baseline, intervene, and measure again. Intuition about team climate is unreliable. Data is better.


The Takeaway: Real, Measurable, and Non-Negotiable

Psychological safety is not a buzzword. It is one of the most rigorously researched concepts in organisational behaviour, with consistent evidence linking it to team performance, innovation, learning, and wellbeing. The organisations that treat it as a buzzword – that add it to their values list without changing any of the leadership behaviours that determine whether it exists – are not just failing to create it. They are, in some cases, actively destroying trust by claiming to have something they do not.

The organisations that take it seriously – that understand it as a product of consistent leadership behaviour rather than a workshop outcome – tend to build teams that are more honest, more adaptive, and more effective over time. The investment is not in programmes or tools. It is in the daily, repeated choice to respond to interpersonal risk-taking with curiosity and support rather than defensiveness and consequence.

Run the checksum on your team’s psychological safety:

  1. When was the last time someone on your team disagreed with a senior leader in a meeting? What happened immediately after?
  2. When was the last time a mistake was discussed openly in your team without any element of blame or consequence? Who initiated that conversation?
  3. Does your retrospective surface the same kind of problem every time – or does it occasionally produce something surprising that suggests people are saying things they have not said before?

The answers will tell you more about your team’s psychological safety than any survey tool. They will also tell you where to focus if you want to build it.


Glossary Terms Used in This Article

  • Psychological Safety – The shared belief that it is safe to take interpersonal risks within a team.
  • Retrospective – A Scrum ceremony for inspecting the sprint and identifying improvements.
  • Agile Transformation – The process by which an organisation attempts to adopt Agile values and practices at scale.
  • Servant Leader – A leadership philosophy focused on serving the team rather than directing it.
  • Daily Standup – A 15-minute daily event for the team to inspect progress and adapt their plan.

Markus Philipp

Senior Scrum Master · 20+ years in IT · 16 years backend dev

I verify whether what passes for Agile still matches the original intent. Enterprise context. No theory.

About the Author

Newsletter

No Fluff. Just Real Agile.

Straight to your inbox. No buzz, no spam.

No spam. Unsubscribe anytime.