Project Aristotle
In 2012, Google’s People Analytics team set out on a project, code-named Project Aristotle, to inquire into the factors that make an effective team. This followed the success of Google’s Project Oxygen which assessed the factors that make up a good manager. The name ‘Project Aristotle’ was chosen as a reference to a quote attributed to the Ancient Greek philosopher “The whole is greater than the sum of the parts”. Aristotle never wrote that exact phrase but it’s a synthesis of what he was writing about Systems and the Elements of a system, along with the mysterious property of Emergence within a system.
A team is a system, a complex and organic interaction of its elements, its people, and through their interactions. There is an emergence of order where together they function differently, hopefully to a greater magnitude, than they would by acting individually. So ‘Project Aristotle’ had a goal of answering the question: “What makes a team effective at Google?”
Always begin with definitions:
Google began with the sensible question of what actually makes a ‘team’ and they distinguished a ‘Team’ from a ‘Work Group’. A Work Group was may meet occasionally to share information and are defined more in terms of formal organisational hierarchies, but the people within a work group do not have a high reliance on one another to perform their roles. A Team by contrast is characterised by highly interdependent people who rely heavily on one another to get their work done, a cohesive unit planning their work, solving problems together, making decisions, reviewing progress around a specific project.
“Google concluded that Psychological Safety was the Number One factor in determining the effectiveness of a team”
Project Aristotle identified 5 main deterministic factors for team effectiveness including:
1. Psychological Safety:
Google concluded that Psychological Safety was the Number One factor in determining the effectiveness of a team. In a Psychologically Safe team, people feel safe taking risks, and sharing their vulnerability.
2. Dependability:
Team members relying on each other to get things done according to Google’s standards for Excellence.
3. Structure and Clarity:
Clear roles, plans, and goals for team members.
4. Meaning:
Work is personally relevant and relatable to team members.
5. Impact:
People’s work matters and creates change.
Less important Factors:
Interestingly, Google found that the following factors did not significantly affect team effectiveness:
Colocation of teammates (sitting together in the same office, something we’ve learned more about during the Covid lockdown restrictions)
Consensus-driven decision making
Extroversion of team members
Individual performance of team members
Workload size
Seniority
Team size (this is an interesting one as it is contrary to Jeff Bezos’ ‘Two Pizza Rule’ where small teams, which could be fed on two pizzas, was favoured at Amazon. This also runs contrary to the thinking in Brooks’ Law where adding people to a late software project makes it later due to the added complexity of keeping everyone looped in.
Tenure
It’s worth observing that these are Google’s conclusions from a study relating to how things are done at Google. As with everything in life there are nuances, and generalising to all organisational contexts would be folly.
A note on measuring Team Effectiveness:
It is worth noting that originally the Google team looked for objective quantitative measures of effectiveness such as lines of code written, bugs fixed, customer satisfaction. It was soon determined that these measures were flawed and effectiveness is nuanced and contextual.
The team finally settled on a mix of subjective and qualitative measures:
Executive evaluation of the team
Team leader evaluation of the team
Team member evaluation of the team
Sales performance against quarterly quota
Through hundreds of double-blind interviews and collecting a range of data around the individuals, demographics, and situational contexts they concluded it matters less about WHO is in the team, and more about the dynamics of HOW the team worked together.
Delving into Psychological Safety
So what is so special about creating the conditions of Psychological Safety in teams?
The word ‘Safety’ may lead to a mischaracterisation of the term Psychological Safety. We are not talking about a cuddly ‘Kum ba yah’ utopia where everyone nicely agrees with each other.
Psychological Safety is creating the environment for tough conversations to happen, for risks to be taken, for hard decisions to be made where there is possibility of failure. But when we fail, we do not resort to blame, we trust one another to take accountability and work cohesively to learn from failure - to fail fast and fail forward. In a Psychologically Safe team, we can be candid with one other, polite straight-talking to confront issues directly rather than hiding things and covering our tracks. We can take the risk of suggesting ideas, even half-baked ideas that might sound silly. We don’t have to think carefully about how to phrase things, we apply the Most Respectful Interpretation to what people say. There is no shame in making a mistake or needing to ask for help. Sharing bad news or politely pointing out errors and concerns along with constructive dissent is actively encouraged. Teams feel inclusive and diversity is encouraged, especially diversity of thinking - Psychologically Safe teams are anti-groupthink.
Software Engineering teams need to navigate complexity and ambiguity together. There are rarely ‘black and white’ solutions to the complex business problems their code needs to address. Navigating complex problems require a high tolerance for nuance and diversity of opinion. We need to balance different priorities and find the optimal trade-offs in terms of speed of delivery, quality, and cost. A Psychologically Safe environment is critical to effectively handling these competing needs.
The Role of Leaders:
Teams are comprised of human beings, and the default setting for human beings is one of defensiveness. To guard against the worst outcomes, to be careful with whom you trust, and to be on alert for attacks. This outlook was key to survival in our pre-history. To engage in Psychological Safety is to override these natural settings, to override our natural wiring for fight, flight, and freeze in what we perceive as threatening situations. Psychologically Safety, therefore, runs contrary to our chimp-like natures. It requires the kind of self-awareness and diligence which is only possible if Psychological Safety is culturally embedded. We all know that corporate environments can be toxic, political, backstabbing, and duplicitous - and sometimes the higher the status, the worse the behaviours.
Leadership is often modeled in our societies by the behaviour of politicians, news reports, TV debates, and the ‘Snakes in Suits’ alpha types in movies. These behaviours are toxic, a far cry from the tenents of Psychological Safety.
It is the role of leaders to accept that a Psychologically Safe environment will not emerge on its own, it must be consciously and diligently supported by leaders. Leaders should model Psychologically Safe behaviours, building trust by admitting their mistakes, their vulnerability, and reaching out for help. They should be approachable and open to new ideas and suggestions, they should not engage in blame, or public shaming, they should strive for calm adult to adult conversations even in the heat of pressure. Leaders should be alert to people who do not feel Psychologically Safe and proactively inquire into the root causes.
Higher status individuals within the group adopt an attitude of humility, accepting that they’re not always right. A Psychologically Safe environment encourages the emergence of a hierarchy of competence around a particular domain and quashes hierarchies of dominance that are based purely on social status. People feel safe to challenge those of higher social status.
Leaders need to turn their back on outdated thinking about leadership, surrender their illusion of control, their need to be right, and allow order to become an emergent property in Psychologically Safe, purposeful, and empowered teams.
A lesson from airplane disasters:
There is a recognition in the aviation industry of the importance of Psychological Safety within the flight crew of an airplane. Following the investigations from a number of airplane crashes, the industry has learned that lower-ranking crew members can feel fearful about questioning the decisions of higher-ranking members. Challenging the authority of the captain could result in an uncomfortable rebuke, just as an employee challenging the authority of the CEO could result in a lower bonus or a contrived dismissal. Therefore, poor decisions by higher status individuals are allowed to persist.
An example is the Kegworth Air Disaster of 8th January 1989, where the pilot had to shut down a faulty engine, but mistakenly shut down the functioning engine. From the cockpit, the pilots had no way to visually check the engines, and even though the cabin crew and passengers could see that the wrong engine was shut off. This is cited as a contributing factor in the crash and there are many other examples in aviation where the ‘social distance’ between the pilot and others on the plane prevented the challenge to authority which could have prevented disaster.
Due to the rigorous introspection process following aircraft crashes and the need for the highest standards of passenger safety, the concept of psychological safety is now baked into training programmes for employees in the aviation industry and embedded into the mentality of the flight crew.
CEOs, leaders, and managers need to make extra efforts to show humility and be open to being proven wrong if they want to engender a culture of Psychological Safety.
Psychological Safety as a Cornerstone for Effective Software Engineering Teams:
With People First Engineering I am attempting to codify a number of protocols that are foundational to creating Software Engineering environments where the human experience of work is given the highest priority. I believe that Psychological Safety is a cornerstone of thriving and engaging environments and have created the protocol as a Standard, using language that Software Engineers adhere to when writing code. See the Psychological Safety Protocol.