Two Tips For Psychological Safety On A Software Engineering Team
Psychological safety is integral for effective teamwork on a software engineering team. This is something I think a lot about on the day to day in my role. I want people to trust that they can critique my work and know that I will not take that as a critique of my character. This is obviously easier said than done. Here are a few specific things I try to make sure I do in order to help build psychological safety.
First, I try to know my crap
This one is obvious, but it’s really important to be someone that knows what they are talking about to build trust with other engineers. This is important for both computer science concepts as well as domain knowledge of the systems a software team owns. Because of this, I try to maintain the “lifelong learner” mindset. Whether it is pairing with another engineer on a story or working with a product owner on testing functionality to make sure it meets the product requirements, I think there is always something to be learned. These situations are also great opportunities to ask questions that show you are here to learn, grow, and put in the work help elevate the team.
Second, I think about how I want to convey ideas
While knowing your stuff is important, the way in which ideas and knowledge are conveyed may be more important. Nobody wants to work with a know-it-all. Because of this, I try to remember the importance of making a suggestion to another engineer regarding how something should be improved.
For example, let’s say that I am reviewing someone’s code and their solution, for one reason or another, seems “hacky” to me. The first thing I will try to do is figure out why the solution seems clunky and try come up with an alternative solution. If I can come up with an alternative, I will always try to offer the solution to the engineer as another option that hasn’t fully been thought through instead of the correct answer. No matter how confident I am in my alternative, there can always be some edge case that I didn’t consider that my edge case doesn’t consider. Because of that, I will say something like “I know you are much closer to the problem here, so there very likely could be something I didn’t consider” to really prove that point to my team member.
In the event that I can’t come up with an alternative to a clunky solution, I try to find time for my team member to talk through the solution to me. This gives the other person time to talk through things they may have tried that didn’t work and help me understand how they settled on the solution they did.
I really appreciate you taking the time to read my thoughts! I hope they were helpful to you in some way!
