Psychological safety isn't about making you happy, I'm actually a bit surprised why so many people here think it is. It's about producing positive outcomes in the form of successful projects. You're still going to have toxic projects, this isn't a magic dust you sprinkle on a project to make it suddenly successful, it's a technique you use to make unbearable work bearable and give the people who don't feel comfortable speaking up the space to do so.

The observation is if everyone feels comfortable disagreeing with one another, the project is more likely to succeed. That's it.

This is a productivity tool to make marginal projects more likely to tip favorably, and to keep good engineers around even when they're on bad projects, and hopefully make some bad projects less bad by giving everyone room to suggest improvements.

>I'm actually a bit surprised why so many people here think it is.

I would hazard a guess that most of the misunderstanding around the term is due to its ambiguity. I think it's so bad it’s counterproductive actually but that's subjective. It really feels like what they are trying to say is that everyone feels personal agency in their decisions, actions and communication, but the term evokes a concept of being free from threats or risk.

I would suggest that neither of these create high performing teams, they just tend to reduce the pathological behaviors that impede them. They still need to get past the observations of Andy Grove 'When a person is not doing [their] job, there can only be two reasons for it. The person either can’t do it or won’t do it; [they are] either not capable or not motivated.' After all, someone sleeping at their desk day after day could actually be experiencing maximum psychological safety.

> Psychological safety isn't about making you happy, I'm actually a bit surprised why so many people here think it is. It's about producing positive outcomes in the form of successful projects. [...] The observation is if everyone feels comfortable disagreeing with one another, the project is more likely to succeed. That's it.

It is both.

My decision to stay or quit is a cost-benefit analysis, and feeling happy or unhappy is a part of the equation. High employee turnover usually means lower productivity, because knowledge is lost and new team members need to learn about the project from scratch.

People keep saying this but I don’t understand the difference. Engineers only want to have constructive arguments with each other if they feel committed to the project and happy about their place in the organization. If people feel that their job is on the line or that argumentation will not lead to any constructive output, then they will not engage in such an activity. Can you explain the difference between being happy and engaging in behaviors which a happy person engages in?

Maybe it would be helpful to use the term other than “safety”? Is there a synonym for a psychological safety that would get cross what you’re thinking about better?

> Maybe it would be helpful to use the term other than “safety”? Is there a synonym for a psychological safety that would get cross what you’re thinking about better?

Trust. Psychological safety is (real) trust between members of the team and the people who impact the team (e.g. managers or executives or whoever). It's trusting the people around you so you feel free to be yourself, to propose off-the-wall but potentially terrible ideas without being thought less of, to be open about flaws and failures, to try to stretch yourself beyond what you think you are capable of because you trust that the people around you will support you.

It isn't having a secure job or even a happy one. I was once on a team with a shitty director and severely understaffed in a very unsexy, low-paying industry. I did not enjoy my place in the organization. But we had psychological safety on our team. In our scrum team the tech lead/manager was amazing. He protected us from above, he trusted us, he was honest about the situation, and he had a passion for building a great team and growing his people. When someone made a big mistake in prod, he taught that person how to correct the mistake as an opportunity for growth while the entire team supported them (but didn't do it for them, because we trusted that person). The job sucked and within 2 years the entire team had quit. But not a single person even thought about leaving until that team lead left and the culture of trust left with him. Psychological safety is related to happiness in that teams with it tend to also have happy employees - but it creates happiness, not the other way around.

Psychological safety is often hard to have when the job is unstable (it probably feels unstable because of a lack of trust somewhere), but a startup is a great example of where you can have both trust and an unstable job.

I think the part you're missing is that projects don't just materialize as "committable" or "comfortable", people have to make them that way, and the more people who feel like they can step into that position, the better it is for the project, just from a pure numbers perspective.

"Happy" is a hard term to define, and I don't think you need to be happy to feel "safe". Another way of describing "safety" is "the ability to make mistakes/ask for help without negative consequences". You may feel "unhappy" that you made a mistake, but you won't feel judged for it if the people around you are comfortable with you taking risks.

You can be deeply unhappy, personally and professionally, and still experience that shared comfort with risk taking on your team, and benefit from what Google's research shows, I think. Perhaps you're all comfortable with the risks because the project is going so poorly and you need to throw some hail marys out there to try and get out of the bad situation. The focus is on everyone agreeing that making mistakes is expected and acceptable, because risks also come with reward.

I actually really like that example, where you're on a doomed project, and the natural "safety" that forms with the team who all knows it's a doomed project anyway, so why not take a few shots at something wild? The space you create in that environment where, "we were going to fail anyway might as well throw some shit at the wall to see what sticks" is exactly what I mean when I say "safety". Projects that have that attitude apparently tend to be more successful. Imagine having that level of comfort with your team and also working on a successful project!

> Engineers only want to have constructive arguments with each other if they feel committed to the project and happy about their place in the organization

This is not true. I don't need to be happy to want constructive arguments. In fact, the more unhappy I am, the more I need that constructive argument about what is bothering me - to deal with situation that makes me unhappy.

Whether I go into it depends a lot on whether I think/feel it is safe for me to open argument or join it. If I think I will be punished for saying stuff, I don't say that stuff, because I am not dumb.

And I can also be unsafe psychologically and subjectively happy. I can have interesting tasks, fun, I won't be expressing my opinions and there will be risk unsolvable situation will arise. But until then, I will be happy.

I've had lots of junior and entry level engineers who are frankly intimidated by their team. Someone will have a decent idea but not bring it up in a group session because "Jane has a PhD and 15 years more experience than I do, their idea is probably better so I didn't bother".

You know what? Most of the time they are right. But it's still important to have a culture where everybody feels comfortable presenting their own ideas and critiquing others - not because we're going to discard the sr. staff persons architecture in favor of the interns idea very often, but because the process is good for the ideas, good for the product, and good for the team members (whatever level).