So-Called Advent Calendar Day 24 - Take a Break

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.

lighted christmas tree

I didn’t actually think I would make it to the last day of the advent. I hardly post once a month so trying to write a blog post every day of the advent seemed a little overambitious (though I guess I can’t really speak to the quality of these posts).

I’ll be taking the next few days off to get away from work and this holiday season I hope you get an opportunity to take a rest, too.

Merry Christmas and happy holidays, wherever you are.

So-Called Advent Calendar Day 23 - Incentivize a Safe Work Place

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.

crosswalk signal
When your team does not feel safe to proceed, it will not last long

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 four components of high performing teams | Lisa van Gelder

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.

So-Called Advent Calendar Day 22 - A Lesson In Hot Dogs

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.

sandwich alignment chart
In sandwich lore, the hot dog means unity

Are hot dogs sandwiches?

It’s a highly contested that brings up strong opinions. People site evidence from New York tax code and from an interview with Supreme Court Justice Ruth Bader Ginsburg, hoping to fortify their position. Yet despite this evidence, the debate is far from over.

But instead of taking another position, I wanted to take this opportunity to dive into the hot dog’s position on the sandwich alignment chart. It sits right in the middle, as a true neutral between ingredients and structure. And by sitting in this position, it is on the fringe of not only the sandwich definition, but also the wrap defintion, and the taco definition.

A common argument I often hear is “If someone said they are bringing out a plate of sandwiches and they came out with hot dogs, wouldn’t you be surprised?” Of course, but the same thing applies if you replaced “sandwich” with “wrap” or “taco”. Hot dogs are at the nexus of these handheld meals.

If you were eating hot dog and the bun split into two, does that suddenly make it a sandwich? Or if you have a really doughy bun and you squeezed your hot dog to close the bun loop, is it suddenly a wrap? What if you didn’t have a bun, but you had flour tortillas - does that make your hot dog a taco?

With just minor adjustments, the hot dog can jump between so many categories. Instead of focusing on the differences, the unification power of the hot dog forces to look at our similarities.

We love to take sides, but sometimes we let the sides divide us. Tabs vs. Spaces. Agile vs Waterfall. Star Wars vs. Star Trek. PC vs. Mac. Digimon vs. Pokemon. Batman vs. Superman (GREAT movie btw).

So during this holiday season, when you take a bite into that traditional Christmas morning hot dog, take a lesson from the hot dog and try to remember the bridges that joins us together, instead of the breads that try to keep us apart.