What Really Makes a Team Effective? A Lesson from Project Aristotle

Have you ever worked in a team that was quiet, aligned, and seemingly well-organized during meetings — yet its effectiveness was far from satisfactory?
Or, on the contrary, have you been part of a team full of “rock stars”, highly skilled individuals, that still struggled with delivery?

“The whole is greater than the sum of its parts.”

Already Aristotle observed that! We intuitively understand this in sports. The Real Madrid Galácticos, a team packed with world-class stars (Zidane, Figo, Ronaldo and others), won the Champions League only once — despite enormous expectations. On the other hand, the Greek national team, winning UEFA Euro 2004, showed that a well-organized team can defeat opponents with much greater individual talent.

If this analogy sounds familiar, it is worth taking a closer look at the conclusions of Project Aristotle — a study conducted by Google around 2012. Its goal was to identify the factors that actually influence team effectiveness — not just those that look good in management theories or on presentation slides.

As part of the project, around 180 teams were analyzed, varying in size (from a few people to several dozen) and with very different performance levels. The research focused on collaboration, communication, and team dynamics, looking for patterns that distinguish average teams from truly effective ones. A detailed description of the methodology and results can be found on Google’s official website.

Results That Surprised Google

The results of Project Aristotle were surprising — even for Google itself. The analysis of hundreds of variables did not confirm many intuitive assumptions. Team effectiveness was not determined by the level of talent of its members, the number of “stars”, shared experience, or even how long people had worked together.

It also turned out to be largely irrelevant whether a team consisted mainly of extroverts or introverts, or how different team members were in terms of personality. Factors that are often considered critical proved to be secondary.

Instead, the most important elements were related to how people work together, not who they are. The key factor turned out to be psychological safety — the belief that team members can ask questions, challenge decisions, and admit mistakes without fear of embarrassment or punishment.

Five Factors of Effective Teams

Project Aristotle identified five key factors that most often appeared in effective teams:

• psychological safety
• dependability (a sense that team members can rely on each other)
• clarity of structure and roles
• meaning (a sense that the work is personally important)
• impact (the belief that the team’s work makes a real difference)

These factors do not work in isolation — they reinforce each other and create an environment in which teams can achieve above-average results. In this article, however, I focus exclusively on psychological safety, treating it as the starting point for further analysis of team effectiveness.

What Psychological Safety Means from a Team Member’s Perspective

For a team member, psychological safety is not an abstract concept or a “soft skill.” It is a very concrete, everyday experience. It means feeling able to speak up — even when you have doubts, have made a mistake, or see a risk — without facing social punishment.

In practice, psychological safety shows up in simple signals: I can admit that I don’t know something, I can say “I don’t understand,” I can question a decision, and I can admit a mistake without fear of being ridiculed or losing the team’s trust. It is the feeling of being taken seriously — not only when I am right.

What Happens When Psychological Safety Is Missing?

A lack of psychological safety rarely manifests as open conflict. Much more often, it takes the form of silence, superficial agreement, and disengagement. Team members quickly learn which topics are “safe” and which are better avoided. Questions remain unasked, problems are swept under the rug, and mistakes come to light only when it is already too late.

In the long run, this leads to very concrete consequences: poorer decisions, slower team learning, reduced innovation, and growing frustration. A team may appear calm and “well-aligned,” but beneath the surface tension, cynicism, and a sense of lack of impact begin to build.

How Can a Team Strengthen Psychological Safety?

Building psychological safety is not the sole responsibility of a leader. It is a team process, based on everyday, often small behaviors. What matters most is how team members respond to each other — especially in moments of uncertainty and failure.

Teams that consciously strengthen psychological safety make sure to:

• normalize questions and doubts instead of treating them as weakness,
• talk openly about mistakes and draw conclusions from them instead of looking for someone to blame,
• create space for different perspectives, including unpopular ones,
• respond to signals of exclusion, interruption, or dismissing someone’s input,
• close feedback loops by returning to previously raised topics and showing that they mattered.

It is the sum of these small, repeated behaviors that makes a team a place where people not only work together, but also learn together. And as Project Aristotle showed, this is one of the strongest predictors of long-term team effectiveness.

What Does This Mean in Practice for a Tech Lead?

For a Tech Lead, psychological safety is not an addition to the job — it is one of the key conditions for technical effectiveness. To a large extent, it determines whether engineers will raise architectural risks, admit uncertainty in their solutions, and openly talk about quality issues before they reach production.

In practice, this means that a Tech Lead is not only an expert who “knows the best solution.” Their behavior sets the norms: whether technical decisions can be challenged, whether code review is a space for learning or for judgment, and whether mistakes are treated as opportunities to improve the system rather than as proof of individual incompetence.

From a Tech Lead’s perspective, the lack of psychological safety has very concrete consequences: worse architectural decisions, hidden technical debt, passive code reviews, and teams that “deliver” but at the cost of quality and long-term stability. Teams where engineers feel safe, on the other hand, learn faster, surface problems earlier, and make bolder — and often better — technical decisions.

Tech Lead Behaviors That Strengthen Psychological Safety

• openly saying “I don’t know” or “I might be wrong”,
• treating code review as a dialogue rather than a verdict,
• inviting the team to challenge technical decisions,
• responding calmly and constructively to mistakes and incidents,
• making sure that every voice in the team is heard.

Tech Lead Anti-Patterns That Undermine Psychological Safety

• acting as the “smartest person in the room”,
• publicly pointing out mistakes (even jokingly),
• becoming defensive when technical decisions are questioned,
• using code review as a control mechanism,
• shutting down discussion due to time pressure.

The result? The team stops warning about risks, stops proposing better solutions, and limits itself to “just delivering” — often at the expense of quality and long-term system stability.

Summary: Effectiveness Starts with Safety

Project Aristotle showed something that many teams intuitively feel but rarely articulate clearly: team effectiveness does not start with technology, processes, or even talent. It starts with conditions in which people feel safe enough to speak the truth — about risks, mistakes, doubts, and ideas that are not yet fully formed.

Psychological safety does not guarantee success. But its absence almost always guarantees problems — often revealed with a delay: in the form of technical debt, poor decisions, silent attrition, or teams that deliver without engagement or ownership.

The good news is that psychological safety is not a personality trait or a luxury reserved for a few organizations. It is the result of concrete, everyday behaviors — especially those that seem least spectacular in technical teams: conversations about mistakes, code reviews, and reactions to uncertainty.

What’s Next?

Psychological safety is the foundation, but it is not the only element of an effective team. In the next part of this series, I will look at dependability — another factor identified in Project Aristotle — and explore how to build teams where people can rely on each other without excessive control or micromanagement.

Sources

• Google re:Work — Understanding Team Effectiveness (Project Aristotle)

• Leading Effective Engineering Teams — Addy Osmani

• Google’s Project Aristotle — psychsafety.com