Psychological safety is defined by Amy Edmondson of Harvard University as “a shared belief held by members of a team that the team is safe for interpersonal risk-taking.”
In other words, psychological safety is knowing that you can make your opinions, ideas, and questions heard without being shamed for it. It doesn’t mean that everyone will agree with or accept your ideas, but it does mean that you won’t be shot down for sharing them.
As you can imagine, this can help a team in a variety of ways (it’s very useful when brainstorming, for example).
In my role as a Junior Developer, I’ve been able to draw connections between psychological safety and the impact it has on our day-to-day here at Frogslayer.
In this blog, I’m going to share 5 ways that psychological safety (and in particular, the confidence to ask seemingly “dumb” questions) can help a software team work more efficiently.
1. Onboard to a Project Faster
In the field of software engineering, it can sometimes be difficult to convey one’s ideas to another person. Oftentimes, we forget that while we have spent the last few days looking at the same section of code, our colleagues have been doing their own work.
When the time comes to explain our code or to start writing documentation, it can be hard to detach and see things from the perspective of someone new to the system. Even in cases where the documentation is thorough, there can still be a pretty steep learning curve when jumping into a new project.
This is where being able to freely ask questions is a huge advantage.
While yes, part of onboarding into a project will necessarily involve spending some time poking around the codebase by yourself, you can save yourself a lot of time by asking people more familiar with the system about specific components/design decisions.
For example, you might be wondering why a particular convention was adopted when dealing with certain types of data – it might have been the arbitrary choice of a programmer, or it may be very intentional. Either way, it may be difficult to figure that out without someone more veteran on the project.
2. Clarify Expectations Sooner
Software teams manage expectations all the time – clients have expectations for the team, the project manager has expectations for the developers, and the developers have expectations for each other.
Sometimes there can be dissonance between what is expected and what is communicated verbally or in writing. This can lead to one of two outcomes:
- If someone assumes what is expected and acts on that assumption, they might end up wasting time (and therefore money) doing something that wasn’t what others actually wanted.
- If that person instead asks a few simple questions to clarify expectations, they can get much better direction about what is expected and achieve that more quickly.
The second option is preferable to the first. However, it can only work on teams where there is enough psychological safety to ask small or “dumb” questions about what is expected of them.
3. Identify Gaps Earlier
At Frogslayer, we have regular “Architecture Meetings” where we developers get together to discuss either (1) design decisions we have made or are making or (2) how we would hypothetically architect something (Ex. – Recently, we’ve been discussing a Google Drive-like file storage architecture).
One thing that I find really valuable about these meetings is oftentimes, by asking questions informed by past experiences, gaps or pitfalls in a design are identified earlier, allowing us to discuss how we might mitigate them.
Obviously, it is much faster to figure out these problems during the design phase rather than weeks or months later once the system is being implemented.
As a junior developer, it can sometimes be intimidating to ask questions about potential problems in a design when you’re in a room full of associate or senior developers.
However, I’ve found that even if my concern ends up being a non-issue, it is still valuable to hear why that is the case (more on that in #5).
4. Remove Blockers Quickly
As a kid, was there ever a time when you could tell your parents were frustrated and that you shouldn’t ask them for anything?
Unfortunately, that same feeling can occasionally be experienced in the workplace.
While thankfully, I have not had this experience during my time at Frogslayer; I can recall an experience from when I was working at a different company.
I reached a point where I was running out of things that I could work on without getting guidance from a more senior developer who did not seem too jazzed to receive more questions from me.
This led to a slowdown in my work because I spent a long time trying to figure out a solution to a question that could have been answered in a few seconds.
Had I felt comfortable approaching with my question regardless of the situation, this speed bump could’ve been avoided completely.
5. Level Up Developers
All the points listed thus far explain how psychological safety can help a team complete a project more efficiently.
However, in the process of asking these questions, knowledge is being disseminated from developer to developer on the team.
This raises the overall skill level of the team, and it goes in all directions. Every developer, regardless of experience level, has something to learn from their colleagues.
An environment in which every developer feels comfortable asking other developers questions is an environment in which your juniors will level up faster, and your seniors will stay sharp.
Final Thoughts
It takes time and effort to build a culture of psychological safety on a team, and it requires participation by everyone.
The whole team (especially the more seasoned members) should be open to receiving and answering all questions, big and small. It falls on the less confident or more reserved members of the team to learn to voice their thoughts and not be afraid to speak out.
During my time at Frogslayer, I’ve been able to experience firsthand the benefits that come from having a culture of openly asking and answering questions. This environment hasn’t just positively impacted the teams I’ve been a part of; it’s also been invaluable for my own personal growth and skill development.
-
Carlos Vazquez-Chapa
