Your Team’s Silence Is Telling You Something
Picture your last standup. How many people said “no blockers”? Now think about your last retrospective. How much of the feedback was genuinely useful, and how much was comfortable silence wrapped in a few polite observations?
If both of those feel familiar, you might have a psychological safety problem.
Psychological safety is the belief that you can speak up, ask questions, admit mistakes, and raise concerns without being punished or humiliated for doing so. It’s not a new concept; Amy Edmondson at Harvard Business School coined the term in 1999. But it’s one that the software industry still struggles with, often because the people in charge don’t realise they’re the ones creating the problem.
Simon Sinek describes it well in The Infinite Game:
A Circle of Safety is a necessary condition for trust to exist. It describes an environment in which people feel psychologically safe to be vulnerable around their colleagues. Safe to admit mistakes, and, of course, ask for help with the confidence that others will support them instead of using that information against them.
This post is about recognising the warning signs that your team doesn’t have that safety. In a follow-up, I’ll explore strategies for building it. But recognition has to come first, and it starts with looking inward.
What Psychological Safety Is Not
It’s worth clearing up a common misconception. Psychological safety is not about being nice. It’s not about avoiding difficult conversations, lowering your standards, or wrapping feedback in so many layers of positivity that the message gets lost.
It’s the opposite. A psychologically safe team has more difficult conversations, not fewer. The difference is that those conversations happen openly, early, and without fear. A developer who feels safe will flag a security concern the moment they spot it. A developer who doesn’t will keep their head down and hope someone else notices.
As Sinek puts it in Leaders Eat Last:
Our feelings of control, stress, and our ability to perform at our best are all directly tied to how safe we feel in our organizations. Feeling unsafe around those we are expected to feel safe – those in our tribes (work is the modern version of the tribe) – fundamentally violates the laws of nature and how we are designed to live.
If your team feels unsafe around you, their performance will reflect that. Not because they’re not talented, but because they’re spending energy on self-protection instead of problem-solving.
You Set the Tone
This is the part that’s uncomfortable to hear. If you lead a development team, you are the single largest influence on whether psychological safety exists within it. Your reactions, your language, your behaviour in meetings and incident reviews; these set the standard for what is acceptable and what is dangerous.
Travis Bradberry captures this in Emotional Intelligence Habits:
Exploding at anyone, regardless of how much they ‘deserve it,’ turns a huge amount of negative attention your way. You’ll be labelled unstable, unapproachable, and intimidating. Controlling your emotions keeps you in the driver’s seat.
Brene Brown goes further. In Rising Strong, she describes what happens when leaders lose control of their emotions as “chandeliering”: sudden, disproportionate eruptions that catch everyone off guard. The effect is devastating:
Uncontrolled eruptions of emotion (aka chandeliering) sabotage the safety that most of us are trying to create, whether in our families or our organisations. If it happens often enough, chandeliering leads to eggshell environments – fear-based settings where everyone is on edge.
You might think you handle pressure well. Most leaders do. But the question isn’t how you see your own behaviour; it’s how your team experiences it. One sharp response in a code review, one dismissive reaction to a question in standup, one visible frustration during an incident, and you’ve taught your team that speaking up carries risk.
I’ve worked with teams where the CTO’s reaction to a production incident determined whether the next one got reported or swept under the carpet. The CTO in question didn’t think of themselves as unapproachable. They genuinely believed they had an open-door policy. But the team’s behaviour told a different story.
Sinek frames this as a fundamental leadership responsibility:
Leaders are not responsible for the results, leaders are responsible for the people who are responsible for the results. And the best way to drive performance in an organization is to create an environment in which information can flow freely, mistakes can be highlighted and help can be offered and received.
The Warning Signs
So what does low psychological safety actually look like in a development team? Here are five patterns I’ve seen repeatedly across the organisations I’ve worked with.
Nobody Asks for Help
Developers working in isolation on problems they can’t solve, not because they prefer it, but because asking is seen as an admission of incompetence. They’ll spend three days stuck on something that a ten-minute conversation would resolve, because the perceived cost of asking is higher than the cost of wasted time.
Brene Brown’s observation in Dare to Lead applies directly:
There is nothing more uncertain than the creative process, and there is absolutely no innovation without failure. Show me a culture in which vulnerability is framed as weakness and I’ll show you a culture struggling to come up with fresh ideas and new perspectives.
If asking for help is treated as vulnerability, and vulnerability is treated as weakness, your developers will stop asking. They’ll also stop proposing new ideas, challenging existing approaches, and flagging problems early.
‘It’s Not My Fault’
When you hear “it’s not my fault” regularly, you’re hearing a survival mechanism. Blame deflection becomes the default response because the team has learned that fault-finding follows failure. Accountability disappears, not because people don’t care, but because admitting ownership feels dangerous.
Amy Edmondson explains the dynamic precisely in Right Kind of Wrong:
The important thing to remember about errors is that they are unintended – and punishing them as a strategy for preventing failure will backfire. It encourages people not to admit errors, which ironically increases the likelihood of preventable basic failure.
The irony is painful. Punishing errors to prevent failure creates the conditions for more failure. The team stops reporting errors. The errors don’t stop happening.
Security Concerns Go Unreported
This is the warning sign that should keep you awake at night. If your developers don’t feel safe flagging security vulnerabilities, your attack surface grows silently with every sprint. A developer who spots a potential Cross-Site Scripting (XSS) vulnerability but doesn’t report it because last time they raised a concern they were told “that’s not a priority right now” has just made a rational decision based on the culture you’ve created.
I’ve seen this in consulting engagements: teams where security bugs are treated as failures rather than catches. The developer who finds a vulnerability should be thanked, not questioned about why it exists. If your incident process focuses on “who introduced this?” rather than “what allowed this through?”, you’re actively discouraging the behaviour you need most.
Retros Produce Nothing
A retrospective where nobody has constructive feedback isn’t a sign that everything is going well. It’s a sign that nobody feels safe enough to be honest. If your retros consistently produce empty “went well” columns and vague improvement actions that nobody follows up on, the format isn’t the problem. The environment is.
Retrospectives only work when participants believe their input will be heard, respected, and acted upon. If the retro is a performance review in disguise, or if previous feedback was visibly ignored, your team will give you exactly what they think you want to hear. Which is nothing useful.
Your Best People Leave Quietly
High performers rarely complain before they leave. They’ve already decided. If you’re losing strong developers and the exit interviews are politely vague (“looking for a new challenge”, “time for a change”), dig deeper. Retention problems that correlate with team culture are a signal that the people who could most easily find work elsewhere have decided your environment isn’t worth the cost.
This is expensive. Replacing a developer costs somewhere between 50% and 200% of their annual salary, depending on seniority and the time it takes to bring someone new up to speed. But the real cost is what leaves with them: institutional knowledge, relationships with the rest of the team, and the signal their departure sends to everyone still there.
What Happens When Safety Exists
In my conversation with Safia Abdalla on The Modern .NET Show, she shared a story that illustrates what psychological safety looks like in practice. During her second engineering internship at a financial startup, she accidentally deployed a feature to production instead of her staging environment. This was a significant feature; one that had been scheduled for a coordinated marketing rollout.
Her instinct was to try to fix it herself before anyone noticed. When the CTO found out, he left a post-it note asking for a conversation. He was stern about the severity. But he was professional and understanding rather than antagonistic. The conversation focused on what happened and how to prevent it, not on punishment.
Safia’s reflection was telling:
It’s an indictment of the infrastructure that is set up to support deployment.
That framing matters. When the response to an incident is “how do we fix the system?” rather than “who did this?”, you create the conditions where the next near-miss gets reported instead of hidden.
That conversation with Safia had such an impact on me that I included two quotes from it in my Empathy, Sympathy, and Compassion talk. The principles she described aren’t abstract; they’re practical, and they determine whether your team trusts you enough to tell you when something has gone wrong.
The Cost of Silence
For the decision makers reading this, the business case is straightforward. Low psychological safety costs you money.
Hidden bugs become production incidents. Security vulnerabilities become breaches. Missed deadlines compound because nobody flagged the risk early enough to course-correct. Innovation stalls because nobody proposes ideas that might fail. Your best engineers leave for organisations where they feel safe enough to do their best work.
Sinek’s observation from Leaders Eat Last captures it:
Exceptional organisations all have cultures in which the leaders provide cover from the above and the people on the ground look out for each other. This is the reason they are willing to push hard and take the kinds of risks they do. And the way any organisation can achieve this is empathy.
The teams that deliver the most are the ones where people feel safe enough to take risks. That safety doesn’t happen by accident. It’s built deliberately by leaders who understand that their behaviour creates the conditions for everything that follows.
Holding Up the Mirror
Before you assess your team’s psychological safety, start with yourself.
- đ When was the last time someone on your team openly disagreed with you?
- đ How do you react when a developer reports a mistake they made?
- đ Do your retros produce genuine improvement actions, or comfortable silence?
- đ Would your team describe you as approachable when things go wrong?
- đ If you asked your team whether they felt safe raising concerns, would they feel safe enough to answer honestly?
I’ve sat in meetings where the most senior person in the room was the last to know about a critical problem, because everyone was afraid of being the messenger. The leader in question would have been horrified to hear that. They considered themselves open and approachable. But their team’s experience told a different story.
Brown puts it simply in Dare to Lead:
Daring leaders must care for and be connected to the people they lead.
Connection requires honesty, and honesty requires safety. If you’re not getting honest feedback from your team, the first place to look is at the environment you’ve created for giving it.
Where to Start
This post is about recognition, not solutions. Building psychological safety is a longer conversation (and one I’ll cover in Part 2 of this series). But there are three things you can do this week.
Listen to your next standup differently. Count how many times someone says “no blockers” versus how many times someone asks for help. The ratio tells you something about how safe your team feels.
Ask one question in your next one-to-one. “What’s something you’ve been hesitant to raise?” Then sit with the answer. Don’t defend, explain, or problem-solve immediately. Just listen.
Examine your last incident response. Did it focus on who caused it, or what allowed it to happen? The language you used in that response determined whether the next incident gets reported or hidden.
âšī¸ Note
This post draws on ideas explored in depth across several of my Continual Professional Development (CPD) reviews. If you’d like to go deeper on any of the concepts discussed here, I’d recommend:
- Playing the Infinite Game (Simon Sinek)
- Embracing Failure (Amy Edmondson, Right Kind of Wrong)
- Leading with Heart and Mind (Brene Brown, Dare to Lead)
- Leading with Empathy (Simon Sinek, Leaders Eat Last)
- Finding Strength in Vulnerability (Brene Brown, Rising Strong)
- Emotional Intelligence Habits (Travis Bradberry)
If you’re reading this and recognising patterns in your own team, that awareness is the first step. Sometimes it helps to have someone from outside the organisation hold up the mirror; someone who can see through the politics and report on what’s actually happening. If that sounds like a conversation worth having, let’s talk.