Psychological safety in your scaleup team – why it matters?

Firstly, let’s set the scene.

We build custom software which is often business critical and far reaching – it will interact with not only our clients but their customer/suppliers too. Naturally, bugs are also reported by these stakeholders.

Bugs in software are a fact of life, bug free software does not exist. That’s not an excuse to write bad software – “Ah well, why bother then?”, that would be the wrong way to look at it.

On the contrary, it’s understanding that strong process to make good software is more important – strong requirements, code reviews, quality assurance, automated testing, security testing, deploying quickly, error logging + more – they are paramount to being reactive and proactive, to reduce the number of hidden issues in software.

To make it more complicated, most software is built on the shoulders of giants – there are complex dependency chains, with any given piece of software sitting on layers and layers of other software. At any moment, a critical (all hands on deck) vulnerability could be disclosed for a bit of software deep in the dependency chain – and this happens probably once a year on a global scale in our tech stack.

It comes with the territory - but innovation creates results, so it's worth it for us and our clients.

What is Psychological Safety and why does it matter?

Psychological safety is the belief that you won't be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes

Whilst I believe this is important everywhere, I’ll focus on tech and my own experience.

We work hard to empower psychological safety - it’s important that people are able to pipe up and say ‘listen, I think I messed up’, or ‘there is an issue here, and we need to tell the client’. Doing so in a no blame way, looking at the facts and the timeline, creates mature and productive resolutions. 

Whilst this doesn’t need to happen often, I know that I would be able to approach any client we have right now, and open a productive dialogue in the same way – partnership and collaboration are key to success.

We’ve had clients where this is not the case – when an issue is disclosed, threats & shouting probably follow, instilled sometimes by a culture of fear in the client’s business, it spills over. Whilst we’d still be transparent, it’s obvious how that culture would foster an attitude of blame, hidden issues and stress.

People end up being punished for the inevitable, or for things they didn’t even cause.

If people are punished for mistakes/failure, and mistakes/failure are an inevitable side effect of innovation, why would the people in a business be motivated to innovate for a scaling business?

Innovation in that scenario has a high chance of punishment.

Being the wolf of wall street only works if you have a ludicrous amount of money to pay people to be motivated in that environment.

So how does this apply to tech/scaling?

We only need to look as far as the post office scandal to see the extreme. Over 700 post office workers were convicted of theft and jailed, many believed to be falsely accused.

In the background, the tech team for the Post office’s Horizon IT system seemed to be ignored or brow beaten when they voiced concern or wanted to investigate the issue.

The technical team were manually changing production data without telling post masters, the legal team making it clear to technical expert witnesses during trials that the software must not been seen as fallible, and it seemed common knowledge that the platform was terribly written and not fit for production – key technical stakeholders wanted to rewrite the software. At the same time, the leadership team promoted the platform as proved to be faultless, and in the words of the Daily Mail ‘Internally, it fostered a cultural belief among its staff that Horizon was not capable of being the source of an accounting error.’

Postmasters would use their own money to cover losses until they couldn’t, as their options were that or prosecution – there was no mechanism to step back and say ‘ok – how did this happen?’ in a way which includes all stakeholders and without pointing fingers. Instead, postmasters had a knock on the door from the Post Office’s private prosecutors, and were left with ‘if you plead guilty you probably won’t see time’ – many went on to spent time in prison anyway.

Now, there was probably more going on here than a culture of fear and silence – but it’s clear how lack of psychological safety contributed.

So what does an excellent, psychological safe response look like from the outside?

In 2017, an engineer for a company called Gitlab (now a $1b company) was performing maintenance to make the platform faster, and thought they were working in a test environment – they were not working in the test environment and ended up deleting the entire production database, all their client's data deleted in an instant. To make things worse, the backup process was toast so there were no readily available backups, and it was clear that a platform which is a critical component for many other businesses has suffered data loss and will suffer several days downtime.

The engineer made a mistake deleting the database, but it was the business process and lack of recovery which created the situation - probably a casualty of scaling quickly.

If you were a tech business using Gitlab at the time, you might as well have had the week off.

Gitlab went on to respond in a way which only strengthened their customer’s respect, resolve and commitment to the company. Gitlab provided a transparent and in depth analysis of what happened, and frequent updates on resolution – they owned up immediately and controlled the situation – it was a brave and rare approach. The engineer went on to work for Gitlab until 2021.

Without a doubt it I assume it would have been a terrible and stressful time to be a Gitlab employee, but the calm, factual and resolution focused approach, with clear empathy for the customers, won out.

I genuinely believe that the psychological safety and approach not only saved Gitlab from existential threat, but actually built trust and empathy with their customers. The situation caused significant pain for their customers, but their customers empathised with their situation and supported them through it.

Since 2017, Gitlab saw huge growth, from 100 employees to over 1400 today.

A culture without blame, focuses on facts and transparency, and with empathy, I believe creates a more valuable and productive business.