What Google Actually Found When It Studied 180 of Its Own Teams
The assumption has always been seductive: build a team of brilliant people, give them clear roles and the right tools, and performance follows. It is a logic that runs deep in the technology sector, where hiring is treated as the primary lever of competitive advantage. Google decided to test that assumption rigorously — and the results fundamentally challenged how high-performing organisations think about team dynamics. Studying 180 of its own internal teams over roughly two years, the company set out to identify what psychological safety in tech teams actually looks like and, crucially, why it outperforms every other variable.
The research, known internally as Project Aristotle, was led by Google's People Operations division. The team analysed hundreds of variables — educational background, personality traits, seniority, team size, reporting structure, whether members socialised outside work — expecting to find some combination of talent and organisational design at the root of high performance. What they found instead was startling in its simplicity. The single greatest predictor of a team's effectiveness was not who was on the team, but how team members felt about speaking up within it.
The concept underpinning this finding is psychological safety — a term coined by Harvard Business School professor Amy Edmondson in her landmark research, which defined it as "a shared belief held by members of a team that the team is safe for interpersonal risk-taking." In practice, this means team members can admit mistakes, raise concerns, ask questions that might seem obvious, and challenge decisions without fearing humiliation, retaliation, or exclusion. Google's Project Aristotle, as reported by Silicon Canals, confirmed that this factor beat everything else — including individual IQ, technical skill, and team cohesion — when predicting which teams delivered the best results.
Why Psychological Safety Is a Critical Infrastructure Problem for Tech Organisations
For developers, IT decision-makers, and policy professionals, this is not an abstract HR finding. It is an operational insight with direct implications for how software gets built, how security vulnerabilities get disclosed, and how product decisions get made under pressure. The technology sector, more than most industries, carries an implicit culture of meritocratic confidence — where appearing certain is confused with being competent. That culture actively suppresses the behaviours that Project Aristotle identified as essential to high performance.
Consider what happens on an engineering team when a junior developer spots a potential security flaw in a codebase but stays silent because they fear looking uninformed in front of senior colleagues. Or when a product manager knows a feature timeline is unrealistic but doesn't raise it because the last person who pushed back was quietly sidelined. These are not hypothetical failures of courage — they are predictable outputs of environments with low psychological safety. And in a world governed by frameworks like GDPR and digital sovereignty regulations, where compliance failures carry legal and financial consequences, the cost of silence can be severe.
"The key question for any leader trying to build a high-functioning team is not 'how do I hire better?' — it is 'have I created the conditions where people can tell me when something is wrong?'"
— Adapted from findings in Google's Project Aristotle research on team effectivenessResearch published by Harvard Business Review in 2017 reinforced these conclusions, noting that teams with higher psychological safety showed significantly greater learning behaviour, engagement, and willingness to flag errors before they escalated. For cybersecurity teams in particular, where threat disclosures and incident post-mortems require candour under pressure, the relevance is direct.
The Five Team Dynamics Google Identified — and Why One Dominates
Project Aristotle identified five key dynamics that distinguished effective teams from underperforming ones. These were, in order of importance: psychological safety, dependability, structure and clarity, meaning, and impact. The fact that psychological safety sits at the top is significant — but so is understanding what the other four dimensions reveal about how teams actually function.
| Dynamic | Definition | Relevance for Tech Teams |
|---|---|---|
| Psychological Safety | Can I take risks without being penalised? | Critical for bug disclosure, code review candour, security incident reporting |
| Dependability | Can I count on teammates to deliver? | Sprint velocity, release reliability, shared ownership of outcomes |
| Structure and Clarity | Are goals, roles, and plans clear? | Agile processes, GDPR compliance roles, incident response protocols |
| Meaning | Is the work personally significant? | Purpose-driven tech culture, open source contribution, mission alignment |
| Impact | Does the work matter beyond the team? | Digital sovereignty, user privacy outcomes, societal contribution |
What makes the ranking meaningful is that the other four dynamics are difficult to achieve without the first. If team members don't feel safe to flag a missed deadline (dependability), question an ambiguous process (structure), or say that a project feels pointless (meaning), those dimensions remain theoretical. Psychological safety is, in effect, the soil in which the other four grow. According to findings documented by McKinsey & Company, organisations that invest in psychological safety see measurable improvements in innovation rates and decision-making quality — two capabilities that are existential in the current technology landscape.
Implications for Open Source Communities and Digital Sovereignty Teams
The findings carry particular resonance for the European technology ecosystem, where open source projects, digital sovereignty initiatives, and cross-border collaborative infrastructure teams are increasingly central to both policy and commercial strategy. These environments — often characterised by distributed contributors, flat hierarchies, and asynchronous communication — present unique challenges for psychological safety that the traditional office-based model does not fully account for.
In open source communities, the stakes of public code review and pull request rejection can feel intensely personal, particularly for newer contributors. Research by the TODO Group and Linux Foundation has consistently flagged contributor retention as a key challenge, and while the causes are multifactorial, the emotional dynamics of public critique without adequate psychological scaffolding plays a measurable role. When contributors feel that their questions will be dismissed or that their early mistakes will define them permanently, attrition rises — and the pool of people willing to maintain critical digital infrastructure narrows.
For GDPR compliance teams and data protection officers — roles that require delivering uncomfortable truths to senior leadership about regulatory risk — the connection is direct. A Data Protection Officer who operates in a low-psychological-safety environment is structurally less able to perform their legal function. If the DPO fears pushback when raising concerns about a new data processing activity, the organisation's compliance posture degrades — not because of bad law, but because of bad team culture. This dynamic was highlighted in guidance from the European Data Protection Board, which has repeatedly emphasised the importance of internal escalation channels that function without fear of reprisal.
The same logic applies to cybersecurity incident response. When a breach or vulnerability is discovered, the speed and quality of the internal response depends heavily on how quickly the relevant people can speak up. Blameful cultures — where the first response to a security incident is to find the person responsible and punish them — systematically slow that response and drive future failures underground. Frameworks like blameless post-mortems, pioneered in site reliability engineering and documented extensively by Google's own SRE handbook, are essentially operational implementations of psychological safety applied to technical failure.
How Technical Leaders Can Build Psychological Safety Without Soft-Skills Theatre
For engineering managers, CTOs, and IT decision-makers, the risk with findings like this is that they get translated into mandatory team-building exercises and culture decks that change nothing. The research is more specific than that, and more actionable. Building psychological safety in tech teams is primarily a function of leader behaviour — specifically, how leaders respond when something goes wrong.
