Psychological Safety: Google's Secret to High-Performing Teams

Psychological Safety: Google's Secret to High-Performing Teams

Google invested two years and studied 180 teams. The question: What distinguishes the best teams from average ones?

The answer surprised even Google. It wasn't team composition. Not the number of senior engineers. Not the budget. The most important factor was psychological safety.

In this guide, you'll learn what psychological safety means, why it's especially critical in tech teams, and how to build it concretely.

Table of Contents

1. What is Psychological Safety?
2. Google's Project Aristotle
3. Why Tech Teams Are Especially Affected
4. The 4 Stages of Psychological Safety
5. Signs of Missing Safety
6. Concrete Measures for Leaders
7. Practices for the Team
8. Measurement and Improvement
9. FAQ

---

What is Psychological Safety?

Psychological safety means: Team members feel safe enough to take interpersonal risks.

Concretely, this means:

• Asking questions without looking stupid
• Admitting mistakes without being punished
• Sharing ideas without being rejected
• Giving feedback without fearing consequences

What It's NOT

Psychological safety is not:

• Always being nice to each other
• Avoiding conflicts
• Having no standards
• Accepting every idea

On the contrary: Psychological safety enables more honest, productive conflicts because nobody is afraid to speak their mind.

The Researcher Behind It

The concept was developed by Amy Edmondson (Harvard Business School). Her research shows that teams with high psychological safety:

• Learn more
• Innovate better
• Make fewer mistakes (paradoxically)
• Have higher employee retention

---

Google's Project Aristotle

The Study

In 2012, Google launched "Project Aristotle" - named after Aristotle's statement "The whole is greater than the sum of its parts."

The goal: Understand what makes perfect teams.

The method:

• 180+ teams analyzed
• Hundreds of variables tested
• Interviews with team members
• 2 years of research

The Surprising Results

What made no difference:

• Seniority of team members
• Introverted vs. extroverted
• Same interests outside of work
• Team size
• Location (co-located vs. remote)

What made the difference (in order of importance):

Rank	Factor	Description
1	Psychological Safety	Feeling safe to take risks
2	Dependability	Being able to rely on each other
3	Structure & Clarity	Clear roles, plans, and goals
4	Meaning	Work is personally meaningful
5	Impact	Belief that the work matters

The insight: Psychological Safety was by far the most important factor.

---

Why Tech Teams Are Especially Affected

The Impostor Factor

In the tech industry, impostor syndrome is widespread:

• 58% of tech professionals report it
• Constant change ("I don't know framework X")
• Comparison with others ("The senior knows everything")

Without psychological safety, impostor syndrome intensifies.

Code Review Anxiety

Code reviews can become toxic:

• Public criticism of code = criticism of the person
• Fear of asking "stupid" questions
• Hiding uncertainties

Meeting Dynamics

Typical problems:

• Only the loudest speak
• Junior devs stay silent
• Important concerns aren't raised
• Post-mortems become blame games

The Remote Challenge

Remote work exacerbates the problem:

• Less informal exchange
• Harder to read moods
• Isolation amplifies insecurity

---

The 4 Stages of Psychological Safety

Timothy Clark describes 4 stages that build upon each other:

Stage 1: Inclusion Safety

Means: I belong.

Signs: New team members are welcomed; differences are accepted; nobody is excluded.

Stage 2: Learner Safety

Means: I can learn and make mistakes.

Signs: Questions are welcomed; mistakes are seen as learning opportunities; knowledge is shared.

Stage 3: Contributor Safety

Means: I can contribute.

Signs: Ideas are heard; everyone has a voice in decisions; contributions are recognized.

Stage 4: Challenger Safety

Means: I can challenge the status quo.

Signs: Criticism of processes is welcome; leaders are open to feedback; innovation is encouraged.

---

Signs of Missing Safety

In Meetings

• Only 2-3 people speak
• Silence after "Any questions?"
• Nodding instead of honest discussion
• Important points are raised only after the meeting

In Code Review

• Defensive reactions to feedback
• Fear of submitting PRs
• Excessive polishing before review
• Conflicts are avoided rather than resolved

In Team Dynamics

• Blame culture after mistakes
• Knowledge isn't shared
• High turnover
• Rumors and hallway conversations

---

Concrete Measures for Leaders

1. Model Vulnerability

• Openly admit your own mistakes
• Say "I don't know"
• Ask for help
• Share your learning journey

2. Change Reaction to Mistakes

Instead of: "Who screwed this up?"

Better: "What can we learn from this?"

3. Actively Request Questions

• "What am I missing?"
• "What concerns do you have?"
• "Is there a better way?"
• Directly address quieter team members

Important: Wait after questions. Silence is okay.

4. Recognize Risk-Taking

Reward:

• Asking questions
• Giving feedback
• Sharing ideas
• Reporting mistakes (before they get bigger)

5. Use 1:1s Effectively

Questions for 1:1s:

• "How safe do you feel to speak your mind in the team?"
• "Is there anything you wouldn't say in a team meeting?"
• "What could I do better to make you more comfortable?"

---

Practices for the Team

1. Blameless Post-Mortems

After incidents:

• Focus on system, not person
• "What led to the error?" instead of "Who made the mistake?"
• Document learnings
• Implement improvements

2. Better Code Reviews

• Criticize code, not the person
• Ask questions instead of giving orders
• Highlight positives
• Suggest solutions, not just problems

3. Retrospectives Done Right

Rules:

• Vegas rule: What's said in the retro stays in the retro
• No interruptions
• Everyone speaks
• Define concrete actions

4. Pair Programming and Mob Programming

Learning is normalized, knowledge is shared, less "this is my code" mentality.

5. Failure Fridays / Learning Moments

Regular sessions where everyone shares a mistake of the week — normalizes mistakes as learning opportunities.

---

Measurement and Improvement

Edmondson's 7 Questions

Amy Edmondson's original questionnaire (1-5 scale):

1. If I make a mistake on this team, it is held against me.
2. Members of this team are able to bring up problems.
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 team members for help.
6. No one on this team would deliberately undermine my efforts.
7. Working with this team, my unique skills are valued.

Improvement Plan

1. Measure baseline (where are we?)
2. Set priorities (what's most critical?)
3. Define measures (what do we do concretely?)
4. Experiment (test for 30-60 days)
5. Re-measure (did it work?)
6. Iterate (adjust and repeat)

---

Conclusion

Psychological safety is not a "nice-to-have" - it's the most important factor for team performance. Google's research proves: Having the best talent doesn't automatically win. Creating the best environment wins.

For tech teams, this is especially relevant. Code reviews, post-mortems, complex problem-solving - all of this only works when people feel safe being honest.

The good news: Psychological safety can be built. It starts with leadership and spreads throughout the team. One question, one reaction, one meeting at a time.

---

FAQ

Is Psychological Safety measurable?

Yes. Amy Edmondson's 7-question survey is the standard. Regular pulse checks (1-2 questions) can show trends.

How long does it take to build Psychological Safety?

Months, not weeks. Trust builds slowly. A single incident can destroy it. Expect 3-6 months for visible improvements with consistent effort.

What if the problem is with leadership?

Difficult, but not impossible. Options: Give feedback upward, involve HR, seek skip-level conversations.

Does this work remotely?

Yes, but it requires more effort. Remote teams must actively build psychological safety.

What's the difference from trust?

Psychological safety is team-level, trust is person-to-person.

Can too much Psychological Safety be harmful?

Theoretically: If "safety" means nobody is challenged. Practically: That's rarely the problem.