Building Effective Software Engineering Teams - Part 2 - Psychological Safety

January 23, 2025   

Photo by Kelly Sikkema https://unsplash.com/@kellysikkema?utm_source=medium&utm_medium=referral

Recap - Part 1

In the first part of this series, I discussed how some engineers are exploiting the opportunity of remote work to take on multiple full-time roles and how organizations can manage this situation.

I emphasized the importance of building trust within software engineering teams, especially in the age of remote work. This article continues from there…

From my conversations with engineers, some of the “bad behavior” seen today stems from their past experiences of being mistreated by organizations. While two wrongs don’t make a right, it’s essential to acknowledge that trust is a two-way street. When organizations treat engineers unfairly—as disposable cogs, fail to provide conducive work environments, overwork them, or terminate employment with little or no notice—it creates a foundation for engineers to view the relationship as purely transactional. This mindset does not bode well for employee engagement.

Beyond this, there’s a more subtle yet critical issue that affects the effectiveness of engineering teams. In 2012, a research team at Google conducted a study to determine what made some teams significantly more productive than others within the organization. Since Google is primarily an engineering company, most of the teams analyzed were software-focused. The results of the study were profound and eye-opening. Team performance wasn’t determined by the number of “rock-star” programmers or the seniority of the engineers. Instead, the research found that the most important factor in predicting team effectiveness was the level of psychological safety within the team.

What is Psychological Safety?

| Psychological safety is the belief that one will not be punished or 
| humiliated for speaking up with ideas, questions, concerns, or mistakes. 
| In teams, it refers to team members believing that they can take risks 
| without being shamed by other team members. [^1]

Psychological safety is foundational to fostering a culture of innovation, productivity, and resilience in software engineering teams.

When this is lacking, team members tend to hide problems, fail to speak up about issues, and focus on assigning blame when things go wrong. These negative behaviors have a detrimental effect on team productivity.

Teams without psychological safety waste significant time and energy battling phantom issues or internal conflicts instead of solving the most pressing problems at hand.

One of the most effective ways leaders can foster psychological safety is by being open about their own mistakes and errors. This sets a powerful tone and encourages team members to do the same.

What Psychological Safety is Not

Some business leaders are wary of psychological safety, assuming it implies a lack of accountability or high standards. Others mistakenly associate it with DEI (Diversity, Equity, and Inclusion) initiatives. These assumptions are incorrect. In the words of Sheril Matthews, from his article on psychological safety and high standards: 1

| Psychological safety is not "comfort"

It is neither coddling nor an “anything goes” environment. It is not about making work feel easy or stress-free. Instead, it enables the kind of candor and communication that makes teams effective—an environment where trust is the foundation for open and honest discussions.

Sheril further illustrates the interplay between high standards and psychological safety using Amy Edmondson’s framework of four organizational archetypes:

psychological safety and high standards illustration

Sheril has already done an excellent job breaking down these archetypes, so I won’t rehash them here. The key takeaway is that psychological safety and high standards are not opposites but complementary attributes of a truly innovative organization.

Any other type of environment fosters a culture of risk avoidance or comfort with the status quo. While high-pressure environments can occasionally lead to bursts of creativity, sustained pressure without psychological safety quickly leads to burnout. Over time, people expend more energy avoiding failure than striving for excellence and innovation.

Why Psychological Safety Matters in Agile Organizations

In agile development, psychological safety is essential because a key part of innovation is the ability to “fail forward”—embracing iterative failures. Failure, in this context, is not a bug but a feature of the agile process. Team members need to take risks and accept that some will lead to failure, as this ultimately increases their chances of success.

It’s important to distinguish between acceptable and unacceptable forms of failure. In high-volume, repetitive, or operational processes, the cost of failure can be substantial (e.g., a cashier at a financial institution repeatedly entering an extra zero or broken diagnostic equipment at a medical facility). These types of failures are not what we’re discussing, and organizations design controls to prevent them.

In contrast, innovation requires comfort with uncertainty, where it’s difficult to predict success. Failures in this context provide valuable feedback, helping teams refine solutions. Ideally, this happens in a controlled, non-customer-facing environment.

A key goal of agile methodology is to gather feedback from customers or clients before incurring significant sunk costs. This ensures that all requirements are met during product development. Without clear and open communication, small issues that could have been resolved early often snowball into major roadblocks that jeopardize delivery.

Building a Psychologically Safe Work Environment

Remote work adds complexity to fostering psychological safety. Nuances of communication, such as body language and facial cues, can be difficult to gauge in virtual interactions.

Fortunately, Google Re:Work has compiled excellent resources to help organizations measure and improve team effectiveness. These resources are a great starting point. 2

References

comments powered by Disqus