Building Psychological Safety in Your Development Team
If you’ve been following this series, you’ve done two things already. In the first post, you looked at the warning signs of low psychological safety. In the second, you examined the emotional intelligence skills that make the work possible. This post is where we put it into practice.
Building psychological safety isn’t a project with a completion date. There’s no point at which you tick a box and move on. It’s a culture, and cultures are maintained through consistent behaviour over time, not through one-off interventions or well-intentioned announcements. This distinction matters, because a lot of what gets sold as “psychological safety work” in organisations is neither of those things.
The work falls into three areas: what a genuinely blameless culture actually looks like versus what most organisations merely claim, how to model vulnerability in a way that gives your team permission to follow, and how to use one-to-ones for what they’re designed for. These strategies apply whether you’re starting from scratch or rebuilding where trust has been damaged.
What a Blameless Culture Actually Looks Like
Most development organisations will tell you they have a blameless culture. In my experience, most of them don’t.
The claim is easy to make. It sounds right, it signals the values you want people to associate with you, and it costs nothing to say. Living it is harder, because a genuinely blameless culture requires you to reframe how you respond to failure at the moment when the instinct to assign responsibility is strongest, right after something has gone wrong.
I want to tell you about the first day I spent consulting at a small software company. The phrase “we don’t have a blame culture here” had come up twice in conversations before I started. On my first morning, the development team was called into a meeting room. A junior developer was invited to stand at the front of the room while her manager walked through a bug that had reached production.
The bug itself was a reasonable fix for its context. This was in the days of ASP.NET Framework WebForms, and the application had been throwing an unhandled exception when rendering a specific public-facing page. The developer had caught the exception, logged the full details, and shown the user a polite error message, which was standard practice for the problem as she had understood it. That fix had been reviewed by three senior developers, passed through internal developer testing, Quality Assurance (QA), and User Acceptance Testing (UAT).
What nobody had caught, at any of those stages, was that the affected page was indexed by search engines. The error message was now being indexed instead of the original content.
That was a legitimate problem. The response to it was not.
One developer stood at the front of the room, in front of her colleagues, while her manager walked through exactly what she had done wrong. She left the room in tears. She handed in her notice later that day.
A few days later, the same manager confided in me that the whole thing had been “a great way of showing my power over the team.”
This is what a blame culture looks like when the mask slips.
The structural problem is obvious in hindsight. A fix that passed through three reviewers, two rounds of testing, and UAT before causing an issue in production is not a developer failure. It is a process failure. The correct question is “how did this reach production without anyone identifying the Search Engine Optimisation (SEO) implication?” not “who introduced this?” When you direct accountability at the person rather than the system, you punish the wrong thing and teach your team something specific: that raising their head above the parapet carries risk.
Amy Edmondson captures the mechanism 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.
A real blameless culture is defined by its incident response language. The difference between “who introduced this regression?” and “what in our process allowed this through?” is the difference between a blame culture and a blameless one. Both questions are trying to prevent the next incident. Only one of them will.
Safia Abdalla’s experience on The Modern .NET Show illustrates the good version briefly but well. When Safia accidentally deployed to production, her manager’s response focused on the system rather than the person. That framing (treating the incident as an indictment of the infrastructure, not the individual) is exactly the language that tells your team it is safe to be honest about what went wrong.
The practical test is your next incident review. Listen to the questions that get asked. If the conversation drifts toward who introduced the problem, redirect it toward what allowed the problem to develop undetected. Do that consistently, and your team will notice.
Leaders Go First
You cannot ask a team to be vulnerable in an environment where vulnerability hasn’t been modelled. The team is watching before they decide whether it’s safe to follow. If you present yourself as someone who always has the answers, who never gets it wrong, and who responds to uncertainty with confident authority rather than honest acknowledgement, you have told your team that certainty is the standard. They will perform it, even when they don’t have it.
Going first means being the person in the room who says “I got that wrong” before someone else points it out. It means walking into a sprint planning session and acknowledging that the architectural direction you pushed for three months ago has created problems the team is now dealing with. It means saying “I don’t know” to a question from stakeholders rather than giving a confident answer you’re not certain about.
These moments feel disproportionately risky from the inside. They feel much smaller than they are to the people watching. But the effect is significant, because each time a leader demonstrates that honesty doesn’t have consequences, they move the waterline on what’s safe to say.
Ted Lasso handles this better than most management writing I’ve read, which is an odd thing to say about a fictional football manager, but the lessons are genuine. By the second season of the show, Ted is dealing with panic attacks. He doesn’t hide them from his coaching staff. He sees a therapist and eventually tells the people around him what he’s dealing with. In doing so, he creates a permission structure for everyone else to bring their own struggles forward rather than managing them alone. His vulnerability doesn’t undermine his authority. It establishes his credibility. His staff trust him more because he doesn’t pretend.
Brene Brown makes the case in Dare to Lead:
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.
The inverse of “leaders go first” plays out in Nate’s arc across the series. Ted had invested in Nate from the beginning: elevated him from kit man, sought his tactical input, gave him a platform and a voice. But as the team grew and the pressures on Ted increased, the individual relationship deteriorated. Ted stopped noticing. Nate, who had built his growing confidence on being seen, found himself invisible again. His response was to start performing confidence instead of building it, to take credit rather than share it, and to treat the people beneath him the way he had been treated before Ted arrived.
The lesson isn’t that Ted failed Nate by being human. It’s that psychological safety built on an individual relationship requires that relationship to be maintained. Building it and then letting it lapse isn’t neutral. The withdrawal of attention from someone whose sense of safety depended on it is its own form of damage.
Practically, going first is a specific habit rather than a general attitude. In your next code review, acknowledge one decision you’d approach differently with hindsight. In your next team meeting, ask a question you genuinely don’t know the answer to. In your next incident review, name a systemic gap that falls within your responsibility. Each of these is a small act. Repeated consistently, they accumulate into a culture.
One-to-Ones: What They’re For and Why Most Leaders Get This Wrong
Most leaders, particularly newer ones, treat one-to-ones as status updates. The format tends to go: how is the current ticket progressing, any blockers, anything I should be aware of. Twenty minutes, fortnightly, box ticked.
That’s a standup with one person. It isn’t a one-to-one.
The one-to-one is the most underused tool a leader has for building psychological safety, because it is the one context in which a developer can raise something they wouldn’t say in a team meeting, flag a concern they’re not ready to bring to a retrospective, or simply be honest about how things are without it being a public act. Done well, it functions as an early warning system, a trust-building mechanism, and a private channel for conversations that don’t happen anywhere else.
Done badly, it becomes a performance review every two weeks. That conflation is what makes developers stop being honest in one-to-ones, and once they stop, you’ve closed the only private channel you had.
Ted Lasso does his homework. That’s what distinguishes his conversations with players from a standard check-in. He understands that Jamie Tartt’s defensiveness has roots outside the football pitch. He recognises that Roy Kent needs a different kind of challenge as his playing career winds down. He knows that Dani Rojas’s relationship with the game is about joy, and that protecting that matters. He doesn’t arrive at those conversations having decided what to say. He arrives knowing who he’s talking to.
The point isn’t to conduct therapy, and it isn’t to manufacture a personal connection. It’s to treat the people you lead as individuals whose circumstances affect their work, and to stay curious about those circumstances rather than assuming you already understand them.
Simon Sinek frames the leader’s role in Leaders Eat Last:
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.
A structure that holds up in practice:
Start personal rather than professional. Before anything about work, ask how the person is doing and mean it. Not as a greeting, but a genuine question with space for a real answer. Matt Abrahams captures the distinction well on his Think Fast, Talk Smart podcast: “be interested, not interesting.” Your job in that conversation is curiosity, not performance.
From there, ask what they’ve been hesitant to raise. This is the question from the first post in this series. The one-to-one is the safest context in which to ask it. Then sit with the silence that follows. Don’t fill it.
Ask what they need from you. Not from the project or the team. From you specifically. The answer is often “nothing, just knowing I can come to you.” Sometimes it’s actionable. Either way, the act of asking signals that you see your role as service rather than oversight.
Close with something concrete. If they raised something you’re going to act on, say what you’re going to do and when. The fastest way to destroy trust in a one-to-one is to listen well and then do nothing. Following through on small commitments is how the relationship develops into something the developer actually values.
A few things to avoid: don’t open your laptop during the conversation. Don’t spend the session solving every problem they raise before they’ve finished explaining it. Frequency matters too: weekly or fortnightly, 30 to 45 minutes. Less frequent than that and the relationship doesn’t develop; more frequent without the substance to fill the time and it becomes a ritual neither of you looks forward to.
Building Safety vs. Rebuilding It
The strategies above apply in both contexts, but the approach differs depending on where you’re starting from.
Building from scratch gives you the advantage of setting norms before bad habits form. Your first incident review is the most important one you’ll run, because it establishes the pattern. If you handle it by asking what the process allowed rather than who caused it, you’ve shown your team something about what leadership looks like here before they’ve had reason to believe the opposite. The same is true of your first code review comment, your first retrospective, and the first time something goes wrong in a one-to-one and you don’t use it against the person.
Early signals carry disproportionate weight. People pay close attention to how new leaders behave because they’re building a model of what’s safe. Use that attention deliberately.
Rebuilding is harder. If the team has experience of blame, dismissed concerns, or violated confidence, the trust deficit can’t be erased by announcing that things are different now. The team has heard that before. What they’re watching for is whether the behaviour changes, and whether the change holds when things get difficult.
In a rebuilding context, the first thing worth acknowledging is that something went wrong. Not in a way that reopens wounds or demands a public reckoning, but honestly enough that the past is named rather than papered over. “I know that the way incidents have been handled here hasn’t always felt fair” is more credible than a fresh-start speech that acts as if the history didn’t happen. People can tell the difference between acknowledgement and performance.
Brown writes in Dare to Lead:
Daring leaders must care for and be connected to the people they lead.
Connection in a rebuilding context is earned through repeated small acts: the incident review that redirects to systems rather than individuals, the one-to-one answer that wasn’t stored and used later, the code review where a mistake is treated as a learning point rather than evidence. Trust degrades quickly and rebuilds slowly. The timeline you have in your head for how long this takes is almost certainly shorter than reality.
One trap worth naming directly: the team-building exercise. The impulse to manufacture connection through an away day or a social event is understandable, but activities designed to create trust rarely produce it. In a world where teams are distributed, partly remote, and juggling competing commitments, manufactured social time often adds friction rather than removing it. Real trust comes from working through difficult things together: from the incident handled well, the hard conversation had openly, the mistake acknowledged without punishment. Those moments build something. A quiz night doesn’t.
Closing the Loop
This series started with a simple observation: your team’s silence is telling you something.
The sequence in this series was deliberate. Warning signs first, so you could see what you were dealing with. Then the emotional intelligence work, because the practical strategies in this post only hold if the inner work is in place. You cannot model what you have not examined in yourself.
None of this is a one-time fix. Psychological safety reflects your behaviour across hundreds of interactions over months and years. The work is in the consistency, not in the gestures.
You have to go first. The team will not be vulnerable before you are. They will not flag failures before you acknowledge yours. They will not trust the blameless culture until the first incident review proves it. Every strategy in this post requires you to act before your team does, without any guarantee that they’ll follow. That’s what leadership is.
ℹ️ Note
This post completes a three-part series on psychological safety and leadership in development teams. If you’re joining partway through, the full reading order is:
- Your Team’s Silence Is Telling You Something: the warning signs
- The Skill Nobody Taught You: emotional intelligence as the foundation
- This post: the practical strategies
For deeper reading on the ideas discussed across this series, the following CPD reviews are worth your time:
- 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)
If you’re reading this and wondering where to start with your specific team (whether the warning signs are serious enough to act on, where the trust has broken down, or how to have the conversations that need to happen), that’s exactly what consulting conversations are for. Let’s talk.