Leadership

Psychological Safety and Team Performance

Google studied 180 teams to find what makes them effective. The top factor was whether people felt safe to speak up, ahead of talent or seniority.

RE

Roberto Espinoza

CEO, Ruzora

July 6, 20268 min read

Google set out to answer a question every leader has: what makes a team great? They studied 180 of their own teams for years, expecting the answer to hinge on hiring the smartest people. The data pointed somewhere else. The single biggest predictor of an effective team turned out to be whether people felt safe to take risks in front of each other.

Key Takeaways

  • Google's Project Aristotle studied 180+ teams and found psychological safety the #1 factor in team effectiveness (Google re:Work).
  • Team composition (seniority, education, background) mattered far less than how the team worked together (Google).
  • The concept comes from Amy Edmondson's research: safety to speak up, admit mistakes, and challenge ideas (Project Aristotle).
  • High-safety teams at Google had lower attrition and were rated effective twice as often by executives.

What Google Found

In 2012 Google launched Project Aristotle to figure out what separated their best teams from the rest. Analysts, psychologists, and organizational researchers studied more than 180 teams, examining every variable they could measure (Google re:Work). The surprise was what barely mattered: who was on the team. Seniority, tenure, education, and raw individual brilliance predicted team performance far less than expected. What mattered was how the team behaved together, and the strongest factor by a wide margin was psychological safety.

Psychological safety, a term from Harvard's Amy Edmondson, is the shared belief that you can take an interpersonal risk, ask a naive question, admit you're stuck, disagree with a senior person, without being punished or humiliated for it (Project Aristotle). On safe teams, people surface problems early, because it's cheap to. On unsafe teams, people hide problems until they explode, because speaking up is dangerous.

Why It Drives Performance

Software runs on surfaced information: the bug someone noticed, the doubt about a deadline, the "wait, why are we building this?" On a psychologically safe team, that information comes out early and cheap. Someone says "I don't understand this design," and a flaw gets caught in a meeting instead of in production. On an unsafe team, the same engineer stays quiet to avoid looking foolish, and the flaw ships. Multiply that across a hundred small moments and safe teams catch more, learn faster, and burn out less. Google measured it: people on higher-safety teams were less likely to leave and were rated effective twice as often (Google).

On a safe teamOn an unsafe team
Problems surface earlyProblems hide until they explode
People admit "I don't know"People bluff to look competent
Dissent improves the planSilence rubber-stamps a bad plan
Mistakes become lessonsMistakes get covered up

A Concrete Version

A junior engineer suspects the new caching approach has a race condition, but the architect who designed it is senior and a little intimidating. On an unsafe team, the junior swallows it, the race condition ships, and it causes a nasty intermittent outage two weeks later that takes days to trace. On a safe team, the junior says it in the design review, the architect responds "good catch, let's check," and a ten-minute conversation prevents the outage. Same junior, same insight. The deciding factor was whether it felt safe to speak.

How to Build It

Psychological safety is set mostly by how leaders react in small moments. When someone admits a mistake, thank them for raising it early. When someone asks a basic question, answer it as if it were a good one, because it usually is. Respond to bad news with curiosity rather than blame, the same instinct behind blameless postmortems. And model it yourself: a lead who says "I got this wrong" out loud gives everyone else permission to.

What This Means for Distributed Teams

Safety is harder and more important on distributed teams, where you lose the casual trust-building of a shared office and a nervous engineer can simply stay muted on a call. Building it deliberately, through how you run reviews and react to mistakes, is part of what makes remote teams outperform. It also depends on the people: senior engineers who are secure enough to say "I don't know" and to make it safe for others raise the whole team's safety. That temperament is part of what we look for. See available engineers.

Frequently Asked Questions

What is psychological safety?

The shared belief that you can take interpersonal risks, ask questions, admit mistakes, and disagree, without being punished or embarrassed. Amy Edmondson's research introduced the term.

Why does psychological safety matter for engineering teams?

Google's Project Aristotle found it the number-one predictor of team effectiveness, ahead of talent or seniority. Safe teams surface problems early, learn faster, and retain people better.

How do I build psychological safety?

React well in small moments: thank people for admitting mistakes, treat basic questions as good ones, respond to bad news with curiosity, and model it by admitting your own mistakes out loud.

Is psychological safety just being nice?

No. It means candor without fear, where people can challenge ideas and surface hard problems safely, which often produces more disagreement, not less.

The Bottom Line

Google studied 180 teams and found the biggest driver of effectiveness was psychological safety, ahead of talent, seniority, or pedigree. Teams where people can speak up catch problems early and learn fast; teams where they can't ship the problems they were afraid to mention. Build safety through how you handle mistakes and questions, and it compounds into performance.

Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.

RE

Roberto Espinoza

CEO, Ruzora

Roberto is the founder and CEO of Ruzora. He works directly with US startup founders and CTOs on staff-augmentation and software-factory engagements, and personally reviews senior engineer placements.

AI-vetted engineers, ready now

Your next senior engineer is already vetted and waiting.

It starts with a single call. 72 hours later, you're reviewing scored candidates who already match your stack and culture.