Culture of Safety
We as an industry talk about team culture—what is "good" culture, what is "toxic" culture—that good culture is collaborative and where people will go the extra mile, where people take responsibility for the big picture, but I don't often find people talking about safety. And by safety here, I primarily mean psychological safety—though other forms of safety are really important, too.
People do their best work when they are not worried.
When they don't have to sound smart. When they don't have to worry about maintaining a reputation. When they can just ask that question that might expose gaps in their knowledge, because then they can be taught, can learn, can grow.
This safety is something that must be cultivated and reinforced over time. It doesn't come easily and is something that can be destroyed quickly.
There are many ways to cultivate this sense of safety, but the biggest thing is consciously avoiding and discouraging behavior that is harmful to that goal.
As a leader, it is my job to set an example myself, but also to shape the behavior of those I lead to create this culture. There are a few key ways that I go about doing that: blameless postmortems, office hours and other meetings where there are no "silly" questions, patience, always being willing to teach or learn, not having to be right, letting others' answers stand, and being willing to learn together when I don't know the answer.
Blameless Postmortems
When things go wrong—and they will, inevitably, go wrong—it is important to address why they went wrong. I think most well-functioning teams understand this and have processes or practices for postmortems.
"Blameless Postmortems" as a buzzword is gaining popularity and I think that many teams and managers claim that they have blameless postmortems, but I've also seen enough cases where people who used that term didn't understand what it was or why.
What it means for a postmortem to be blameless is that the focus is on what process failed, what technical flaws existed or interacted to cause a negative outcome, and not on who did what, or worse, who caused the outage or who broke it or who should have done things differently.
This is really important because it moves the discussion to productive diagnostics, mitigations, and remedies and away from what people did. It makes people feel safe to engage with the process rather than feeling like they have to defend their own actions or deflect blame.
If you feel like you have to ascribe it to "human error," then it means that the process guardrails have failed, and the discussion should focus there rather than the person whose actions or inactions "caused" the error. We know that people make mistakes. It is one of the fundamental properties of being human. We shouldn't punish that. Instead we build processes that account for human fallibility—that assume it will happen and protect against it.
In many cases, I find that even if ICs know this, sometimes leadership does not approach postmortems with the same respect for the blameless culture. This can be particularly pointed when someone in upper management is upset about an issue and wants names of people involved. Ultimately, it lands on leadership at all levels to push back on this behavior, and gently, but firmly deflect to the actual issues, and then follow up in private to educate and reinforce the value of blameless postmortems.
No Silly Questions
The temptation to save face by not asking questions when something is confusing or not understood is often strong. We don't generally like showing others that we don't know something—especially in professional environments where we're being paid to know things, where we are judged on how competent we are.
But when we don't ask questions, we don't get the opportunity to learn. We may misunderstand what was trying to be communicated. We may waste time trying to figure it out on our own.
By making meetings a safe space for silly questions, by engaging with them in good faith, and by teaching, I cultivate a space where people feel free to ask questions, even if they think they should already know the answer.
I also model this by asking questions myself when I do not understand. "I am not sure I understand that, can you help me understand?" is a great generic question, but it can be tailored to the specific context for better effect.
Patience and Understanding
How you respond to others' questions or gaps can easily make or break the interaction, regardless of whether your response actually solves anything or not.
Responding with exasperation, impatience, or "as I just said," will do more to destroy the felt safety than any positive response could win back.
Instead, responding with patience, with understanding, or affirmation will go toward making people feel safe. A genuine "good question," "thanks for asking," or "ahh, I should have elaborated," can go a long way to reframing it as a welcomed behavior instead of an imposition. You can even show excitement: "oh, you're going to love this trick! If you use the --color option to ..."
Seeming genuinely happy to engage is important.
Willingness to Teach or Learn
When someone shows a gap in understanding—and especially when someone is brave enough to ask directly for help—it is important to respect that by teaching. Not condescendingly, not "I can't believe I have to teach you this," but mentorship that respects their intelligence.
We all have gaps—none of us are omniscient. Opportunities to teach should be honored with excitement. You have the opportunity to help someone grow, learn, and become better at what they do. They'll be better equipped to solve problems in the future and your team will be more effective overall.
I find a personal fulfillment in seeing someone grow in their craft—watching them get better under my mentorship. There aren't many better affirmations of my own leadership than seeing those on my team getting better at their craft through my leadership. It's more validating than my own performance reviews. It reflects directly upon me and my own values and purpose in a way that goes beyond any other validation of my work.
It is also really important to realize when you have something to learn. Earlier, when I said we all have gaps, that includes leaders. You have the chance to model the learning, too. If someone knows more than you about something, listen. Ask follow-up questions. Be curious. Don't get defensive. Be excited to learn something new.
Being Wrong
We all will be wrong at some point. Sometimes even confidently wrong.
There is often a moment where we realize, internally, that we got it wrong, and in that moment, there is a choice to be made. Do we try to hide the fact that we were wrong, or do we do the vulnerable thing and admit we were wrong?
There's a strong instinct to hide it. To deflect, to move the goal posts, to go "well, what I actually meant," to try to use logic and semantics to still "win" the argument. This is because we are scared of being seen as wrong.
This damages the safety others feel. People feel like even if they're right, it doesn't matter, so what's the point? Junior people may even be gaslit by your argument gymnastics and the power imbalance, which will just reduce their own confidence and ability to perform, let alone their morale.
Instead, we should admit when we are wrong and be happy to be wrong because it means we get to learn and grow ourselves. There is a philosophy "strong opinions, loosely held," which means that we can have opinions about the right way to do things, and we should be diligent about those opinions, but that we must be open to being wrong, and when presented with new data, update our opinions. Loosely held is the hard part.
It can even be helpful to thank the person who pointed out you were wrong. It drives the point home that you welcome being corrected and it acknowledges and respects the fact that correcting a leader can often be a difficult thing to do.
Letting Others Be Right
Being a leader, there is often a desire or expectation to weigh in on everything, and to have the final word.
We like to restate solutions in our own words—to add one last bit of advice or caution or point. It seems hard sometimes to just say "awesome, your approach looks great to me, do it your way."
But part of building a culture of safety is showing people that they can be right on their own. When you insist on having the last word, or editing an already good plan just because someone else came up with it, it undermines the confidence that they were right. It strips them of the full weight of success when it goes well.
Not adding or correcting when no correction is needed shows trust and faith in people. It makes them feel safer because they know you could have added something, but trusted their ability by letting their solution stand as-is.
Learning Together
Sometimes no one knows the answer. Someone asks a question and there isn't an immediate answer to give. People look to you as a leader and you don't have the answer either.
In that brief moment, there are a few options that you might quickly consider, internally: you could guess, you could deflect, you could defer, you could delegate, or you could dig.
Guessing is only acceptable if you caveat it strongly: "I don't know how that works, but if I had to guess, I'd say ..." but even then, it's not a great option. And you certainly shouldn't guess and pass it off as actual knowledge.
Deflecting is also not a good option. People will realize that you didn't address the topic and it will harm morale over time. Deferring, where you say "I'll find out and get back to you" only works if you take responsibility to figure out the answer and then come back later with a real answer.
Which leaves us with the only two good options. Delegating shows trust in the abilities of the person you delegated to, and gives them an opportunity to teach others what they learned. But if you just delegate back to the person who asked the question, you've not actually helped them.
Digging together as a group, when time allows, does a lot of good things. It shows that you don't know everything, but it models how to find out. It teaches, but also doesn't put you above them. And it shows you care about the question enough to actually spend team time on it. It's a strong "show, don't tell" signal you can send.
Collaborative digging also shows junior engineers that leaders have to struggle through documentation, search Google, chase red herrings, and not always know everything, while also showing them how leaders find the answers when they don't know.
Conclusion
Altogether, when you do these things consistently and when you advocate for these behaviors both within your team as well as across the larger organization, you go a long way towards making people feel safe to be human. Safe to learn. Safe to try new things. Safe to fail. Safe to succeed.
And when people feel safe, they perform better, have better morale, stay longer, grow faster, and grow into better engineers.