Safety in Discomfort: On Psychological Safety
Part of a "Software Engineering Enchiridion"
(Image: From my days riding a motorcycle across Europe and the US, speaking about software engineering, chaos engineering and resiliency)
“Difficulties are the things that show what [you] are.” — Epictetus
You don’t grow in a hammock. You grow when the world presses on you, when you’re forced to stand in the heat of the kitchen and still keep your hands steady.
Some people think psychological safety means never being bruised. They mistake it for comfort, for a padded room where no one says anything sharp. But comfort is not safety. Comfort is stagnation.
Real psychological safety is the opposite. It is the freedom to wrestle with ideas without wrestling with punishment. It’s the space where you can say, “I don’t know,” and not get laughed out of the room. It’s the moment when you tell your boss something they don’t want to hear, and you know your career won’t be burned to the ground for it.
This isn’t about singing comforting songs in retros. Not collective soul-searching and group therapy instead of growth. It’s about dissent without exile. Conflict without knives in the back. The right to be wrong, loudly, while still being trusted to try again tomorrow.
Teams that confuse comfort for safety end up soft, brittle, and dull. They fear conflict, so they avoid it. They fear failure, so they never take risks. And soon enough, they fear each other.
But the teams that get it right—they’re the ones with scars and stories. They fight like family, not enemies. They argue because they care, not because they want to cut each other down. They know the real danger isn’t in saying the wrong thing, it’s in never saying the hard thing.
So stop trying to make your team “comfortable.” Make it safe instead. Safe to risk, to learn, to call out the emperor when he’s naked.
Because growth doesn’t live in the beanbags. Growth lives in the fire.
Aphorism
Comfort coddles, but safety sharpens; real teams grow in the fire, not in the hammock.
Practices
Create space for people to say “I don’t know” without penalty.
Encourage dissent, but channel it toward ideas, not people.
Make space for everyone’s voice.
Celebrate risk-taking even when the outcome fails.
Protect truth-tellers from retaliation.
Normalise candour as a path to clarity, not as a personal attack.
Pitfalls to watch out for
Mistaking harmony for health: silence is not agreement.
Using “safety” as an excuse to avoid conflict.
Punishing failure in practice while praising experimentation in theory.
Confusing blunt cruelty with honesty.
Checklist
Did I make it safe for someone to voice an unpopular opinion?
Have I protected the person who called out a hard truth?
Am I rewarding effort, learning, and risk—not just perfect outcomes?
Did we resolve conflict without leaving scars that fester?
Is disagreement welcomed as a sign of engagement, not rebellion?
Some Examples
No: In a retro, a junior engineer raises a concern. The manager smirks, others pile on, and the topic dies. Next time, the engineer stays quiet. The team congratulates itself on “smooth” retros.
Yes: In a retro, a junior engineer raises a concern. The manager thanks them, invites discussion, and the team debates fiercely. They don’t all agree, but they leave with a plan—and trust deepens.
Psychological safety is not a padded room where no one bleeds. It is the ground rule that says: you can take risks without losing trust. You can be wrong without being ruined. You can dissent without exile.
Teams that confuse safety with comfort trade growth for fragility. They avoid hard truths and become brittle, soft, and dull. But teams that embrace discomfort with safety? They fight, they scar, they learn—and they become unbreakable.
Further Reading
Amy Edmondson — The Fearless Organization (psychological safety in practice)
Kim Scott — Radical Candor (balancing honesty with care)
Patrick Lencioni — The Five Dysfunctions of a Team (why absence of conflict kills trust)
Epictetus — Discourses (on the value of difficulty and trial)
If you enjoyed this article in the Software Engineering Enchiridion series you might also enjoy:
