Software development is almost always a team sport.

Even products that start with a single developer or creator will often grow in size and scale to include multiple specialized roles, managers, and other players. And they all need to learn how to work together in the best way possible to create the best possible software.

This is no small task.

In any team, there are conflicting interests, dueling egos, and varied personalities. But in order to understand how software teams can do their best work, we need to first understand what the definition is of an effective team.

For our purposes, teams are most effective when they are able to work together to accomplish more as a group than they could as individuals.

This is the foundational motivation for creating a team in the first place. If it’s untrue, then the team would be better disbanded in favor of a group of individual workers.

So, how do we ensure that our software team meets these standards?

Google’s People Operations team did an extensive study to try to understand which factors determined if a team would be efficient and productive or if the team would struggle to work together.

The results are surprising.

The right size and structure doesn’t exist

It may be tempting to debate how to structure or compile a team for maximum effectiveness. We often read and hear about how more-democratic teams are better than ones with strong top-level leadership, or whether it’s best to put top performers all together on a single team or spread them out evenly across different groups, or how many people should be on a team to get the most work done.

The answer, according to Google’s study: It doesn’t matter.

Among the most important findings of the study was that there was no universal “best” team structure or organization.

Google’s study concluded that across their dozens of teams, there was no correlation between the basic structure of the team and their performance.

Instead, the effectiveness of the team was really only correlated with the ability for team members to speak openly and feel like they were heard.

This is referred to as “psychological safety” – the number one factor for creating effective teams.

Psychological safety matters

This idea of psychological safety is truly the underpinning of the remaining findings from the Google study.

This characteristic reflects the idea that members of a team feel like they have the freedom and safety to communicate freely. They’re able to express themselves and take risks without losing status within the group or fearing for their job.

With psychological safety, team members have the freedom to do their best work.

If teams remove barriers of fear, anxiety, and discomfort, the members will gain the confidence they need to outperform their peers.

This doesn’t mean coddling or insulating teams from feedback. Quite the opposite, in fact. In order to harbor psychological safety, teams should be given full responsibility for their actions and their work. With that level of responsibility, they will have a greater sense of autonomy and more ownership over what they create.

Software developers who feel a sense of collective ownership over the ultimate outcome of the product they are building tend to perform better individually and the same applies to teams as a whole.

Better communication, more clarity

From psychological safety comes many additional benefits for teams.In particular, there is more open communication. People feel unrestricted to ask questions, clarify points, and make their own ideas heard by the group.

This leads to many of the other factors that Google identified as foundational for effective teams.

From this one source of psychology safety, we see that teams are more likely to exhibit dependability, internal structure and clarity, sense of meaning, and feel their work has real impact.

These are the hallmarks of an effective and efficient group that can work together to create innovative solutions and solve tough problems.

Building psychological safety

Although we can attribute much of the success of a team to a single attribute of the group, that doesn’t mean it’s something that is easy to foster or nurture. There’s no “easy” button that we can use to make team members feel safe together.

But we can control for factors that help create a culture that is more likely to breed this all-important characteristic.

Psychological safety is the product of a specific set of conditions that surround the team, which give way to a broadly felt sense of security, responsibility, and ownership. This is a trait that stems from a number of factors.

Here are some ways that your company can help improve the effectiveness of your teams by increasing psychological safety.

Make sure members are heard

The most important component in establishing psychological safety is making team members comfortable to speak openly.

This means that team members should all be given equal time and consideration in meetings. They should feel that they are heard and that their ideas are given the same weight as others on the team. This fosters goodwill between members and encourages everyone to speak their mind.

• Institute policies that encourage each team member, individually, to voice their thoughts
• Allow team members to share and explain conflicting or controversial ideas and opinions
• Introduce and actively enforce a culture of “no stupid questions” or “no stupid ideas”

Allow for discussion and exploration

One of the possibly counterintuitive findings from the study indicated that individual team members, meetings, and processes do not necessarily need to be ultra-efficient in order for teams to be effective.

In fact, the opposite proved to be true. Teams that engaged in banter, got sidetracked on tangential topics during meetings, and generally had a more casual rapport were among the most productive. But it really shouldn’t be surprising given that this kind of relationship within a team would obviously foster more comfort and provide an atmosphere for more open communication.

There are diminishing returns to this type of culture. Teams can’t spend their entire day shooting the breeze and still be productive. Even so, cracking down on every instance of “time wasting” can clearly be counterproductive.

• Loosen policies on “time wasting” or extremely strict time management processes
• Allow for some flexibility in meetings and schedules for ideas and discussion
• Emphasize the importance of quality of work versus efficiency of creation

Encourage personal (appropriate) sharing

The more team members feel they’re able to share, the more comfort and security they feel within a team.

In this case, sharing personal stories and other non-work conversations will build mutual trust, respect, and rapport. This leads to more comfort when sharing ideas, worries, and thoughts about work.

Again, we see that in order to open dialogue between team members, there must be a culture of openness. Once that feeling is established, team members will be more willing and able to communicate freely amongst themselves.

• Encourage managers/leads to engage in friendly banter and small talk
• Create time for socializing and non-work activity
• Begin group meetings with personal, friendly discussion
• Reward risk
• Team members must feel comfortable taking risks in order to innovate and push for new and unique ideas.

One of the core reasons why teams that feel a sense of psychological safety tend to be more effective and productive is because they are willing to take bigger risks. Plainly, teams that take risks are more likely to uncover new and exciting opportunities for the product or business.

But this starts with harboring a culture where developers feel comfortable taking (smart) risks. They must be rewarded for such behavior and the threat of punishment for failure should be limited.

This essentially boils down to conditioning. If developers feel their risk could result in them being fired – even if it was an honest attempt to improve some element of the business – then they’ll become averse to such actions. Instead, recognize and reward risk-taking as something worthwhile. Discourage reckless behavior, but not experimentation.

• Recognize and reward smart risk taking
• Set expectations about failure and punishment
• Create time and space for experimentation, trial, and controlled risk
• Institute a “failure” metric that encourages risk taking

Over to you

What makes your team effective? What tensions prevent your team from performing their best?

Share your experiences in the comments.

7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.