If you're not hearing bad news from your teams, guess what? That is the bad news.
Hi, I'm Lance Dacy, otherwise known as Big Agile, and today we're going to talk about the ever-growing topic that has quietly become the single biggest differentiator between good teams and great ones, especially in hybrid and distributed remote environments.
Psychological safety—that's the hidden elephant in the room. I find it present in conversations with teams all the time. Every leader I talk to says they support it. And it's the thing that every developer silently evaluates before they say a single word. Leaders want it. Developers are asking themselves, "Do we really have it?"
Here's what we're going to cover today:
- What psychological safety really is (and isn't)
- Why hybrid teams lose it faster than in-person teams
- Google's Project Aristotle and the top five predictors of high-performing teams
- How Scrum and Kanban can strengthen or sabotage psychological safety across distance
- Leadership behaviors that turn fear into learning
- Three actions you can take this week to raise the bar for your hybrid team
What Psychological Safety Actually Means for Teams
I want to show you a picture here of Amy Edmondson because we hear that name quite a bit in our space. She's done two decades of research across hospitals, factories, schools, and technology organizations, and she discovered a hard truth: people don't stay silent because they lack ideas. We all have ideas. They stay silent because they fear the consequences of speaking.
So what does psychological safety actually mean? It means:
- I can speak up without fear of embarrassment
- I feel like I can surface uncertainty without being judged by the team
- I can admit mistakes early before they compound into bigger mistakes
- I can offer half-baked ideas without worrying if my team is going to think they sound dumb
That's what we tend to see as psychological safety—the way it manifests in teams.
What Psychological Safety Is NOT
When you hear this word, many people think it means being nice, lowering standards, unlimited comfort, or avoiding conflict. That is not true at all. The best teams in Edmondson's study actually reported more mistakes—not because they made more mistakes (we all make mistakes), but because they detected the mistakes and issues earlier and were able to surface them.
Now, hybrid work tends to make issue detection even harder and silence a bit easier. Not for every team, but for a lot of teams.
Why Hybrid Teams Lose Psychological Safety Faster
In today's global market, the debate is ripe: Do we return to office? Keep remote? Do hybrid? Either way, you're going to encounter remote forms of collaboration and working. Brian Miller and I did a podcast not long ago on this very topic, and we ended up saying we really don't have an answer because it all depends. There are a lot of variables at play.
But what we do know is that if you're tending to collaborate in a more hybrid or remote fashion, that tends to bring in some remote tension that you might see. Remote forms of collaboration introduce friction you can't see, but you can absolutely feel it.
Yes, some teams do this well. When I was doing the podcast, we actually talked to teams that perform okay in a remote environment—they've learned how to do it. So I don't want to cast a net across everyone, but I do believe that a lot of teams suffer from this.
The Remote Tension Factors
Here's what many teams feel:
Delay amplifies doubt. A two-second pause on Zoom might feel like a rejection.
Less spontaneous conversation. When we're in person, we typically have hallway chats. We're like, "Hey, quick question." We might learn through osmosis—just sitting around listening to other conversations.
No micro-repairs of trust. When you're in person, there's this trust that builds just inherently because I interact with you day in and day out. When you're remote, unless you're hanging out every day, that's very hard to do.
Higher fear of judgment. When you have cameras, recordings, chat transcripts, note AI takers—everything feels a little archived. That's kind of scary.
Unequal visibility. People in the office get a lot of context while remote folks get a bunch of assumptions that they're making as they're sitting at their chair.
Cognitive load multiplies. Through multitasking, Slack pings, overlapping time zones, silence becomes the path of least resistance. You just got to survive.
Hybrid work rewards the confident and penalizes the hesitant. That means your best insights may be sitting on mute. I call it the Zoom mute button problem.
Google's Project Aristotle: Real-World Data on High-Performing Teams
What I wanted to do today is bring you real-world scenarios. That's one of the things I like to see when I'm working with teams. So let's talk about Google's Project Aristotle.
Google studied 180-plus teams across the company and analyzed 250-plus variables. They expected performance to correlate with a lot of things we would think about when trying to identify high-performing teams. Keep in mind that Google has 45,000 or so software engineers (just in the US alone) if we're talking about tech teams and development.
When you think about looking at these high-performing teams and trying to find a correlation with features that could predict better outcomes when putting other teams together, they expected to find things like:
- Seniority of the people on the team
- Co-located teams performing better
- Longer tenure with the company
- Good personality mix on the team
But none of that mattered, if you can believe that.
The Top Five Predictors of High-Performing Teams
1. Psychological Safety
By far, this was number one, and it matches Edmondson's research exactly. If people feel safe speaking up, everything else becomes possible. We have to understand what that is and how to create an environment that fosters it.
2. Dependability
A far distant second was dependability. Team members reliably complete their work on time. Scrum and Kanban actually naturally support this through the transparency and the things we can look at with teams.
3. Structure and Clarity
People felt good when they had clear roles, clear responsibilities, and clear expectations. Now these tend to decay quickly in the hybrid environment unless they're codified intentionally. A lot of times when I put teams together, it's one of the first things we do—organizational design. Making sure we've got teams set up with structure, clarity, and roles. What skills are we lacking? All of that good stuff.
4. Meaning
The people working on these things have meaning. The work matters for personal reasons, not just the business ones. This helps tap into intrinsic motivation, which Dan Pink has done a lot of good studies on, especially with the kind of knowledge work and complex, critical thinking type work we're doing in software. Intrinsic motivation is a really powerful thing for high-performing teams.
5. Impact
People can see how their work changes outcomes at the organization. Hybrid teams often lose this connection unless leaders do a really good job actively showing it or it manifests somewhere.
The Big Takeaway
Hybrid teams don't necessarily suffer from the distance. The world is smaller these days with technology. We can get together face-to-face without being in the same room. What they suffer from is uncertainty, and uncertainty can kill contribution to the team.
They're sitting alone building out their own assumptions. They're uncertain about things. They can start telling themselves stories. I'm sure you've been there before as well. That kills contribution to the team. They start telling themselves things that they don't feel very confident about.
How Scrum Can Help Create Safety (If We Don't Break It)
This wouldn't be a Big Agile video if we didn't talk about Scrum, Kanban, or something like that. So I want to talk about how Scrum can help create safety if we don't break it along the way.
The Daily Scrum
This is probably the biggest one that causes teams a lot of struggle. The Daily Scrum is not a status meeting.
When psychological safety is strong, it's okay for people to stand up and say, "I'm stuck. Can someone help?" or "I see this freight train coming, let's do something about it" instead of just quietly sitting by. We used to play project chicken when I was a project manager.
When psychological safety is low, it's like, "I'm good"—and the translation is "I'm drowning, but I don't want any judgment." Also, people think, "I don't want to drag the meeting down. People will hate me if I just keep going on and on."
There's got to be some working agreements as well. When we're collaborating and having meetings, I often use the ELMO technique so everybody feels safe. If we feel like we're going down a rabbit hole, just call out ELMO—Enough, Let's Move On. I tend to laugh about this. In the in-person classes I do, I typically have these little Elmo dolls that I put at the table, and sometimes that will help people feel a little bit safer. Obviously in the remote world, that's not as practical.
Sprint Reviews: Transparency Over Throughput
Sprint reviews in Scrum can help with transparency. They're about learning from reality. Our reviews should be more curiosity-driven, not necessarily just a stakeholder interrogation. It's a really good opportunity to collaborate with our stakeholders at that time and make them feel safer that they're getting more frequent check-ins with the team. That builds those micro-trusts I was talking about.
Sprint Retrospectives: The Learning Zone
Of course, we can't escape the retrospective. This is where Edmondson's studies on the learning zone come in. To me, the sprint retrospective is where fear either can dissolve or compound. Teams need these rituals that pull quieter voices forward—not burying them. They've got to practice them.
I get a lot of debates on LinkedIn and other social networks where people don't like the cadence of the sprint and say we don't need a time box anymore. But I'm going to tell you, these ceremonies or rituals—I certainly don't want to do any kind of empty ritual—I want to have frequent check-ins that have outcome-driven possibilities. This retrospective is teaching the team and getting them more comfortable talking about their problems.
I do something similar with my kids. I've got four kids, and I try every week, every Sunday, to sit down with each one of them and say, "Hey, how's it going?" I might have a little teaching topic I want them to think about for that week. Really, all I'm doing is building in time that they know they can bring me any problem as soon as they start trusting that process.
If I just waited until they brought a problem, sometimes it's a big one and they think, "I don't want to talk to Dad about this." But if they know every week we're going to connect and it becomes familiar, those are the micro-trusts. Eventually, what I really want them to do is be able to tell me anything. I don't want them to feel like I'm going to judge them. Yeah, I'm their father, so I may have to discipline them a little bit, but I don't want them to suffer silently. That's what happens a lot with our teams if they don't have a common way to do that.
I think the sprints and the Scrum framework give us that pattern and that cadence to help us do that.
How Kanban and Scrum Can Strengthen or Weaken Psychological Safety
Let me showcase some information about visualizing work. With Scrum and Kanban, we can visualize blocked work. A blocker's not a confession—it's a signal. If blockers don't move for days, there's probably fear somewhere. We want flow, not fear.
Imposing work-in-progress limits can help expose system issues a lot earlier than sitting idly by. But only if people feel safe to honor those working agreements.
I've talked a lot in the last few weeks, and maybe even the last quarter, about flow metrics—cycle time, throughput. These aren't necessarily performance grades. They're signals. They're helping us figure out: Are we getting better in our system or not?
A high degree of safety means we can highlight that cycle time is spiking and ask, "What's going on?" Low safety means cycle time is spiking and people are asking, "Who messed up?" We don't want that either. Leaders have to help foster that environment.
The difference, to me, is everything on the tone and how you approach these metrics.
Leadership Behaviors That Build Safety Across Distance
Moving on to the last bit I want to talk about: leadership. What are some leadership behaviors that can build safety across that distance?
Edmondson's research is crystal clear when it comes to this: safety is a leadership behavior, not a trait. It's not a team trait we're trying to get. It's a culture. It's an environment.
Key Leadership Actions
Frame work as learning, not just execution. Leaders need to admit the idea that, especially in technology, this work is complex. The questions you bring up help us get it right. There's no one right answer. Collective intelligence—none of us are smarter than all of us together.
Model fallibility. Say things like, "Hey, I might be missing something here. You all have the context. You all are the experts. I don't have that context." Leaders are automatically setting the permission structure by saying, "I don't have all the answers. Please help me." Know that you're trying to build a culture to do that.
Make speaking up a responsibility, not an option. I like to tell teams that this is something I'm granting as a responsibility in the organization. It's not just coming from leadership—the teams have the best data.
Use structured participation techniques. Some common things you can research are round robins, chat waterfalls, confidence votes, fist-to-five techniques, asynchronous feedback in Mural and Jira. Silence is not agreement. Silence is avoidance, and that's a signal that something's wrong.
Respond productively to bad news. We want people to be able to bring us bad news. Like I said at the beginning of the video, your first reaction is going to determine whether you hear the next piece of bad news or not.
Say things like, "Thank you for catching this early, John. I really appreciate that." When people bring you bad news, use that as an opportunity to foster trust.
Three Things You Can Do This Week
Regardless of your position, here are things you can do in your teams:
1. Add a "risk silence" question to your retrospective. What's one thing we've noticed that we haven't been really talking about? To me, that's a game changer.
2. Shift the Daily Scrum from status to risk. Don't talk about what you did yesterday and what you plan on doing today. What are the risks that we see? What kind of help do we need? What's unclear? Where are we uncertain? What might slow us down next? That's what we want to talk about.
3. Start a 15% experiment. Give your team a space for small experiments that might improve collaboration and flow. Don't give up on them the first time they don't work. At least try them a couple of times.
Building a Fearless Environment
Whether you're hybrid, remote, or returning to office, the work isn't the enemy. Fear is. Silence is. Isolation is. People sitting there not really saying what they want to say.
If you want a team that adapts faster than your competition, the one thing you need that Google and Edmondson and every other high-performing agile team I've ever seen agree upon is this: a fearless environment where truth moves faster than problems.
A fearless environment where truth moves faster than the problems.
Ready to build high-performing teams with stronger psychological safety?Explore the comprehensive training programs and classes that Big Agile offers to help you transform your organization's approach to agile collaboration and team dynamics.