Psychological safety is a shared belief within a team that speaking up carries no personal penalty — that a question, an objection or an admitted mistake will be met with interest rather than punishment. It is a property of the group, measurable in what people are willing to say when the stakes are real.
Quick Overview
Picture a sprint retrospective. You ask what went wrong, and the room goes quiet. Someone eventually mentions an external dependency. Nobody mentions that the estimates were fantasy, that an architectural assumption was wrong, or that priorities changed halfway through. The meeting meant to produce learning produces theatre.
Now picture the same question answered by a senior developer: I made a bad architectural assumption, it cost the sprint real time, here is what I would do differently. The difference between those rooms is not technical skill. It is whether the room is safe to speak in.
This article treats psychological safety as a condition of the team rather than a capability of any individual in it — the question is whether a person can say “I don’t know” here, not whether that person is emotionally skilled or personally resilient — and it converts that condition into exercises a lead can run in the next sprint. Emotional intelligence and resilience are individual capabilities, covered elsewhere. What follows is about the group.
The exercises below are ordered by the interpersonal risk they ask someone to take: naming your own failure, admitting that you do not know, and contradicting the person running the meeting.
Why Interpersonal Risk Decides What an IT Team Produces
Software work is knowledge work, and knowledge work advances through argument, awkward questions and errors that get discussed rather than buried. Every one of those moves requires a person to accept interpersonal risk — of looking incompetent, of being blamed, of being the one who said the naive thing in front of colleagues whose respect matters.
Asking a question risks looking like you should already know. Admitting an error risks being held responsible for it in a review months later. Proposing an unconventional design risks being the person whose idea got laughed at. These are not imaginary costs, and a rational person minimises them by staying quiet and taking safe tickets.
The output of that rational caution is mediocrity, and it looks exactly like a team without problems. Nobody escalates, nobody argues, nobody admits anything, and the defects surface later — in production, in a postmortem where the true sequence finally comes out, or in a resignation letter. A quiet team is not evidence of a healthy one. Very often it is the clearest symptom available.
The judgement worth holding onto: silence in a technical team is a signal, not an absence of one. It tells you the cost of speaking has been calculated and found too high.
What the Term Means — and What It Is Not
The term was defined and popularised by the Harvard researcher Amy Edmondson, whose work on psychological safety describes it as a shared belief that the team is a safe place for interpersonal risk-taking. The word shared is doing real work there. It is not how brave one developer happens to feel; it is what the group collectively expects to happen when someone speaks.
It is not niceness. Teams with high safety argue hard, because disagreement about an idea stops being an attack on a person once the group is confident the person is not at risk. A team that has confused safety with politeness has usually stopped saying anything worth hearing.
It is not lowered standards. The relationship runs the other way: candid feedback is only possible where feedback is not dangerous, and candour is what makes standards enforceable. A team that cannot say “this design will not hold” has no mechanism for quality other than hope.
It is not a guarantee that every idea is adopted, and it does not remove difficult conversations about performance. It changes their register — about the work, with the facts on the table, not about the person.
The circulating claim that safe teams simply outperform unsafe ones is worth treating carefully, because the percentages attached to it in retellings trace back to summaries rather than to any study you can read. The mechanism is defensible without them, and the mechanism is what a lead can act on.
What Changes Downstream
Four things change, and each of them is a mechanism rather than a statistic.
The solution space widens. People propose the awkward option, the one that might be wrong. Some are. The ones that are not are why the team ships something better than the obvious design.
Defects get caught earlier, where they are cheap. A developer who feels safe says “I am not sure I have understood this requirement” before writing the code, and says “I think there is a problem here” while it is still a pull request. Both sentences are expensive in an unsafe team and almost free in a safe one, and both move discovery to the left of the cost curve.
Learning gets faster. A failed experiment is only useful if the team can talk about why it failed. Where failure is shameful, the analysis is sanitised and the same failure stays available to happen again.
People stay. Engineers leave teams where they cannot ask and cannot be wrong, and they usually give a different reason on the way out.
The Lead as the Team’s Climate
Psychological safety cannot be announced. The team infers it from hundreds of small interactions, and the lead is the single largest contributor to that evidence base, because everyone is watching how the lead reacts.
A lead builds safety by admitting their own errors and their own ignorance, out loud, in front of the team — the only way to demonstrate that doing so is survivable. By responding to a reported problem with curiosity: thank you for spotting that, tell me more. By asking for dissenting views and thanking people for them, particularly when the dissent is inconvenient.
A lead destroys safety by punishing mistakes, interrupting, criticising in public, or quietly ignoring a concern. Destruction is much faster than construction here — a single visible incident undoes months of accumulated evidence, because it is more informative than the months that preceded it.
This is why the capability sits in leadership development rather than in a values poster: the behaviours are learnable, they are specific, and they are hardest exactly when a project is going badly. Programmes such as active leadership for IT professionals work on that gap directly, rehearsing the reactions — to bad news, to dissent, to a mistake surfaced late — that determine what the team concludes about the cost of speaking.
Preparing the Ground Before the First Exercise
Do not open with the exercise. Open with the conversation about why you are running it. Explain what psychological safety is, why it matters for this team’s work, and what you are after — a group in which people are comfortable raising ideas and concerns.
Say plainly that this is a shared responsibility but that your part is different in kind, and commit to it in front of them. Ask permission to experiment with how the team works; a team that agreed to an experiment behaves differently from one that had it imposed.
Your own willingness to be visibly uncertain is the whole preparation. If you cannot be uncertain in front of them, nothing that follows will read as sincere.
The Retrospective Where Failure Can Be Named
The goal: make talking about errors ordinary, and make the lesson rather than the blame the unit of discussion.
How it runs: replace the standard “what went wrong” with a round in which everyone — including you — answers two questions: what was my biggest mistake or wrong assumption this sprint, and what did I learn from it?
Your part is not optional and it comes first. Share a real failure of your own: a decision that turned out badly, a judgement you got wrong. Not a diplomatic non-failure — an actual one. The team is calibrating on how much candour is genuinely permitted, and it calibrates on what you demonstrate rather than on what you invite.
When others start, listen and respond with curiosity rather than analysis. The temptation to fix the mistake in the moment is strong and it is the wrong instinct; the discussion is about the lesson, not the remediation. Thank people for the honesty specifically, so the reward for candour is visible to everyone present.
And then the hard commitment: what is said in that room is never used against anyone afterwards, in any form, including as context in an unrelated conversation months later. One breach ends the exercise permanently, and the team will not tell you it has ended. Run this way, the retrospective stops being a status ritual and becomes the place where the team’s real failure data lives.
Making “I Don’t Know” a Signal of Strength
The goal: establish a norm in which asking for help and admitting ignorance are rewarded behaviours rather than tolerated ones.
How it runs: this exercise is continuous rather than scheduled, and consists of modelling and reinforcement. Start with yourself. In meetings, when you do not understand something, say so plainly — I did not follow that, can you explain it differently — and when a decision exceeds what you know, say that too and ask the room for help making it.
The reinforcement half matters more than the modelling half. When anyone says they do not know or asks for help, your response is the data point everybody records. Thank them for the question specifically, treat it as a good question rather than a gap, and route it to whoever can answer. Doing that in public is the entire mechanism: it turns a moment that felt like exposure into one that looked like contribution, and the next person watching learns the exchange is safe.
The failure mode is subtle. A lead who says the right words while showing a flicker of impatience teaches the impatience, because tone is the more reliable signal and the team knows it. If the question genuinely irritates you, notice that and deal with it rather than performing the opposite.
Meetings Where Disagreement Is Safe
The goal: actively solicit dissent, so that decisions are made against the objections rather than in their absence.
How it runs: instead of presenting a finished proposal and asking whether everyone agrees — a question that reliably produces agreement and no information — present the problem and the context, then run a pre-mortem. Ask the team to imagine that it is six months from now and the project has failed spectacularly, and to write down, anonymously, what went wrong. Collect the predictions and work through them together. The framing does the safety work: nobody is objecting to your plan, everybody is describing a hypothetical past.
A second technique is to assign the role of devil’s advocate formally, rotating it between people. The nominated person’s job for that meeting is to find the holes, the risks and the weak assumptions in the proposal on the table. Because the criticism is their assigned function, it costs them nothing socially — including when the proposal is yours, the case where dissent is most valuable and least likely to appear on its own.
Close by thanking people for the objections and saying which ones changed the decision. An objection that visibly altered an outcome is the strongest evidence available that objecting is worth the effort. Where the exercise is new, pairing it with structured practice in empathetic communication in teams helps, because dissent lands differently depending on how it is phrased and received.
Measuring Something Subjective Without Pretending It Is Objective
Psychological safety is a perception, which makes it subjective, and subjective does not mean unmeasurable. The standard instrument is a short anonymous survey asking whether people can bring up problems, whether mistakes are held against them, whether it is safe to take a risk, whether asking for help is difficult, and whether their skills are valued. Run quarterly, it gives a trend line, and the trend line is the useful part — the absolute value depends on how the team reads the questions, the direction does not.
Alongside the survey, watch the qualitative indicators, which usually move faster. Do people ask questions in meetings? Are there real technical arguments? Do retrospectives surface anything the lead did not already know? Does anyone push back on an estimate?
An increase in difficult but constructive conversations is the most reliable signal that safety is rising, and it is worth naming in advance, because it feels like the opposite. A team that has started arguing looks, from outside, like a team with new problems. It is a team having its old problems out loud.
From Silence to High Performance: The Stages a Team Moves Through
Building this is a long game measured in months. The stages below describe what a team looks like along the way, the lead’s role at each point, and what to do next.
| Stage | Dominant behaviour | The lead’s role | What to do next |
|---|---|---|---|
| Fear and silence | Nobody speaks, errors are hidden, blame is the default explanation, retrospectives are worthless | Directive manager, often unaware there is a problem | Recognise the problem and start modelling the basics — admit your own mistakes in public |
| Caution and calculation | People share, but only when they are certain it is safe; care dominates | Guardian: reacts visibly to breaches and rewards acts of candour | Introduce structured exercises, starting with the retrospective on failure |
| Openness and collaboration | Candour is the norm; the team argues about ideas without difficulty | Facilitator: ensures every voice is heard and actively seeks dissent | Add the harder techniques — pre-mortem, assigned devil’s advocate — and delegate ownership |
| Innovation and high performance | The team experiments and takes calculated risks as a matter of course | Coach: steps back and supports autonomy | Protect the culture and grow the next leads |
The pattern worth noticing: the lead’s job shrinks as the stages advance. A team that still needs its lead to guarantee safety has not finished the work.
The Leadership Capabilities This Actually Requires
The behaviours described here rest on capabilities that are themselves developable, and naming them makes the development concrete rather than aspirational.
Emotional self-management comes first, because most of the damage a lead does to safety is done reactively — the visible irritation at bad news, the defensive answer to a challenge. Humility, in the unglamorous sense of being able to say publicly that you were wrong. Facilitation, meaning the ability to run a conversation in which disagreement happens without the group fracturing. And authenticity, not a soft addition to the list but the constraint on all of it: a team detects a rehearsed technique quickly, and a rehearsed technique reads as manipulation, which is worse than not trying.
These are trainable, but by practice under mild pressure rather than by reading, which is why leadership development here tends to be simulation-heavy. The neighbouring skill of reading the room accurately is treated separately in the material on EQ for managers and exercises that strengthen empathy.
Frequently Asked Questions
How does psychological safety differ from a team simply being nice to each other?
Niceness avoids conflict; safety makes conflict survivable. In a psychologically safe team, discussions get heated, decisions get challenged and mistakes get named — everyone is confident the argument is about the work and not about their standing. A team that substituted politeness for safety has usually stopped saying anything that matters.
How long does it take to build in an IT team?
Months rather than days. The first observable changes — more candour in retrospectives, more requests for help — tend to appear after several weeks of consistent practice. The pace is set not by the exercises but by the consistency of the lead’s own behaviour, particularly around admitting error in public.
Does this affect retention?
It plausibly does, and the mechanism is straightforward: engineers who feel unheard, who fear being wrong and who have no room to experiment tend to leave, giving compensation as the reason on the way out. Be sceptical of the numbers attached to this claim in retellings — widely repeated, rarely traceable to a readable study.
Where should a manager start?
Change your own behaviour in meetings before changing the meetings. Admit a mistake publicly. Ask the quieter people for their view by name. Meet a reported problem with curiosity rather than defence. Those signals cost nothing, and they are what the team reads.