Towards a psychologically safe environment
Feeling in a safe environment is a prerequisite for a happy and productive team. I’ll mention a software team as an example but it could be applied to other teams.
Maslow’s hierarchy of needs is a structured pyramid of human needs.
Notice that personal security lies within the safety needs, just above the physiological needs. If we don’t satisfy those lower-level needs, how can we unleash the ones above, where creativity and innovation can happen? If you’re struggling to survive, how can you think about politics or culture? Studies show that psychological safety allows for moderate risk-taking, speaking your mind, creativity, and sticking your neck out without fear of having it cut off.
Pathological organizations look for a “throat to choke”: Investigations aim to find the person or persons “responsible” for the problem, and then punish or blame them (…) If failure is punished, people won’t try new things. Treating failures as opportunities to learn and holding blameless postmortems to work out how to improve. Accelerate
According to Wikipedia, “psychological safety is being able to show and employ one’s self without fear of negative consequences of self-image, status or career”. If you’re living in fear, whether because you’re afraid of breaking a system or of being judged, you’ll refrain from challenging the status quo or even participating. You may resort to finding ways to hide those fears that are nocive to your productivity and well-being. For example, if you didn’t understand something but you don’t say it out of fear, how unproductive is that? Ideally, you want to work at a place where it’s fine to show your weaknesses. Saying “I don’t know” should be a normal thing.
Fear and anxiety are always bad. Don’t normalize them. Taking risks is a requirement to evolve and making errors along the way is natural. If errors are part of life and work, we better learn to embrace them.
We learn from failure, not from success. Bram Stocker
The team should be mature enough to see mistakes as part of the learning process. You should feel safe to make mistakes with no feeling of guilt, regardless of your seniority level. Accepting the error is mostly about culture. It boils down to the people who make up the company and the team. With that in place, there’s autonomy to implement some practices and ways of working.
Here, we include culture, practices, and methodology-related topics. There are too many to cover, so I’ll just highlight some that I find relevant and recommend that you investigate further:
- Proper welcome: you don’t need to throw a party when a new team member joins in, but make sure you prepare a few onboarding sessions. Be kind (remember when it was you). Pair programming can be a powerful welcome tool providing a sense of security and belonging. The typical alternative is to send lots of links and docs and say “tell me if there are questions”; of course, many people will refrain for fear of looking stupid.
- Focus: it’s proven that productivity is harmed by frequent switching; due to the stress involved, errors increase. Ideally, you should work on a single project/product at a time for a given period. Ideally, you should focus on a feature at a time and find ways to reduce interruptions.
- No finger-pointing and blaming: a team should be a cohesive group of people who help each other accomplish a common goal. Competition is the opposite of that. Shared ownership is a key strategy here — we’re all responsible for a product’s faults (and successes), and the focus is on understanding and avoiding repeating errors, not attributing blame.
- No gatekeeping: sentences that start with “a real programmer…” or “you don’t know that… ?” embody the adult version of bullying. Don’t make someone feel guilty for not knowing something, regardless of their experience. Use pair programming as a tool to foster learning and tackle know-how gaps.
- Don’t be a lone wolf. Resort to practices such as code reviews and pair programming to increase quality and know your colleagues. These practices reduce the fear of the unknown because we get the team’s feedback about us and our work. When onboarding someone, be open about your weaknesses from the start; mention your strengths later.
- Feedback culture: consider regular retrospectives, speedbacks, team health checks, and 1-on-1 feedback sessions (ad-hoc or scheduled) so that the team can increase trust in each other and continuously improve. Feedback is an immense topic that needs its articles so make sure you read about it before implementing it.
- Experimenting culture: one way to reduce resistance to change is to make small experiments inspired by the scientific method: based on a hypothesis, propose an experiment, analyze the results, and act on that. This applies to anything — from tweaking the technology to adapting the methodology. This reduces the fear of commitment because we can try (small) things before. It’s also a way to make big changes through small steps (always adapting in the process). It only works if the team embraces a learning and humble culture, in opposition to an “I’m sure” culture.
- Transparent culture: be honest with your peers and ask the management to act transparently. People fear what they don’t know.
- Get to know each other: in my experience, trust is the number one factor for a functional team. One shortcut for that is doing some get-together activities. Also, get to know yourself; ask for feedback, and make some introspection.
- Promote flat-hierarchies. Even if the company is not organized flatly, you can still act as if all have a saying on the product and the solution. Don’t be afraid to address the stakeholders and product owners — it’s in your best interests that you normally talk to each other.
- Lean approach: do the minimum needed to have something useful; get early and frequent users’ feedback. The MVP mindset doesn’t apply only to new products; in fact, it applies mostly to new features.
- Gradual approach: reduce risk by delivering small user-driven stories; do not create long-standing branches with big changes; make frequent (and green) commits; push often. With a proper CI/CI in place, you can easily pinpoint a problematic small commit and revert it.
- Assume positive intent: don’t assume the worst to reduce misunderstandings; until proof of the contrary, assume everyone wants the best for the product, communication, and company.
The key to working in small batches is to have work decomposed into features that allow for rapid development, instead of complex features developed on branches and released infrequently. This idea can be applied at both the feature and the product level. Accelerate
- Test-driven development: in my case, it provided lots of emotional safety because I knew it was hard to break things since everything had tests that were run very frequently (coupled with a CI/CD system). Also, I almost stopped using the debugger because the development was much more gradual with fewer surprises.
- Continuous delivery: Everybody has felt the release-driven anxiety. “What if I break the build?” Consider swapping from releases to continuous delivery for a constant value stream and to reduce the risks inherent to big bang (i.e. waterfall) releases.
Our research shows that Lean management, along with a set of other technical practices known collectively as continuous delivery, do in fact impact culture. (…) when teams practice CD, deployment to production is not an enormous, big-bang event — it’s something that can be done during normal business hours as a part of regular daily work. (…) Our research also found that developing off trunk/master rather than on long-lived feature branches was correlated with higher delivery performance. Accelerate
Unlike conventional approaches to software development, when we apply Continuous Delivery techniques, Release into Production is NOT a fraught, nervous event where leave is canceled, people are on-call and we feel certain that something will go wrong and we’ll spend long hours in the coming days and weeks fixing the problems. Continuous Delivery Pipelines
All of these initiatives should be embraced by the whole team — and of course, the company should promote them by trusting the people and sponsoring training if required. However, if you have the drive and the passion, you can be the agent of change. One behavior can generate a chain reaction of similar behaviors — a virtuous cycle. Go slowly and be positive or you’ll just be the one that complains and criticizes (which will be taken personally).
Bad environments were probably not always bad. If you see a colleague being judged, attacked, constantly interrupted, or afraid of asking things, maybe you should intervene. If everyone stays quiet about bad things, bad things can scale up.
The unknown is one the most common causes of fear — when you don’t know your colleagues, the codebase, the system status, or the future of the product. We saw some ways to deal with that but there will always be some uncertainty because companies exist in an uncertain world. Therefore, even in a very safe environment, it’s important to accept that. Change is the only constant so I just try to make the codebase — and myself — more open to change despite following a lean approach.
Don’t think you’re immune to mistreating someone. It can happen to all of us without us noticing. For example, we may overspeak someone causing distress due to some implicit bias. It happened to me before to get annoyed at someone when I saw behaviors that were mine (psychological bias). That said, take some time to retrospectively reflect on your daily attitudes.
Psychological projection is a defense mechanism in which the ego defends itself against unconscious impulses or qualities (both positive and negative) by denying their existence in themselves and attributing them to others. Psychological projection
I tend to recommend that the energy you spend complaining about the team or the company should be spent trying to fix the problems in the first place — unless the problem is too big. For example, if you work in a climate of fear, it’s unlikely you can change it in the short term; some people are too resistant to change and some companies are too slow to adapt, so maybe you should consider another challenge. Fortunately, if you work in software, there are too many opportunities out there to explore. If it’s a team issue, you can ask to rotate to another team.
Also, you can resort to technology in strategic ways (e.g. automation). I explore these topics further elsewhere:
Life is too short (and career-life even shorter) to live stressed — and you might be developing some mental issues in the background. Why do mental issues get so underrated when compared with physical harm? Don’t be ashamed if you need professional help. Take care of yourself.
Before implementing the technical practices and discipline of continuous delivery on the Bing team, engineers reported work/life balance satisfaction scores of just 38%. After implementing these technical practices, the scores jumped to 75%. (…) Our research shows that improving key technical capabilities reduces deployment pain: teams that implement comprehensive test and deployment automation; use continuous integration, including trunk-based development; shift left on security; effectively manage test data; use loosely coupled architectures; can work independently; and use version control of everything required to reproduce production environments decrease their deployment pain. Accelerate
