How to respect other people’s time with Slack

Slack can be great for improving workplace communication, but it can also be a collosal distraction for everyone. Tens or hundreds of channels and DMs, and an expectation of near immediate replies… 

With so much communication going on, how can anyone get any work done?

After giving this a lot of thought, one simple fact has occurred to me: every time I post anything to slack, I have chosen to take a little piece of someone’s time away. It might only take a few seconds to read a one-line message. An emoji or gif posted in reaction to another comment may only take a moment to glance at. But each one of those messages adds up, and together they create work and distraction for your colleagues.

Every message, even just an emoji, creates a notification on your colleague’s computer. A message posted in an open channel creates that notification for everyone who is in that channel. 

So each gif only takes a moment to glance at. But let’s do the math: let’s say there are 50 people in a channel – that’s 50 people who need to spend a little bit of mental energy clicking on the channel and consuming your gif. But remember it’s not just the time spent looking at the gif itself – it’s switching tabs to Slack, switching to that channel, looking at the gif, and then probably responding. So let’s round it up and say it takes 10 seconds. (This doesn’t account for the cost of task switching, which is a whole different topic).

10 seconds x 50 people: 500 seconds, or 8.3 minutes. And how many gifs are sent a day? 50? 100? The numbers quickly add up.

To that end, I came up with a few simple rules of engagement for Slack, to be considerate of everyone’s time and distraction:

  • Use public channels for communications that are relevant for everyone. Don’t waste people’s time and attention with messages that aren’t relevant for everyone in the channel. Use a DM instead.
  • Reply to messages only when a reply is really needed. If it’s important that the other person knows that you’ve read the message, use an emoji “response” instead, which does not create an unread notification on the channel.
  • If you want to reply to someone who posts in an open channel, but the reply is only relevant to that person, don’t reply in the main channel – start a thread instead. That way, the reply won’t create an unread notification for everyone in the channel. Bonus points: don’t reply to the person on the channel at all; use a DM instead.
  • Think twice before posting a gif to an open channel. Yes, they’re fun and all that – but they are also massive distractions.
  • If you are writing a longer response, don’t hit ‘ENTER’ until you’re finished. That way, the recipient will receive only one notification, and only when the message is finished. Otherwise, the recipient gets pulled in after the first line, and sits there waiting, staring at the “Will is typing…” message and wondering what is coming next… which is a huge waste of time.
  • Only reply to messages in open channels when you have something useful to say. The number of messages you post in open channels is not a measure of your productivity. (Rather, it tends to be the opposite). 

With every message you send on Slack, you have unilaterally decided to take a little piece of time and attention away from one or more people. Use this power over your colleagues wisely! 

Whose line is it anyway? (Don’t block your colleagues)

In improvisation theatre (yes, I was a theatre nerd in high school) there is a concept called blocking. Essentially, whenever you have an interaction with someone on the stage in improv, your interaction should allow the next person to pick up the thread and run with it to continue the scene. In other words, you need to provide a hook for the next person to continue the story.

If you don’t provide a thread for the next actor to continue the scene, it’s called ‘blocking’, as you’ve essentially blocked the scene from proceeding.

A quick example:

Actor A: “Do you want to go for a walk with me?”
Actor B: “No, I don’t feel well.”

B has blocked A’s offer to go for a walk, without providing an alternative option for the storyline, leaving A with the responsibility for creating a new storyline for the scene.

In development teams I see people blocking each other all the time.

Another example:

Developer A: “Can we add an extra parameter to this function?”
Developer B: “No, it doesn’t work like that.”

Developer B has blocked Developer A from solving the problem, without giving A another thread to follow. In other words, B has shunted the topic back to A, leaving A with the responsibility to try to find another way to attack the problem, but with no extra cues from B on what might work better next time.

Saying ‘no’ is not the problem here. But when you say ‘no’, you should always try to give a thread to allow the scene to continue.

Let’s try the example again:

Developer A: “Can we add an extra parameter to this function?”
Developer B: “No, it doesn’t work like that, but if you look at the sample requests you might get an idea of what’s working already.”

Now Developer A has a thread; she has an idea where to go to continue the search for the solution.

Not blocking someone can be as simple as giving a cue to let the scene continue. So when interacting with people in your team, or with other teams, remember: everybody wants the scene to continue, so avoid blocking.

The show must go on!

Rallying the “troops”: how things can be misunderstood

Soldiers at attention.

I was reminded today of a story about managing people. About 8 years ago I was in my first management job, managing a team of about 15 web software designers and engineers. I saw a key challenge in bringing the team together, inspiring one vision and building a sense of identity and unity within the team.

At the time, I was fresh out of the Army, and was still active as a part-time Army reservist. I took to calling the team my “troops”, and turned some of the key challenges we faced as a team into our “key battles”. I saw it as a term of endearment to the team. In my mind, I saw it bringing a sense of unity and a common, understandable vision to the team. I saw it flattening the hierarchy, putting us all at the same level to encourage shared responsibility and the willingness to speak out. I saw it helping to build individual relationships between each of the team members. (Looking back, I think subconsciously I also hoped it would help give me, as a very young manager of an experienced team, a sense of authority; but I wouldn’t have told you that at the time.)

All-in-all, I saw it as a positive, understandable and motivational message. Indeed, military expressions like “rallying the troops”, “strategic battles” and “war rooms” were common in business parlance then, as they are today.

In reality, though, the team themselves saw something quite different. In short, they hated it. They hated being referred to as “troops” or “soldiers”, which they found disrespectful. Where I saw it flattening the hierarchy within the team, they saw a new hierarchy emerging: one with officers who sit back and give orders and soldiers who follow them. Where I saw it encouraging initiative and shared responsibility, they saw themselves reduced to simple soldiers who just follow orders and are not expected to think for themselves. On top of that many found the frequent references to war and battles offensive and tiring. (This was just after the second invasion of Iraq, and soldiers were still dying every day in Iraq and Afghanistan.)

I learned two very valuable lessons from this in my young management career.

Firstly, be very careful with military references in the workplace. While it’s still common in business to hear talk of “battlefronts” and “attack plans” and so on, I’ve learned to be cautious with how often, and in which situations, I use these. I think in the context of a conversation between a few people it’s probably ok; but I wouldn’t frame the team objectives/targets for the year in terms of “battles” and “wars”.

Secondly, sometimes you just don’t know how people are responding to the messages you deliver and the things you say. As a manager, when setting a vision or delivering a message, you need to remember that your job isn’t done until you can confirm that the message was heard and understood by your team in the way you intended. For my example above, how could I have known that my efforts to bring the team together were not working out as I had intended? I think the answer is: ask. Ask for feedback from individuals, from the team. Just like in agile and scrum, constant feedback helps you constantly iterate and adjust, which applies as much to management and communication style as it does to code.

Communication in standups: watch the team, not the speaker

You can gain a lot of insights about people’s mood and reaction to news and disucssions just by watching them.

One habit I have picked up is during the daily standup, instead of watching the person speaking, I look around and watch the other members of the team. If I know the speaker is discussing a topic that’s particuarly relevant for someone, I’ll watch them to try to gauge their response to it.

You can get a sense of how effective the standup is overall simply by watching the faces and responses of the other people in the room. If the team seems bored or restless, then it might be a sign that the format of the standup or the way things are being discussed could be improved. If someone seems to respond negatively to a particular point or topic, you might take a note to catch up with them 1 on 1 after the standup to follow up.

Try it in your next standup; you will likely be surprised what little insights you get out of it.

Seek understanding – not insurance

When you communicate, you have two responsibilities:
1. communicate your message
2. ensure the message is understood

#1 is easy – but it is #2 that counts.

You can do #1 and forget or skip #2 – but you haven’t really communicated. Saying words out loud is not communication – it’s just making noise. Communication implies an understanding from both the initiator and receiver of the communication.

You can also do #1 in such a way to make sure that #2 doesn’t happen – that’s called covering your arse.

The danger of cc and reply-all

I got an email the other day, adressed to me with a mailing list of all the other Product Managers from our site in cc, that started with the words: “Actually, that’s completely wrong.” It was referring to my previous mail to a small group where I had made a comment about the readiness of a particular component to be integrated. It wasn’t just the arrogant, schadenfroh tone that irked me, but the sudden inclusion of the complete mailing list in cc. “Hey look, everyone, he was wrong!”

When you put people in cc on an email, you are making a statement. Always. The cc list can completely change the meaning and intent of an email… Who you include is often almost as important as what you say. So please be careful…

If you write to a colleague to give not-so positive or negative feedback, and you put their manager in cc, it is an escalation. If you don’t put their manager in cc, it is colleague-to-colleague feedback which has a much lower chance of provoking a defensive reaction.

If you write to a colleague to give positive feedback and you put their manager in cc, it can often increase the weight or worth of the feedback significantly.

When you answer an email with a reply all, especialy when you want to critisise or disagree with a point of view, etc, including everyone is a a statement that you want everyone to know that you disagree. This can sometimes be constructive, but if you intend to attack an idea or point out how someone was wrong, it can quickly look immature and cheap. 

Replying all to point out someone’s failure or weakness is like when you used to run to mum and dad as a child to tell on your sister whe she did something she wasn’t supposed to. It might feel satisfying for a minute, but at the end of the day you will end up looking like a child.