What are the best software development teams?
Are those the one that are using the best programming languages? The best tools? Do we really need a Kafka Cluster set up with Kubernetes on AWS that is running an Event Sourced CQRS system using hexagonal architecture and property-based testing to be successful? Do we need to be agile and use tools like SCRUM or SaFE?
I love statically typed functional languages like F# or Haskell. And I love how much safety it gives you if you make illegal states unrepresentable. Does this mean we need to have static types to be successful? Dependent Types? Liquid Types?
Those are all either awesome things or empty buzzwords. You can decide this for yourself or for your specific context.
No matter the technology or the way of working you choose, I am convinced that only one type of team can be truly successful over a prolonged period of time: A team that's root value is constant learning.
We live in a complex world in which we constantly need to make decisions. We often need to make those decisions in complicated environments in which best practices are not applicable anymore. We need to be able to sense for specific problems, analyse them and act accordingly. This can be hard to do if we are not constantly learning. If we are dealing with complex environments, we cannot even analyse before we act. We need to be constantly experimenting and be prepared for failures to go forward (compare to the Cynefin framework by Dave Snowden).
We need to fail often. And then we need to use the feedback given by our experiments and failures to improve the behaviour of the system we are living or working in. But we have two problems. The first one is that feedback can only influence future behaviour. There is just no chance that we can go back in time and use all the learnings to not make the mistakes we made and to take the chances we did not know or never learned of. The second problem is that the bigger a system is the slower it is changing its behaviour. So, to learn from our mistakes and improve on the way we need feedback that is fast, and we need feedback that is continuous. Therefore, we need a culture where ideas are heard, feedback is welcomed, and mistakes are embraced or even honoured. This is not only true for software development teams; it is also true for any kind of team or organization.
I am absolutely convinced that psychological safety is a key factor to reach those goals.
Psychological Safety is the belief that the work environment is safe of interpersonal risk taking.
To understand what this means we should have a look at how we behave when we do not feel this safety.
Have you ever been in a meeting where you did not understand something but did not speak up because you felt "everyone around you knows the answer"? Have you ever had the feeling that something is not right about a decision your team is making but you did not speak up because you did not want to be the nay-sayer? Have you ever witnessed someone making a mistake in production and try to rug it under the carpet or have you been this person yourself? All these behaviours come up and are normal when we do not feel psychologically safe in our work environments or in other words when we do not have the belief that our work environment is safe of interpersonal risk-taking. If this is the case, we do not want to look dumb, so we do not ask questions, we do not want to look incompetent, so we do not admit mistakes, we do not want to be heckler, so we do not speak about the risks we are seeing. In an extreme case, we are managing a self-image and trying to secure our job, our position, or our status. The problem is that this behaviour is diametral to the success of our company, our team and eventually of ourselves. This behaviour is the enemy of learning.
What happens if 80 percent of the attendees of the meeting where you did not dare to ask the "stupid" questions have the same questions? How can we really have a successful outcome of that meeting? How can we commit to any actions if people have not understood what most of it is about? What if the one brilliant but slightly out of the box idea to improve our system and to cut 60 percent of the cost was never articulated because the person was afraid to look dumb in front of their peers or their boss? How can we learn from mistakes, when the discovered security breach was rugged under the carpet without any retrospective and post-mortem?
The problem is that we cannot just tell people that "my door is always open; you can always come to me" and expect everything to be fine. When we do not feel safe in our team we will avoid speaking up, even when we see big risks ahead. We will keep our ideas to ourselves and when our mistakes are held against us, we will stop taking risks to avoid those mistakes. But this behaviour is invisible most of the time. You cannot tell when someone is holding back. Unfortunately, an unwillingness to take risks can reduce the value of every undertaking a company can take on. "Low psychological safety, therefore, gets in the way of both team performance, innovation, learning, and personal success" (source). If we do not feel psychologically safe, we will not engage in meaningful conflict. This leads to a lack of commitment and eventually to a total inattention to results and is described well and much more deeply in Patrick Lencionis awesome book "The five dysfunctions of a team".
When feeling psychological safe we have the strong innate belief that the work environment is safe for interpersonal risk taking. We will speak up if we see problems arise. We will present our ideas, even if they sound crazy or unachievable at first. We feel free to criticize someone without fearing for a personal backlash and if we are criticized ourselves we can be sure that it is not done because someone else is longing for our job but because this persons also wants the best for the team. Our working environment becomes safe if everybody is sure that the feedback is never a personal attack, never about us but about the work that we delivered.
According to "The Fearless organization", the book by Amy Edmondson, the researcher who coined the term, psychological safety can be measured on four dimensions
The degree to which it is permissible to make mistakes.
The degree to which difficult and sensitive topics can be discussed openly.
The degree to which people are willing to help each other.
The degree to which you can be yourself and are welcomed for this.
An organization or team that has a high level of psychological safety on those four dimensions removed the need for excessive courage in the workplace. It allows feedback to be as fast and open as possible. It accepts that mistakes are inevitable and even embraces them as something that is the key enabler for new learnings and improvements. In such an environment we are not thinking an evening or a week about if we should address something but do it right away, we speak up, even if we are not sure about something, we speak up, even if we just have a feeling that something is not right, we speak up, when we have new ideas. And for those voices to be effective it requires a culture of listening. We want innovative ideas and insights to flourish and to create new knowledge throughout our team or organization as fast as possible. This is crucial for every knowledge work. This is crucial for learning.
When I talk to people about this topic, I often get the reaction that we do not want to treat people like snowflakes and being afraid of triggering them all the time. I even heard that this is just another angle that forces us to use political correctness everywhere. While I think the premise of this kind of thinking is misled (and should be discussed in a different article) this is not at all what psychological safety is all about. Psychological Safety is not about being nice. It is not about holding back to comfort your teammates. It is not a trade-off against holding people accountable or holding them against high standards. It is quite the opposite; it is about creating an atmosphere in which candor and openness is the default and not the exception. It is about being able to create such standards and allow new insights to bubble up to the surface as fast as possible. It is about not avoiding conflicts (and letting them grow) but solving them as soon as they appear.
Psychological Safety also is strongly related to but not a synonym for trust. According to Amy Edmondson Psychological Safety is experienced at a group level whereas trust exists between two parties. Citing the paper that introduces Psychological Safety: "Trust is the expectation that others' future actions will be favourable to one's interests; psychological safety refers to a climate in which people are comfortable being (and expressing) themselves."
This means Psychological Safety describes an immediate feeling and not long-term expectations about how specific people are going to behave in specific situations.
The question that is the most difficult to answer is how to achieve psychological safety. We need to understand that creating it is an ongoing process. We cannot declare our environment, our team, or our company a psychological safe space and expect everyone to act accordingly. Most of the time the need to mention that the current meeting or discussion is safe for every attendee is a good heuristic for realizing that in fact it is not. We cannot just tell two people to cooperate and be open. It is primarily the leadership that sets the tone. If we want to raise the degree to which it is permissible to make mistakes the first thing we need to accept is that we cannot assume that things are going well, things are much more likely to not go well. We need to frame failure as something achievable because learning can only occur when failure is not only allowed but encouraged. Every movie every song and every product suck in the beginning. It needs constant feedback to improve. We need all the "stupid" ideas, all the experiments. We need them early, and we need as many failures as possible to iterate and improve on them. If we want people to accept failures as something normal, we need to create an atmosphere where we could talk open about our errors. This makes us vulnerable, so it is only possible when we can create an atmosphere in which cooperation and not fighting against each other is the default mindset. Only then we are not afraid of speaking up and admitting our failures. This might sound a bit too "emotional" for some people but think of an atmosphere where none of this is given. How should people be honest, when they fear that they look dumb or that their very job is in danger for admitting a mistake. Just think about it for a second: when was the last time you have admitted a mistake?
We need to talk openly about our errors and especially as leaders we need to admit that we do not know all the answers. This does not make us weak, but it makes us wise. We need to ask the silly questions, we need to be genuinely interested in the other person's ideas and feedback, and we need to incorporate them into our future actions to show that people can really make a difference and that their voices are heard.
There are many ways in which we can improve the psychological safety of our team and there is no go-to answer. For some people talking about emotions helps tremendously. For some people this is their biggest horror and all this "fufu group hugging thing" makes them unsafe. Again, the key is a genuine interest in listening to what people have to say and an eye for what needs they really have. This is demanding work and something that is necessary for being a true leader.
If you are a leader in any kind of way, be it a team lead, be it in middle management or be it a company lead and you came to realize that psychological safety is not as high as it should be, do not blame the people for not speaking up. Do not tell them that "the door was always open". Instead, apologize for not creating a safe and therefore brave workspace. Think of actions or tools like KPIs that lead to people not speaking up. Think of ways to change these things, make suggestions, and genuinely ask questions about how people would change things if they could. But be aware that especially in the beginning you will not get all the answers from people because as I have already stated: You cannot declare a psychologically safe environment. You need to create and cultivate it to reap the benefits and you need to start being the person in the mirror.
A good way of reaching a high level of psychological safety is to create a common culture of feedback. Giving good blame-free feedback and receiving feedback in a non-defensive way is extremely hard, it needs to be trained like every other skill in our toolbelt. This is one reason you should never cancel retrospectives to get some "real" work done. When done correctly they will really make a difference. Regular blame-free post-mortems that analyse why certain things went wrong and how the team or the organization can learn from the mistakes that have been made can help to create a culture that really embraced and learns from mistakes.
Are people intimidated and blocked by pair programming? Try some team or mob programming sessions. Working together as a group can help tremendously with creating a real team. But don't forget to incorporate regular retrospectives to see what could be improved. You could even think of micro retrospectives every hour or even every thirty minutes. It is hard to build up frustration and uncertainty when you have regular chances to improve your teamwork.
If you are not a leader and experience a low level of psychological safety in your work environment, you are not powerless. You can create a psychological safe environment with your peers by using the same techniques mentioned above. You can ask genuine questions; you can admit mistakes and you can show people that you are not talking behind their backs. This alone will create a different atmosphere in your team and help to raise the level of psychological safety. Do not wait for your managers to start with this. Start with yourself.
You might ask yourself, where you can begin right now? You could go to one or two of your colleagues and ask them what kind of things you are doing that might intimate them or others. You could ask openly what you could do differently the next time (and you should not get angry when they give you answers that you did not expect). At the end of your next meeting you could ask for a small retrospective that checks if everyone felt heard. I know that in a psychologically unsafe environment this might be a bit daunting at first, but most people will react in a positive way when they feel that somebody cares about them genuinely. If you belong to a majority (white, male etc.) you should become aware of your own privileges and use them for the advantage of other marginalized groups of people, especially when your organization is not the most diverse place. Speak up for them, care for them and make it easier for them to get heard.
To reach full circle back to programming, I am going to wrap up with the following: When learning object orientation, you are taught "tell don't ask" (which is a great concept) but if you want to create a psychological safe workspace (i.e. you do not want object orientation but people orientation) it is all about (genuinely) "ask don't tell" (what to do). If you want to tell then make yourself vulnerable and tell about your inner state, your thoughts, your feelings and especially your needs.