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.

The Example

One Google team with the best engineers performed poorly. Another team with less experienced members outperformed everyone.

The difference: In the second team, everyone could speak freely. In the first team, a few dominated the discussion.

---

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

Missing when:

• Cliques form
• New people feel like outsiders
• Insider jokes that exclude others

Stage 2: Learner Safety

Means: I can learn and make mistakes.

Signs:

• Questions are welcomed
• Mistakes are seen as learning opportunities
• Knowledge is shared

Missing when:

• "Stupid questions" are mocked
• Mistakes are punished
• Knowledge is hoarded

Stage 3: Contributor Safety

Means: I can contribute.

Signs:

• Ideas are heard
• Everyone has a voice in decisions
• Contributions are recognized

Missing when:

• Only seniority counts
• Ideas are ignored
• No recognition

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

Missing when:

• "We've always done it this way"
• Criticism is seen as disloyalty
• Hierarchies are rigid

---

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

Self-Diagnostic Questions

Answer for your team:

1. If someone makes a mistake, is it held against them?
2. Is it difficult to ask other team members for help?
3. Are differences rejected?
4. Is it risky to take a risk in this team?

The more "yes" answers, the lower the psychological safety.

---

Concrete Measures for Leaders

1. Model Vulnerability

What you can do:

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

Example:

"I pushed a bug to production last week. Here's what I learned from it..."

2. Change Reaction to Mistakes

Instead of: "Who screwed this up?"

Better: "What can we learn from this?"

Framework for mistakes:

1. What happened? (Facts, no blame)
2. What was the impact?
3. What do we learn?
4. What do we change so it doesn't happen again?

3. Actively Request Questions

What you can do:

• "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)

Example:

"Thank you for bringing that up. That was brave and saved us from a bigger problem."

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

Template:

1. Timeline: What happened when?
2. Root Cause: What was the cause?
3. Contributing Factors: What contributed?
4. Action Items: What do we change?
5. Lessons Learned: What did we learn?

2. Better Code Reviews

Rules for reviews:

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

Example:

• Bad: "This is inefficient."
• Better: "Have you considered using X here? It might improve performance."

3. Retrospectives Done Right

Format:

• What went well?
• What can we improve?
• What was confusing?

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

Benefits for psychological safety:

• Learning is normalized
• Mistakes are part of the process
• Knowledge is shared
• Less "This is my code" mentality

5. Failure Fridays / Learning Moments

Regular sessions:

• Everyone shares a mistake of the week
• What was learned?
• 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.

Measure Regularly

• Monthly pulse checks
• Anonymous surveys
• Team health checks
• Retro feedback

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.

At Balane Tech, we help teams not just with technology, but also with the culture that makes technology successful. Contact us for more information.

---

FAQ

Is Psychological Safety measurable?

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

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. Sometimes the only solution is to change teams.

Does this work remotely?

Yes, but it requires more effort. Remote teams must actively build psychological safety. More 1:1s, more explicit communication, intentional culture rituals.

What's the difference from trust?

Psychological safety is team-level, trust is person-to-person. You can personally trust a colleague but not feel safe taking risks in a team meeting.

Can too much Psychological Safety be harmful?

Theoretically: If "safety" means nobody is challenged. Practically: That's rarely the problem. Most teams have too little, not too much psychological safety.