Eficode The most dangerous team is a silent one: Psychological safety in high-performing teams

In this episode of The DevOps Sauna, Pinja Kujala is joined by Alexandra Aldershaab to explore why psychological safety remains one of the most important ingredients of high-performing teams.

They discuss why psychological safety is not about avoiding disagreement, how respectful feedback drives growth, why silent teams can be dangerous, and how leaders and team members can create environments where people feel safe to speak up, challenge ideas, learn from mistakes, and innovate together.

Whether you're a developer, engineering leader, DevOps practitioner, or anyone working in modern software teams, this conversation offers practical insights into building stronger, more resilient teams.

[Alexandra] (0:03 - 0:10)

You have to be respectful, you have to be caring, you have to be open to any opinion, because we want to learn and we want to keep an open mind.

[Pinja] (0:12 - 1:35)

Welcome to the DevOps Sauna, the podcast where we deep dive into the world of DevOps, platform engineering, security, and more as we explore the future of development. Join us as we dive into the heart of DevOps, one story at a time. Whether you're a seasoned practitioner or only starting your DevOps journey, we're happy to welcome you into the DevOps Sauna.

Hello and welcome back to the DevOps Sauna. Today's topic is something that is really close to my heart. It has always been throughout my professional career.

And first of all, we know that there has been a lot of talk previously about high performing teams. How do we reach that? How do we get the teams at their optimal best?

And one of the key factors that we have seen has been psychological safety. Lately, to be honest, the discourse has been quite opposite and psychological safety has been seen as maybe coddling, maybe even something that we're not allowed to disagree with one another. So we would like to talk about this, why that is not the case.

I'm not here to talk about this by myself, but I brought an amazing colleague of mine, a senior DevOps Engineer, Alexandra Aldershaab. Welcome, Alexandra. Hi.

I'm so happy that you joined me for this. I know that this is also something that you have previously discussed already also on stage. Is that correct?

[Alexandra] (1:35 - 2:14)

Yes. I had the pleasure of doing a talk called “Psychological Safety from the Trenches”, along with a friend of mine, because we thought that there was all this hype around, let's have psychological safety. And we're like, yeah, but so how do we get psychological safety? Like, what are the actual things that we can do to achieve it if we don't know where to start?

And that was how it came about. And we were like, okay, let's make a talk. We've both tried being in a team where there wasn't psychological safety and we both have tried a million different things, but some of them actually worked.

If we pull together the things that actually worked, then we could try and help others do the same.

[Pinja] (2:15 - 2:32)

So if we think about the definition of psychological safety, everybody should know by the time we're recording this, this is the year 2026, that with psychological safety, we enable the team members to take risks and there's no blame culture. What else do we mean when we say psychological safety?

[Alexandra] (2:32 - 2:50)

Well, we mean, like we can speak our mind. We're not afraid to speak up. We're not afraid to bring our opinion to the table.

And we can talk about our mistakes. And it's even encouraged. There's the whole fail fast.

And nobody wants to fail fast if failing means reprimands, right?

[Pinja] (2:50 - 3:56)

So I was once in a team in one of my previous jobs where I made a mistake. I made an oops. We were doing a data migration.

I forgot to inform one part of the organization and they were kind of mad because some of their data was not in the place that they were hoping that they would be. And then what my team lead did was like, of course I came clean. I immediately said what was happening.

And then in this team meeting, he said to the team in a very vague manner, oh, somebody just made a mistake. And I think we should do some better Q&A sessions beforehand. I immediately wanted to raise my hand and say, by the way, it was me.

Just that people actually get the face and I can provide better information about the mistake that I did. Even though I know that he was trying to protect me from people getting mad or being shamed or something. But at least I felt that I was in a comfortable position to just say, OK, it was me.

That's what happened. In the end, I was not blamed for it. It was a large organization that can happen to anybody.

But it was funny how he didn't feel that I would have had that psychological safety in the end, which was strange.

[Alexandra] (3:56 - 4:35)

That's interesting because you clearly kind of had, right? If you felt safe enough to say that. But it's also why it feels like psychological safety has to come from all aspects, right?

You have to have the employees, but you also have to have management on board. You can't get it from one end without the other. It's like a full on culture thing that everybody has to have to kind of be a part of.

But I think that given you the opportunity to not say it, you can also be part of creating the psychological safe space where you feel comfortable to say, hey, that was me. Shit happens. Let's figure out how to solve it rather than getting bogged down on what happened and what went wrong.

That's true.

[Pinja] (4:35 - 4:52)

Yeah, I was not thinking from that perspective, but it was a really strange situation, at least from my perspective at the time. But this is what we mean, right? That we don't mean, of course, that anybody's coddled.

We don't mean that we need to see consensus. And it's quite the opposite, isn't it?

[Alexandra] (4:52 - 5:49)

Yes. Because if we don't have the psychological safety, at least for me, then I don't feel comfortable saying, oh, I disagree with you. Because if you have a very hierarchical structure and everybody's just supposed to do what they should be doing kind of way of going about how to be in a team, and someone says, oh, go implement this in that, you know, use that tool, write that code, do it like this, like I say, and you feel like, oh, but maybe that's not the best solution because I had that experience from that other time, you know. But if I'm not comfortable saying that, then we are in the case where there's not consensus.

But there's definitely no disagreement either, because you just get to the point where you just follow orders instead of saying, oh, I think I have an idea. Maybe this could be a good idea. Maybe it was a bad idea.

But the fact that I'm not feeling safe enough to share it means that we'll never get the other ideas. And it's very difficult to pick the best one if you only hear one of them.

[Pinja] (5:49 - 6:00)

That's true. And do you feel that we have basically not completely stopped, but are we talking about psychological safety less than what we did before? Is that something that is on trend right now?

[Alexandra] (6:01 - 6:59)

I definitely feel so. Because when I first got together with my friend and we started to talk about, can we do a really cool talk about psychological safety? It was on the basis of having been to conferences and seen all these cool talks where people said, oh, but if we have psychological safety, you can see all of these cool impacts it will have on the team.

You will see how much more throughput the team will be able to create. We will see how much more efficient these team members will be and how everybody gets to shine more and we get better software. We get it faster.

All of these awesome things that were everywhere. And those are not the talks that I'm seeing currently at conferences. To be fair, most of them are about AI now, but all of the ones that aren't about actually like producing code, but about how to work together as a team, I feel like they've shrunk.

And I don't feel like a lot of talks have psychological safety as like the keywords, the buzzwords. It's not everywhere anymore. Now it's something you find in corners here and there.

[Pinja] (6:59 - 7:24)

And I think that's one of the things that is actually making it more important right now to talk about this because AI is making everything faster. And we'll get to this in a moment, I guess, what we mean when we say, what does it mean when you have psychological safety? But it's, I think, even more important now.

But I don't think we, some people say that we already have reached psychological safety. And I was like, sure, by all means, but no, I cannot agree with that.

[Alexandra] (7:25 - 7:42)

The best part is when someone comes and says, you now have psychological safety. And if you don't feel so the door's over there. We're kind of being told now it's all fixed.

And you're like, wait, what? Because that is the opposite of like, that does not leave room for disagreement, right?

[Pinja] (7:43 - 8:06)

And we like, of course, like, this is kind of ironic. We're talking about psychological safety. And here we are laughing about these opinions.

Fair enough, some of them might say, but at the same time, it is not something, it's not an absolute state, it's not something that is a forever staying factor in a team, you need to nourish it. And I don't think we can stop talking about psychological safety, even now.

[Alexandra] (8:07 - 9:08)

I completely agree. I think it's because even this based on my experience, there's still a lot of workplaces that don't have it at the moment, or at least not to a full degree. We still talk about how minorities can be afraid of speaking up or being their true selves in the workplace.

If we had full psychological safety everywhere, that probably wouldn't be a debate. So it's clearly not something that we've achieved globally. And some of the discourse where we kind of, where we hear people say, oh, but it's just, as you mentioned, too much cuddling.

And well, then we can't actually state our opinions, because we have to constantly be afraid of the woke people in the room and stuff like that, which is, to me, the opposite, again, because you can actually speak your mind. If you have proper psychological safety, that means everybody can be honest and more direct. And of course, you can't just sit and, you know, harass people.

But that's not, that's also just not about being honest about being mean, right?

[Pinja] (9:08 - 9:48)

No, I, like many people who actually are behaving in a rude manner, they hide behind the well, I'm just being honest, and it's being direct. And that's not psychological safety at all. We don't mean being rude.

When I joined Eficode, the team that I was in at the time is actually my current team. One of the things I was taught very early is that if you have something that you're working on, some materials, you know, some kind of ideas, send it to the team as early as you can. It's gonna be shredded to pieces with love.

It sounds very scary, to be honest, but it's gonna be shredded to pieces, but there's love at the end. Like, you're gonna get the feedback, but it's gonna be done in a respectful manner. And of course, it's gonna elevate what we do in that way.

[Alexandra] (9:48 - 11:19)

And that's just so important, because that's also a thing, right? Oh, but then we can't tell people if they did something bad. Like, no, yes, that is exactly what you can, if you have psychological safety, you can tell people when they fuck up, and it will be in a kind way, where we will all learn from it and get better.

Like, I've experienced like a, I want to say like a two page feedback thing about everything I did wrong in this feature I implemented. And you could say, oh, that was horrible. But to be honest, it was one of the best learning experiences I've had, because it was a senior developer who took the time to write down what he saw me doing, and what he saw me not doing.

So he was like, oh, but if you had used this software pattern in this context, your package would be much less messy. And you could divide this into different things. And like, I read through everything he did, I went and did a UML diagram, because I was fairly new out of university at that point.

And like, I showed it to him. And he was like, oh, yeah. And then if we tweak this a little bit, I think you got the architecture down, right.

And I implemented it. And we ended up with like, the longest pull request review I've ever gotten. But at the end, we also ended up with a, oh, wow, I can barely see that this is the same person, that this version is absolutely amazing and spot on.

And I learned, because the next time I was gonna do a new little NuGet package, I would start off with everything I've learned. And I would create good quality software from the get go. I've also had, you know, pull request reviews that were, oh, this is bad.

And I'm like, it's a very short review. And I have no idea what to do with it.

[Pinja] (11:19 - 11:30)

So your colleague actually took the time and wrote a respectful feedback. Yeah. Even though it might seem harsh at first, like, oh, wow, is this how big of a mistake I made?

[Alexandra] (11:30 - 12:03)

I will say it's very daunting when you get like two pages of all the errors you created in that little NuGet package that wasn't actually that much code. And you're like, oh, my god, he nearly wrote more texts about how wrong I am that I wrote lines of code. But it was in a respectful way.

And it was in a way where I could grow and I could become a better developer. And that is so important. And the fact that that was him being very honest and telling me it's just not good enough, but in a kind and respectful way.

So I, like today, I'm so grateful for that experience, even though it was like two pages of all I did wrong.

[Pinja] (12:04 - 12:32)

And that's one of the things, like, if we think about what happens if we don't have psychological safety, we, for example, cannot address these mistakes. And we have to be able to address the mistakes. They might be really crucial.

Like, for example, yes, we write code. But at the same time, it might be a mistake in a healthcare organization. And we cannot learn and improve unless we're able to talk about those mistakes in a very respectful manner to add as well.

[Alexandra] (12:32 - 13:12)

Yeah. It's also if we go and say, oh, you made a mistake, you have to improve. Then we're not really discussing whether or not there's a structural thing that kind of leads you down the road where that mistake happens.

But if you like to take a step back and say, oh, a mistake happened, what were the underlying reasons? What led up to this? Do we have faulty documentation?

Do we not know what our processes are? Are we all doing things differently, which leads to communication problems that leads to this mistake? So if we actually look at what led us here, instead of just blaming a person, then we can actually fix the problem, address it head on and fix it without it being all about whether or not someone made a mistake.

[Pinja] (13:12 - 14:10)

I've read about these, there is a Westrum model of different kinds of cultures as an organizational model. And in this model, they have three types of organizations and cultures. They're pathological, and they basically look into how you treat the messenger.

So in pathological, you hopefully not for real, but you shoot the messenger, basically, you blame the messenger. There's the bureaucratic, it's kind of in the middle, but you also, you tend to ignore the messenger. And then in generative cultures, you actually teach and educate the messenger, what should I do when this happens?

And looking into, say, healthcare organizations, software organizations, whatever the organization is, where mistakes can be brutal, can be fatal, you need to be able to detect the actual root cause, as you say, what happened. And we're not able to even take those risks. As I said before, we're not getting those opinions if we don't have psychological safety.

But if we also fear the mistakes, we're not doing any experimentation, and we're not taking those risks.

[Alexandra] (14:11 - 14:57)

There's also the whole aspect of speaking up early. So if you see a project going in a direction where there's a lot of risk of stuff going wrong, feeling comfortable enough to say, oh, I've seen something like this before, or I fear that this could result in these things, having the possibility, even if it's not your project, or if it's not your job to have an opinion, but the fact that you feel safe enough to say, oh, wait, I've actually, I've got some experience on this particular way of running a project, and I can see there's a risk of you getting in a sticky situation if you continue the way you do. Then we can fix the things early on, instead of waiting till everything's burning and people are getting hurt by the problems, right?

[Pinja] (14:57 - 15:19)

That's true. And if we look at the other side, we've talked about what a psychologically safe environment looks like, but what else does it mean from a team's perspective, like a high performance team, when we have the comfort of being ourselves? Where does it lead? What have you seen in your own experience and with the teams that you've worked with?

[Alexandra] (15:19 - 17:27)

I think I had this amazing experience once with a team where we were really good at collaborating, and we had a high degree of psychological safety and the ability to just say things out. This is also the team that got a two-page review of my pull request. Really good team.

And we were working on this project, and right before we were supposed to deliver, we suddenly found out the specification we were working towards was the wrong version, and we basically implemented the wrong thing. And all of a sudden, we had a crazy close deadline. And the way that we just all said, okay, how are we going to fix this?

This was pre-COVID, so we were all in the office, right? Pull out the whiteboard, do a list. What are we doing?

How are we doing it? How do we optimize? Who knows most about which aspects of the product?

Who can fix things the fastest? Where are we pairing up to make sure that we get the most productivity in the shortest amount of time? And all of us basically just came together as one cohesive unit that just built that thing.

It was crazy. We'd spent six months building the wrong thing, and then we spent one month building the right thing, because we just were like, stepped up and said, okay, this is the thing. How do we improve how we work together immensely and just fix it now?

And it was an amazing experience. And having tried to work like that, where everything is just smooth and everyone is focused on how do we get the best result the fastest? Incredible experience.

And also showed how much we can achieve when we know how to work together and we know how to talk to each other and we're not afraid of... Because in a high-stress situation, the risk of saying something that comes out a bit wrong, right? Like when you're stressed out and you want to say, oh, can you grab me the milk?

And you say, give me that milk, right? And you're like, oh, sorry. But if you know each other well, and you're like, oh, wait, that was a bit harsh.

You're like, oh, yeah, sorry, stressed out. And then it's done. And then it doesn't become this whole big interpersonal thing where I might have offended someone or something, because we all know about high-pressure situations and we know each other and we're comfortable around each other.

And then we can get through that really fast. And we can also call each other out, right?

[Pinja] (17:28 - 17:28)

That's true. That's really important.

[Alexandra] (17:28 - 18:01)

Yeah, because if I say something offensive, I'd like people to say, hey, wait, that was odd. Did you mean that?

To give me the opportunity to instantly say, oh, sorry, I definitely did not mean it like that, because I rarely intend to be offensive, right? So that whole like, oh, wow, okay, that came out completely wrong. Let me fix that immediately.

Instead of accidentally hurting someone and then not realising until a couple of days later and then having to say, oh, I'm really sorry, but the damage is kind of already done, right?

[Pinja] (18:01 - 19:14)

Yeah, because they've had a couple of days, like actually reminiscing about that feeling and being, by feeling hurt, basically. And I especially feel that English is not my first language. And I want to think that I speak fluent English, but at the same time, since I'm not a native speaker, I sometimes with English language, especially, I might choose the wrong word that for a native speaker might feel very odd, out of place.

And I've had a lot of people correct me often. It's like, is this what you really mean? I was like, oh God, no, absolutely not.

Thank you for calling that out. But that would not happen if I wouldn't have built the rapport with the people, if they wouldn't feel comfortable with me or around me to feel that they're not hurting my feelings. Exactly.

By saying that, especially in high pressure situations, when we do need to move fast, we do need to have the trust in the process that, hey, when things get hard, when things get really, really, really bad and hard, we can have a conversation, is this the right direction or not? Because otherwise you're going to go six months in the wrong direction.

So let's talk about how we reach that? So in this team that you were just describing, how did you start building the psychological safety with this team?

[Alexandra] (19:14 - 22:53)

I think to be fair, in this team, it was actually really good when I started. It was one of the first teams I was in after graduating and it was part of what showed me when I ended up in different companies afterwards what it could have been like and also showed the difference to me that, okay, but this is what we can do if we trust each other and we're willing to rely on each other. But I've also been, as I've been in the workforce for some years by now, I have been at multiple different companies and multiple different teams.

And I've also started out in a team once that was not high on psychological safety, where I felt like if I said the wrong thing, it could hurt my career basically. If I didn't have the right ideas, then they wouldn't even get to the backlog kind of thing. And one of the things that I did there was basically we had, I was in the fortunate situation that the company had, we did a team agreement saying we have two hours a week to skill up, to kind of upskill and get better at things.

And I had one of my co-workers who I really like, we were vibing, so I really liked hanging out with her and she was really cool and we're like, okay, let's do this. You know a lot about the front end, I know a lot about the back end, let's do the whole breakdown of the silos that everybody's talking about and let's do a two-hour session every week where we go into a meeting room and have a proper safe space. And there was room to talk about anything and everything.

And also we did quite a lot of general, like looking into different technical solutions. And she taught me a lot of stuff about React and I could teach her some stuff about how to do a lot of DevOps-y things. So we did a lot of really cool technical stuff, but we also just had a space where both of us felt really comfortable.

And like, I was always looking forward to going to the office that day because I knew I would have two hours in a meeting room where I could bring like the full me and I could just say what I was thinking without fear of that being the wrong thing. And now I might be misunderstood and all of a sudden I might be, you know, in my manager's office having to account for something that I never meant. And it was quite cool because we managed to kind of build this little thing.

And then other developers were like, what, what is it you, like, this seems like a really cool thing you're doing. Like you're learning quite a lot of stuff and we're like, oh, we have this junior developer, come join us. These are the rules of the space.

You have to be respectful. You have to be caring. You have to be open to any opinion because we want to learn and we want to keep an open mind.

And as the team grew, we kind of incorporated more and more people into this like skill up session. And eventually it was just like the team's book club. And it was really, really cool because it managed to kind of like, the space that we created there, like the psychological safety we had in that space slowly seeped out into the team.

And the team just became more and more like that little space because we included more and more people into the space and they would bring that way of interaction out. And it ended up being like a really, really cool team. And you could really tell the difference in what we could achieve and how quickly we could solve problems because all of a sudden we had a whole different way of communicating with each other because we could just say, hey, there's a problem.

Let's fix it. Instead of tiptoeing around how to raise this the right way. Is it a Jira ticket?

Is it a talk with your manager? Like how the corporate dance of not knowing how to do things the right way. Instead we could just be open and say, hey, there's a thing here.

How do we address it and spar with the other people and get the full knowledge of the team? And it's really, really cool. And you could really feel the difference from when we started.

It's a slow process though. Like we're talking a year or two from starting this project till it actually, you know, was a full on thing in the team. But it did.

[Pinja] (22:54 - 24:09)

You showed an example, right? And that's one of the key things is like if there is no psychological safety, it's really hard to start building it from scratch without showing an example. And you need to put yourself out there.

And it's very scary. And this is something I work as a team lead. I have a team of 13 people.

And I, OK, of course, I want to say that my team has psychological safety. But at the same time, this is something you need to nourish all the time. Right.

What I want to show as an example is that I make mistakes all the time. Unfortunately, I might forget to reply to a message. I send the wrong thing to a team member or something.

Then asking, saying sorry is one thing, like acknowledging like, oh, I'm sorry. This was not what I meant. I'm sorry this impacted you.

But also showing that to the team that in, like for example, in team meetings, I sometimes share mistakes that I made. It's not like, hey, gather around now. It's Pinja’s sharing time!.

It's not like that. But it's like every now and again, it's like I kind of take that responsibility and acknowledge the mistakes I made so that I'm in a managerial position so that I can show that, hey, it's OK that I also accept them from others. So I guess that I feel like showing example is one of the key things that that where you can start from.

[Alexandra] (24:09 - 24:48)

Definitely. But I also think it's one of those things where it's probably a little bit easier when you're the manager. Yes, it is, to lead by example.

Then when you're a team member and you kind of have to because just being vulnerable and open and honest can also make it really easy for your boss to crush you. Right. If you didn't actually have the space to be that open and vulnerable.

But I think I completely agree. This is an example. And that's also what we did there.

That was, you know, just creating that little space where we could have the right way of working that we actually dreamed of. And it's the same when you can openly state that I made a mistake. It's OK to make mistakes.

[Pinja] (24:48 - 25:07)

Yeah. But it's very important that you were able to start from that like you had a small space and very basically being able to control what happens here inside these walls here, but at the same time showing it to the others without having to be so vulnerable in front of them straight away before they they wanted to join when they saw that. Oh, this seems like fun.

[Alexandra] (25:08 - 25:36)

Yeah. It was also clear that we were having a great time. We were learning all these new things and we were always happy.

Like we were just happy and more productive on those days because we were just like that boost of energy from not tiptoeing and not using a lot of mental energy on figuring out how am I saying things and how does this come across and but just being able to be yourself that, you know, it freed up a lot of space in my head for, you know, being productive.

[Pinja] (25:38 - 25:56)

Isn't that what we mean when we say high performing teams? Right. Yeah.

And an enabler for that. And that's one of the things if we want to make innovations, we need to take risks. Risks don't happen without psychological safety and learning doesn't happen without making those mistakes.

[Alexandra] (25:57 - 25:57)

Exactly.

[Pinja] (25:57 - 26:06)

I guess that would be the theme of today. But hey, Alexandra, I've had so much fun talking to you about this. I think this is all the time we have for today.

But thank you so much for joining me today.

[Alexandra] (26:06 - 26:10)

Yeah, it was amazing to be asked. I really enjoyed it.

[Pinja] (26:10 - 26:21)

And thank you everybody for tuning in. We'll see you in the sauna next time. We'll now tell you a little bit about who we are.

[Alexandra] (26:21 - 26:36)

I'm Alexandra and I'm a senior DevOps consultant at Eficode. I am really passionate about process optimization, whether that be really technical or it be the ways of working and how we interact as human beings.

[Pinja] (26:36 - 26:51)

I'm Pinja Kujala. I specialize in agile and portfolio management topics at Eficode. Thanks for tuning in.

We'll catch you next time. And remember, if you like what you hear, please like, rate and subscribe on your favorite podcast platform. It means the world to us.