Blog

Thanks to my workplace, this year I went to my first conference. In May, I attended Agile Manchester 2024.

In total, I spent three days in Manchester, witnessed 15 sessions, drank a few ciders and ate more sandwiches than I really should have. But in amongst all the food and mingling, one of the sessions really hit home, and it's been living in my head rent-free since, to the point where I've realised writing about it might help coalesce the ideas somewhat.

That session was titled "Psychological safety: The link between speaking up, complexity and high-performing teams" and it was wonderfully delivered by Jitesh Gosai.

Considering it opened with discussion of an air disaster, at the beginning I wondered what exactly was coming. By the end, Jitesh had completely won me over with his excellent delivery and engaging presentation. I'd never heard the term "psychological safety" before, but I became aware that I was living it without realising.

I've often encouraged colleagues to feel confident enough to speak up, that I'd rather that they say something than suffer in silence. That I don't judge, and that their well-being is important. And that I expect similar; the reality is that everyone has something from time to time - worries about home, or work, or education, or whatever. It doesn't matter, they exist and we're all juggling our own lives whilst we come together to get things done at work.

Sometimes someone might need to disappear to resolve something. That's OK. Sometimes a child gets in the way, or needs an appointment somewhere. A girlfriend needs collecting from a station. A boyfriend needs something forgotten bringing to him. Unfortunately, there's a funeral. A school play... the list continues and all of these examples are life, we haven't even arrived in the workplace. But if people are worrying about things happening in life, how can you expect them to be conscientious in work?

More, if they feel that life is pressing on them, are they going to be able to comfortably say to colleagues that they need help?

If they don't feel safe, how can you expect them to take a risk with something new in the workplace? How can they grow in experience, role and stature, if they are under a cloud? What happens if they make a mistake and don't feel safe enough to say so, and hide that error, causing even bigger issues further down the line?

The first point is all about feedback, and getting everyone into the same position with it. I have always tried to make sure that the people I work with feel safe to speak up about anything, so that there is a quick feedback loop between me and my colleagues. I make an effort to tell people I might have not worked with before that I value rapid feedback: that an upfront message is valuable to me, and that talking about me but not to me doesn't allow me to improve. And this is absolutely true, but it isn't strictly for me: reassuring people that it's ok to offer that feedback upfront if they want to is the first step towards ensuring that everyone feels safe in sharing.

I'd argue that the second point would be demonstrating how mistakes are handled. Mistakes happen. Workplaces where people fear making them are poisonous, and you don't see the best of the people in them. Giving people the sense of safety that they are empowered to try something that could go wrong is something to strive for within all teams.

Once everyone reaches that point of feeling safe in their group - of family, of friends, of colleagues - then the good times can begin. In the workplace, particularly in my industry, people can start thinking of better solutions to complicated problems, safe in the knowledge that they aren't going to get shouted down or ridiculed, and comfortable enough that they can make a mistake along the way - and that leads me to the third point: fear, or rather an avoidance of it. People who are fearful of something - an event, a process, a colleague, whatever - are not going to perform at their best. This extends out across the organisation: I'm particularly keen of trying to talk to people in their language to dispel any fear or misunderstanding that might occur. It's OK to talk code with fellow developers, but a non-technical colleague may want concepts explained in a very different manner, and without doing so they may fear (or at the very least, not fully understand) processes.

I'm doing Jitesh's talk a disservice here, but I didn't want to simply regurgitate it, rather to get my own similar thoughts down.

I'd probably sum it up as follows:

1. Psychological safety needs everyone on the same page
2. Fast feedback enables people to get there
3. Mistakes are not something to be feared

If you can get your teams started towards that path, I think everyone will be happier, more responsible, more confident and more productive.