Psychological safety is a treasure you need to foster

In 2012 I joined a small company. Back then the company was “just” acquired by a big multinational corporation (MNC), but retained a lot of its independence. The developers were ruled by a few simple policies. There were a few central systems, a SVN server, a Maven Repo, Jira, Confluence, a self-developed time keeping system, a simple intranet CMS and an Exchange server. The company was mainly consuming open-source software, so there was no need to release things to the open-source ecosystem. There was a simple HTTP proxy to the internet. Admin access on the developer machines was normal. A great place to work.

But overtime the company got “assimilated” more and more into the corporate structure. Corporate IT took over hosting of some of the tools, while others were replaced with corporate tools and others were simply shutdown. Instead of being able to walk to our IT guys, we had to file tickets via e-mails which were then manually entered into a ticket system by some poor souls (you could accelerate this process by calling a help desk line). It became more and more important to follow corporate policies, which were rooted in automotive business. And we got new managers who were more rooted in the MNC, thus more focused on following those policies. The HTTP Proxy was doing TLS termination to prevent malware downloads, so most tools broke because of untrusted TLS certification chains. Admin access on the developer machines had to be requested on a per case basis. Developers felt that the organization had lost trust in their abilities. Sounds familiar to you?

At the end of my tenure there, one of my colleagues asked me: “In the past we were able to execute projects much smoother, and with more success. Why can’t we do this anymore?” And at the time, I didn’t have a good answer. Sure, laptops were a little slower and not as nice, the infrastructure was much more complex, and getting a VM took a few days instead of a few hours. But none of those things really seemed to be at the core of the problem. But I understood what my colleague meant, we seemed to be much less effective and efficient in what we were doing.

Now, with a fresh perspective from the outside, I think I found an answer to what had happened, and want to share that: We gradually over time lost psychological safety.

A visualization of the lack of psychological safety by the amazing Steffen Reimann

Psychological safety is a shared belief held by members of a team that the team is safe for interpersonal risk-taking. A lack of psychological safety, leads to an environment in which people are afraid to take risks or make mistakes in front of others because they fear being punished for it. This often manifests as a culture of fear or a tendency to avoid transparency. (From Software Engineering at Google by Titus Winters, Tom Manshreck, Hyrum Wright). Let me give you a list of things that I think contributed to this loss:

The people didn’t feel safe anymore. They had to assume that they were doing something wrong, every step of the way. There is a “piece of wisdom” that you can hear in many German workplaces: "Wer nichts macht, macht nichts falsch" which roughly translates to "if you don't do anything, you do nothing wrong". My assumption is, that you could build a metric out of the times you hear this sentence, and this metric could be a good indicator towards how messed up your organization is. Often enough, if you digged into the topics enough, you figured out how to do the things you would have wanted to do. But it was easier to perceive it as impossible.

It led to a climate, where developers where deploying as little as possible. Not only that the release processes had a highly manual component due to things necessary for the quality gates, but also “the risk” People were doing more and more “cover your a**” emails. Escalations became more and more common. The volume of jour fix meetings increased. The volume of new features/bugfixes decreased. Developers were talking more and more about technical debt, to get time to work on those perceived risks.

Many practices in agile software development can help building this safety. Mob or pair programming can reinsure confidence in your abilities as a developer, and create trust within the team. Fast feedback loops with continuous integration, allow you to feel at ease with your changes. Test driven development gives you assurance that your code is fulfilling the interface contract. Periodic retrospectives allow you to mend problems.

But there is only so much a development team can do by themselves. Ultimately it’s the job of the leadership to create an environment where people fell safe, are ready to take risks and grow. If you need a place where you can start, take a look at how much process work is needed for a feature request to get into production. You can transform teams that are creating policies, to teams that are providing automated tools for checking/fulfilling those policies. And review your processes and policies: Are they for blame management or do they map a market need? Could there be more automation? Who is enabling the teams to follow the process/policies?

Embracing digital transformation is a daunting task. In order to be successful, you will need to dare, you will need to iterate and pivot. Cosmetic changes are not enough, you need to be willing to challenge your existing systems. Otherwise it can’t be transformative, there will be catharsis on the way, but the promise of a digital transformation should be well worth it.

On a side note:
*In the later years a colleague from quality management did a great job, to re-enable continuous delivery. By having an inspired understanding of the corporate processes he created a software development process maturity model. The sad part is that many developers didn’t really understand it, and for them it was just another line item on the Quality Gate checklist. One of my last activities was leading an effort in creating a standardised development process for our professional services teams.



I’m a technology enthusiast and focusing on Digital Transformation, Internet of Things and Cloud.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Christoph Grotz

I’m a technology enthusiast and focusing on Digital Transformation, Internet of Things and Cloud.