You can have the best engineers, the clearest roadmap, and the most elegant architecture in the world, and none of it will matter if your team doesn’t feel safe enough to speak up when something’s wrong.

I’ve been leading engineering teams for over two decades now, across start-ups and large corporates, and if there’s one thing I keep coming back to, it’s this: the teams that performed best weren’t the ones with the most talent. They were the ones where people felt safe enough to be honest. Safe enough to say “I don’t understand this,” or “I think we’re making a mistake,” or “I need help.”

It sounds simple. It isn’t.

What the Research Actually Says

When I first came across Google’s Project Aristotle, I expected the findings to be about hiring, get the right people and everything else follows. That’s not what they found.

The project kicked off in 2012, studying 180 teams across Google, running 35 different statistical models to work out what made some teams effective and others not. They looked at everything: demographics, personality traits, skill sets, team size, conflict resolution approaches. The result was surprisingly clear. Five dynamics mattered, and they mattered in a specific order:

1. Psychological safety, the most important by a significant margin
2. Dependability, can you rely on each other?
3. Structure and clarity, does everyone know what they’re doing and why?
4. Meaning, does the work feel purposeful?
5. Impact, does the team believe their work makes a difference?

What struck me when I dug into this was what didn’t matter. Team composition, size, colocation, seniority, even individual talent, didn’t contribute significantly to effectiveness. Google’s own conclusion was blunt: “who is on a team matters much less than how team members interact, structure their work, and view their contributions.”

That finding challenged a lot of what I’d assumed earlier in my career, when I spent far too much energy trying to assemble the “perfect” team rather than creating the conditions for a good team to thrive.

So What Is Psychological Safety, Exactly?

The term comes from Amy Edmondson’s research at Harvard. She defines it as a “shared belief that the team is safe for interpersonal risk taking.” That’s a precise definition and it’s worth sitting with for a moment, because it’s easy to confuse psychological safety with something softer, being nice, avoiding conflict, or lowering the bar.

It’s none of those things.

Psychological safety isn’t about comfort. It’s about being able to ask a basic question without worrying you’ll be seen as ignorant. It’s about admitting you’ve made a mistake before it snowballs into something worse. It’s about challenging a senior engineer’s approach because you’ve spotted a problem, even though they’ve been at the company three times longer than you.

Edmondson draws an important distinction between psychological safety and group cohesiveness. Cohesiveness, getting along, liking each other, can actually reduce the willingness to disagree. A team that’s too cohesive might avoid challenging each other precisely because they don’t want to rock the boat. Psychological safety is different. It’s not about harmony; it’s about honesty.

There’s a Harvard Business Review study that reinforced something I’ve observed myself: while personality plays a role in whether someone speaks up (introverts may naturally hold back), the situational factors are far more powerful. Strong environmental norms can override personality. In other words, even naturally quiet people will speak up if the environment makes it safe to do so, and even confident people will stay silent if it doesn’t.

What It Looks Like When It’s Missing

I want to share something I came across in my research that perfectly illustrates how quickly things go wrong without psychological safety. Lisa van Gelder, writing in 97 Things Every Engineering Manager Should Know, describes being brought in to debug a team whose velocity was dropping sprint over sprint. Engineers were coming in late, leaving early, and disappearing by Thursday afternoon. The CEO wanted to know if the team should be replaced.

What she found was revealing. The Scrum master had started tracking individual velocity, not team velocity, and requiring each engineer to publicly justify any incomplete stories at the end of each sprint. The engineers hated it. They felt blamed for things outside their control, dependencies on other teams, blockers they couldn’t resolve alone. So they started padding estimates. They committed only to work they knew they could finish. By Thursday, most had finished their stories but wouldn’t say so, because they were afraid of being assigned something they couldn’t complete by Friday.

The fix was straightforward: stop tracking individual velocity, make commitments shared by the whole team with no consequences for incomplete work, and break epics into smaller stories. Velocity tripled. But there was a side effect that’s even more telling, once individual tracking stopped, senior engineers started mentoring juniors again. Previously, there’d been no incentive to help someone else when your own numbers were on the line.

Van Gelder’s conclusion is one I’ve pinned to my mental wall: “Shame is hugely motivational but usually in the opposite way you want.”

I’ve seen versions of this pattern at different companies. Not always as extreme, but the dynamic is the same, when people feel watched and judged, they optimise for self-protection rather than team outcomes. They hide problems instead of surfacing them. They take fewer risks. They stop helping each other.

What It Looks Like When It’s Present

The contrast is stark. On teams where I’ve seen genuine psychological safety, the energy is completely different. People flag risks early because they’re not afraid of being blamed for raising them. Code reviews are honest and constructive rather than performative. Retrospectives produce real insights instead of polite nothings. Junior engineers ask questions freely, and senior engineers don’t treat those questions as interruptions.

Addy Osmani describes a situation at Google that resonated with me. He was setting up a new team for a developer product, with members from four continents ranging from fresh graduates to veterans with over a decade of experience. The initial meetings were essentially monologues, senior voices dominated, and junior members held back. One junior engineer said something along the lines of “I’m not sure that what I have to add is going to matter compared to what the senior engineers have to say.”

The interventions were practical rather than dramatic: round-robin sessions where everyone got uninterrupted time to speak regardless of seniority, an anonymous “Ideas and Concerns” forum addressed weekly in team meetings, and junior-senior mentorship pairings that went beyond technical guidance. The result was that previously hesitant junior members started contributing ideas that were sometimes crucial to solving complex problems, and senior members found fresh perspectives they’d been missing.

What I found interesting about this example is that none of the interventions were particularly clever or novel. They were just intentional. Someone noticed the dynamic, named it, and put structures in place to counteract it. That’s the thing about psychological safety, it rarely happens by accident, but it doesn’t require anything revolutionary either.

The Two Types of Safety

Something I’ve come to appreciate over the years is that there are really two distinct flavours of psychological safety, and teams need both.

The first is safety to be vulnerable, admitting mistakes, asking for help, saying “I don’t know.” This is the one most people think of. It’s what stops problems from being hidden until they’re crises.

The second is safety to challenge, disagreeing with a decision, questioning an approach, pushing back on a senior colleague. This one’s harder to build because it runs up against hierarchy, and most organisations have more hierarchy than they’d like to admit.

I’ve worked in environments where the first type existed but the second didn’t. People were comfortable saying “I’m stuck” but wouldn’t dream of saying “I think this architecture is wrong” to someone more senior. That’s a team that can execute but can’t course-correct, and in my experience, the inability to course-correct is what kills projects more often than the inability to execute.

Camille Fournier puts it well in The Manager’s Path: “The real goal here is psychological safety, that is, a team whose members are willing to take risks and make mistakes in front of one another. This is the underpinning of a successful team.” The key phrase is “in front of one another.” It’s not just about the relationship between each person and their manager, it’s about the relationships across the whole team.

How Leaders Accidentally Destroy It

Here’s what I find uncomfortable about psychological safety: it’s far easier to destroy than to build, and the people destroying it are often well-intentioned.

Fournier shares a piece of feedback she received during a performance review that stopped me in my tracks when I read it: “People are afraid to take risks or fail in front of you because they are scared of being publicly reprimanded in front of their peers.” She reflects that this created a vicious cycle, people hid information to avoid criticism, which made her trust them less, which made her more critical.

I recognise that pattern. Early in my management career, I thought being direct and having high standards was enough. I didn’t realise that how I expressed those standards mattered as much as having them. A sharp comment in a code review, an impatient response to a question in a meeting, a visible sigh when someone raised a problem, these things accumulate. People notice, and they adjust their behaviour accordingly. They stop bringing you bad news. They stop asking questions. They stop taking risks.

The research backs this up. Osmani lists several ways leaders undermine psychological safety without meaning to:

• Assigning blame when mistakes occur rather than getting curious about root causes
• Using jargon or overly formal language that creates distance
• Failing to anticipate reactions when discussing sensitive topics
• Not seeking feedback on their own communication style

But there are subtler destroyers too. The People Pleaser anti-pattern, managers who avoid difficult conversations because they want to be liked, actually undermines safety. As Fournier notes, “You might think people pleasers create teams that feel safe to be vulnerable and fail, but in fact the opposite is true. These managers make it hard for the team to fail in a healthy way, because of the manager’s own fears of failure and possible rejection.”

And then there’s the well-meaning “shield”, the manager who protects their team from all organisational context. The intention is good, but the effect is infantilising. As Jeff Foster argues in his essay on being a “context provider” rather than an umbrella: by insulating the team from reality, you’re stifling their development and preventing them from making informed decisions. Adults who are treated like adults tend to behave like adults.

Building It: What Actually Works

After years of reading about this and trying things myself, I’ve landed on a set of practices that I think genuinely move the needle. None of them are quick fixes, psychological safety is built through consistent behaviour over time, not through a single workshop or offsite.

Replace blame with curiosity

This is the single most impactful change a leader can make. When something goes wrong, the instinct is to ask “who did this?” or “why wasn’t this caught?” Instead, ask “what happened?” and “what can we learn?” Fournier’s advice is to “get curious”, when you turn disagreement into honest questioning, people open up. When you attack, they shut down and learn to hide information.

I’ve found that the language matters enormously. “Help me understand what happened here” lands completely differently from “How did this get through review?” even though both are technically questions.

Model vulnerability yourself

If you want your team to admit mistakes, you need to go first. Apologise when you get something wrong. Say “I don’t know” when you don’t. Share what you’re learning, not just what you already know. Fournier recommends a short apology that takes responsibility: “The goal with apologising is to show people that you know your behaviour has an impact on others, and to role-model for them that it’s OK to make a mistake.”

This one was hard for me. Coming from an IC background, I was used to being the person with the answers. Learning to say “I’m not sure, let me think about that” in front of my team felt like weakness at first. It wasn’t. It was the thing that gave others permission to be honest too.

Create structures that make safety the default

Don’t rely on people feeling brave enough to speak up, design processes that make it easy. Anonymous question channels, round-robin formats in meetings, retrospectives with clear ground rules, skip-level meetings where people can raise concerns without going through their direct manager. Google’s gTeams exercise, a 10-minute survey followed by an in-person discussion, improved psychological safety ratings by 6% and structure and clarity by 10% just by getting teams to talk about how they were working together.

Be consistent

This might be the most important one. Psychological safety isn’t built in grand gestures, it’s built in the hundreds of small interactions that happen every week. How you respond when someone raises a concern in a meeting. Whether you follow through on commitments. How you handle bad news. Whether your behaviour matches what you say you value.

As Fournier puts it: “If you want to build trust, you do that by showing up, talking to them both individually and as a team, and behaving in an ethical, reliable manner. Over and over and over again.”

Don’t confuse safety with low standards

This is the caveat that matters. Psychological safety does not mean relaxing performance expectations. Osmani is explicit about this: “Fostering psychological safety does not mean relaxing performance standards. You cannot allow inappropriate conduct just to ensure team members feel safe. Performance standards and psychological safety must both be high.”

The best teams I’ve worked on had both, high expectations and high safety. People were pushed to do excellent work, but they weren’t punished for the inevitable mistakes that come with pushing boundaries. That combination is what produces genuine innovation and sustained high performance.

The Long Game

Psychological safety isn’t something you achieve and then move on from. It’s something you maintain, constantly, through every interaction and every decision. It’s fragile, a single incident of public blame can undo months of careful work. And it requires ongoing attention as teams change, as new people join, and as organisational pressures shift.

But the research is clear, and my own experience confirms it: teams that have it outperform teams that don’t. Not by a little, by a lot. They ship more, they learn faster, they retain people longer, and they handle crises better. Google found that teams with high psychological safety were less likely to leave the company, more likely to harness diverse ideas, brought in more revenue, and were rated as more effective by leadership.

If you’re a technical leader and you’re only going to focus on one thing, make it this. Everything else, the processes, the architecture, the roadmap, sits on top of it. Get this wrong and nothing else you build will be as solid as it could be. Get it right and you’ll be amazed at what your team is capable of.