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.
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 policies towards open source became much more complex. Instead of the developers getting a training and signing a waiver, tools had to be executed. Since the development landscape had become much more complex, integrating the OSS tooling was a cumbersome tasks. Some teams even decided to outsource the OSS scanning to teams in India, that would download the code periodically and run the OSS tools. Due to the corporate structure, there were teams with competing offers to solve the OSS woes. All of that was an insurance, to be able to shift blame.
- There were more and more policies that had to be followed. Nobody really understood them, and there was no guidance on how to implement them, or whether they were applicable at all for what you were doing. They became line items in the quality plans that each project had to fill out. With each project manager figuring out if it was relevant for them. And, when in doubt, rather create too many documents than too few. All of those documents of course had to be updated and maintained.
- Since the company was a hardware manufacturer there were of course many processes and policies, that were focusing on limiting the risk of a recall. A recall is something you definitely don’t want to have in a hardware product. But the story is different in software. Still those processes had to be followed.
- Quality gates were introduced. The project management processes were inflated. Quality engineers became part of the organization in order to have somebody working on the quality gate checks. Of course they were also there, to be able to assert blame. Doing CI/CD was prohibited. Deploying without doing a quality gate first was not allowed anymore (this changed at a later point in time, see below *).
- Random managers from other teams/divisions/subsidiary escalating internally with “You can’t do that, since we are doing this”. This perceived feeling that your project, which you might have been hired by a customer to do, transgresses into their territory. Ultimately limiting collaboration and reducing organizational transparency.
- EU-GDPR happened, with the looming threat of a 4% revenue or 20 Million Euro fines. There was of course a central project that managed the rollout of EU-GDPR corporate wide. But the support for enabling teams was very low. Once again you could hire competing teams, to get your “EU-GDPR insurance”.
- The looming threat that “the NSA is going to hack us and steal all our data”.
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.
