In the spirit of the holiday season, this is a series of short blog posts covering random things I have learned while doing Salesforce development, one for each day of Advent.

A few days ago I watched a video a colleague shared with our team called “The four components of high performing teams.” The speaker presents the four components along with some stories from her professional experiences to add some context. Here is the description of the the four components from the video:

• Mastery - The skills & knowledge needed to do a great job, and a clear path to get to the next level.
• Autonomy - The space to figure out their own solution to a problem & how they want to work
• Purpose - A clear sense of direction, and the knowledge of how what they’re working on fits into the big picture & helps their team succeed.
• Safety - A team that is afraid won’t take risks or experiment, a team that is afraid of finger-pointing won’t learn from mistakes.

Below is a link to the video. It is about 30 minutes long, but I think it is worth the watch, especially if you are building a new team:

The component the spoke to me the most was the concept of safety. I never really considered software development to be unsafe other than the risk of not getting enough sun and exercise. But even though I have been pretty much always physically safe in a job, I can’t say the same for my psychological safety.

I have had moments where I have broken down and cried in a stairwell. I have had days where I stopped in front of the entrance and stared at the building for 10 minutes, trying convince myself to walk in. I still recoil when I see a Slack notification on my phone - I don’t even use Slack at work anymore, but I just have this negative Pavlovian response to those notifications now.

These are feelings that I should never have about work, especially in the truly low stakes environments that I have worked in. No one is going to die if I deploy next week instead of today. It will be ok if the website is down for an hour. What’s the worst that will happen if a lead can’t convert on a Saturday?

But I have felt that overwhelming pressure before, that looming cloud that sets you into a panic to just do something to get it over with. Maybe these are a little extreme, and to be fair I recognize that these reactions are also things I need to work on personally. But I guarantee you have felt unsafe before too.

Have you ever blown out an estimate before, like doubling your estimated scope just to give you some padding? Have you ever delayed responding to a message or an email even if you have the time to answer just because “If I answer too quickly, I’ll set the precedent that I am always immediately available?” How about creating fake meetings on your calendar because you can’t trust that the time won’t be taken away from you at the last minute? Or maybe you answered emails and messages during your days off because something might happen if don’t?

All of these are signals of an unsafe environment. You may not be in an overtly toxic workplace, but that feeling of unease can really poison things. When you expect punishment for missing a deadline or for being incorrect on something, you will start to change your behavior to keep it from happening again.

The whole idea of “under promising, over delivering” is based on this premise of withholding information in order to protect yourself. For example, I could be 80% certain I could deliver something in a month, but the last time I gave that estimate, it was sold as it will 100% be delivered in a month, regardless of an unforeseen consequences. So instead of rushing to deliver at the last minute, maybe this time I double my estimate just to be safe.

To me, that sounds like an antagonistic relationship instead of a collaborative one. An environment that promotes safety, however, would allow for this dialog to happen. As a team, we should decide together to add some padding to the scope in order to account for uncertainty. We should be able to discuss and reflect not only on our victories, but also our mistakes and incorrect assumptions, so that we can be estimate more accurately in the future.

Most importantly, this has to come from the top, from a leadership level. So if there is anyone in management or executive leadership reading this, I encourage you to incentivize safety above all. Your reports should be comfortable to tell you that something went wrong, that something will take a longer than you hoped, so that you can make more tactical decisions base on all the information available. Because when you disregard that and insist that it needs to be done anyway, you disregard reality and end up delivering a solution that no one is happy about. And the longer that lasts, the more likely your team will decide they are better being somewhere else.