Psychological Safety in DevOps

Why Blameless Culture is an IT requirement Link to heading

The industry has been in the shift left movement for ages now. Moving security closer to the developer and the resources they consume. Things like github actions and similar technology have let us automate security activities and surface potential issues ever earlier in the development life-cycle. There are clear advantages to this process, making developers allies in security, preventing issues sooner, and raising general awareness. It can be easy to react to issues raised by automated systems and focus on solutions. This can be a more complex issue when we are dealing with issues raised by a team mate. It’s so easy to get caught up in either the blame game or bruising egos. The most successful teams I’ve been on have cultivated a blameless culture around the code they write. Recognizing that we are all human and make mistakes, we all miss things sometimes, sometimes very silly things. Building a team around the idea that we are all trying to build the best systems possible can help alleviate some of those traps.

Blamelessness in IT, no matter where you are in the stack, should be a default part of your team culture. We as leaders need to create a culture that allows and encourages people to speak out when they see something not right, and do so publicly. This can be really hard to do depending on the situation but if you can make it a standard all members of the team are expected to work towards it can get easier. Calling out a mistake in a coworker’s code can be challenging. Nobody wants to make someone they work with look bad. Recognizing that we all make mistakes though and holding each other to as high a standard as possible makes us all better engineers.

I do think the call out should be public however. A comment on a pull request or commit that maybe something could be written better, with examples, can be enough to inspire a new solution someone may not have thought of. Having a culture of questioning why we as individuals are doing things a given way makes us think about things more critically. It’s easy to fall into the “I’ve always done it this way” trap. New methods for doing things come up all the time. What was best practice last time may have changed. I mean we have all introduced an accidental memory leak or forgotten to trap for an edge case before. This is what peer review is supposed to be, teams free to question, not just rubber-stamp each other’s code. Does your team have a free enough culture to allow a JR dev to call out a SR on a PR, or even just ask a question?

I’ve worked on a number of teams where nobody would be willing to call out a SR dev no matter what they submitted. Who can call out the Brent¹ on your team? It doesn’t end with the ability to call people out though. You have to build a culture of open education to go along with it. If someone asks a question about why something was done a certain way the person being questioned should feel empowered to explain their solution and have a conversation, not defensively but collaboratively. There needs to be a culture of learning from each other on your technical teams to get the best from all those involved.

This culture has to start at the top in my opinion. Leadership needs to create that space for people to question and correct. Your technical teams are the subject matter experts in the systems you have deployed. They need to feel free to engage with leadership, even publicly, to make sure information is accurate to the best of everyone’s ability. I have always encouraged my teams to call me out if I say something wrong or stupid, even if it’s in a public setting. It is the job of leadership to define direction and keep the ship pointed correctly. There is no way for me to track every detail of every application’s current state. I have to rely on my teams to make sure I have the most correct information whenever possible. When my team calls me out, I shine a light on it. I give them the opportunity to set the record straight, take questions, and make sure everyone understands. Someone speaking up should be celebrated and never belittled. I think this example is important. If leadership is unafraid to be wrong then the people they work for will have similar expectations.

Having this level of psychological safety in your teams does more than just raise productivity and code quality. It also reduces stress on the team. People who feel supported in their workplace feel less stress and pressure and are therefore able to perform at a higher level. We want people to feel confident that they are doing work they can be proud of, not just work that makes the boss happy. People who feel safe and valued in their workplace are also better at managing changes in the work environment. In today’s business world change is the name of the game, you want your team to be able to manage that change as smoothly as possible. While this clearly requires good communication, there has to be a bedrock of trust beforehand or it doesn’t matter what reassurances you bring.