Creating a Slack Writing Etiquette Guide for Your Workplace(slab.com)
slab.com
Creating a Slack Writing Etiquette Guide for Your Workplace
https://slab.com/blog/slack-etiquette-guide/
12 comments
My Slack pet peeve: "Hi" and then a further 2 minutes of "John Doe is writing a message...".
Gather your thoughts, then write everything - the context, what you need from me, everything - in a single message.
Gather your thoughts, then write everything - the context, what you need from me, everything - in a single message.
This! Also:
>hi!
>Can I ask a question?
Just speak your mind or even better: just send an email.
IM is really great for sexting but it’s not great for anything professional IMO. Transcripts aren’t always saved and you can’t trust the transcript from a lot of clients (I had one person who would often edit messages to completely change their meaning after sending them, I had to make a habit of screenshooting IM conversations.) If you really need to have a conversation and can’t talk to me in person you can probably get my phone number.
>hi!
>Can I ask a question?
Just speak your mind or even better: just send an email.
IM is really great for sexting but it’s not great for anything professional IMO. Transcripts aren’t always saved and you can’t trust the transcript from a lot of clients (I had one person who would often edit messages to completely change their meaning after sending them, I had to make a habit of screenshooting IM conversations.) If you really need to have a conversation and can’t talk to me in person you can probably get my phone number.
I use this to my advantage. Often when somebody writes “hi” I don’t respond and they go away.
YES! Amen to that.
The people who do the "Hi" thing are savages and need handled appropriately.
Options:
1. Ignore their message until they've fully communicated their initial ask. it is not your responsibility to engage to "Hi".
2. Sporadically type something in to the chat box but never actually send the message. This gives the other person the "bubbles" but they have to keep waiting for a message that will never otherwise appear ; )
The people who do the "Hi" thing are savages and need handled appropriately.
Options:
1. Ignore their message until they've fully communicated their initial ask. it is not your responsibility to engage to "Hi".
2. Sporadically type something in to the chat box but never actually send the message. This gives the other person the "bubbles" but they have to keep waiting for a message that will never otherwise appear ; )
Option 1 works well for me.
I'm sounding like a zealot here, but this is why I like Zulip. It has multi-line compose by default and it encourages you to write messages like you write emails, ie long-form.
Is slack etiquette different from that of Skype?
I prefer to greet and then send in my message(in one or many chunks depending on complexity/feedback) after that.
Sharing my perspective here.
The greeting is irrelevant because truly neither party of the message cares. That's okay too. You have a question, I probably have an answer so just ask your question.
The absolute most respectful thing you can do to the person you are messaging is to send as much info as possible in the original message and then let them respond. If you do need to engage first with something like "do you have a moment for a question?" then still write your question first so you can copy/paste it immediately.
The greeting is irrelevant because truly neither party of the message cares. That's okay too. You have a question, I probably have an answer so just ask your question.
The absolute most respectful thing you can do to the person you are messaging is to send as much info as possible in the original message and then let them respond. If you do need to engage first with something like "do you have a moment for a question?" then still write your question first so you can copy/paste it immediately.
It's not different, and you shouldn't do this in any text-based communication platform.
In my experience this is usually done by someone making a request outside the normal chain of command and therefore trying to signal politeness. And it backfires.
There's a site for this http://www.nohello.com/
The example on using emojis is very strange:
> It'd be nice to get that report by this afternoon.
This phrasing is inherently passive aggressive since it's not a direct ask, regardless of how many emojis are included.
Why not:
> Hi <name>, will you be able to have the report on X ready by <time>?
> It'd be nice to get that report by this afternoon.
This phrasing is inherently passive aggressive since it's not a direct ask, regardless of how many emojis are included.
Why not:
> Hi <name>, will you be able to have the report on X ready by <time>?
I notice this pattern all the time in guides to "polite" workplace communication. Their examples are hypothetical, so they look at how positive something sounds without considering the underlying content, or go even further and change content to improve tone. The advice looks good on paper, but using it when there's an actual task at hand might just sound sarcastic or disingenuous. The worst example I've ever seen was something like:
> Instead of "I need that report by the end of the day", try saying "I really appreciate you working to get that report out soon, it's a big priority right now!"
That's absolutely insane, because those are two completely different statements. The second one sounds less demanding because it's not the same request. So the tip isn't positive communication advice, it's either a schedule rework or failing to convey a deadline.
As for this specific example:
> By adding an emoji below, it's clear that the sender is embarrassed to make this last-second request, and isn't trying to come across as sarcastic, rude, or overbearing
That wasn't clear to me at all. If you type in "embarrassed", Slack will only suggest :flushed:, although I'd also have understood :sweat_smile:. I guess the monkey was meant as "I'm hiding my face with shame", but Slack calls that emoji ":see_no_evil:", and at first glance it seemed like "I'm trying to not to look over your shoulder, but is this done yet?". If the problem is "making a last second request", there's no particular reason that emoji are the best way to address it - one example simply has more content than the other. So I like your direct phrasing, and I might add:
> Hi <name>, will you be able to have the report on X ready by <time>? I'm sorry it's such short notice, thank you!
> Instead of "I need that report by the end of the day", try saying "I really appreciate you working to get that report out soon, it's a big priority right now!"
That's absolutely insane, because those are two completely different statements. The second one sounds less demanding because it's not the same request. So the tip isn't positive communication advice, it's either a schedule rework or failing to convey a deadline.
As for this specific example:
> By adding an emoji below, it's clear that the sender is embarrassed to make this last-second request, and isn't trying to come across as sarcastic, rude, or overbearing
That wasn't clear to me at all. If you type in "embarrassed", Slack will only suggest :flushed:, although I'd also have understood :sweat_smile:. I guess the monkey was meant as "I'm hiding my face with shame", but Slack calls that emoji ":see_no_evil:", and at first glance it seemed like "I'm trying to not to look over your shoulder, but is this done yet?". If the problem is "making a last second request", there's no particular reason that emoji are the best way to address it - one example simply has more content than the other. So I like your direct phrasing, and I might add:
> Hi <name>, will you be able to have the report on X ready by <time>? I'm sorry it's such short notice, thank you!
I'd really just prefer to keep emojis out of any professional requests. If after work you want to go out for :beers: :D then sure, but if you're asking me to work late on a project, no amount of emojis will improve my mood.
I'm with you there, and it gets even worse when a company has their own emojis with a completely obscure meaning that is somehow expected to be understood. Like for some reason people in my company reply to messages sent out of the context of the channel with an emoji of the pokemon Charmander breathing fire (:charangry:). My own subtle form of protest is to use random emojis that really don't have any meaning. A personal favorite is :shallow_pan_of_food:.
imo, this is part of a more general problem with emojis. the "name" of the emoji does not always correspond to the image very well, so you have to confirm that the image actually conveys the tone you are going for. then as the recipient, you might sometimes wonder whether the image or the name of the image carries the intended meaning.
[deleted]
> Use Slack for ephemeral communications only
> Ask yourself, does this conversation need to be preserved for future reflection or action? If not, continue using Slack. If so, transfer the important elements into Slab.
This whole article seems to boil down to, "rely less on Slack, and more on our product."
I strongly disagree with things getting lost in Slack, and it being made for ephemeral things. Slack is one of the places I typically go to search for problems and past data - their search is quite good, _much_ better than (e.g.) Atlassian's, and no worse than StackOverflow's. If I have a technical issue that I'm sure someone will run into again, I'll almost always toss it into Slack so I can ctrl-f for it later.
(This is different for their free offering; there, yes, things vanish into the void. But this isn't aimed at pals chatting away in the evening.)
> Ask yourself, does this conversation need to be preserved for future reflection or action? If not, continue using Slack. If so, transfer the important elements into Slab.
This whole article seems to boil down to, "rely less on Slack, and more on our product."
I strongly disagree with things getting lost in Slack, and it being made for ephemeral things. Slack is one of the places I typically go to search for problems and past data - their search is quite good, _much_ better than (e.g.) Atlassian's, and no worse than StackOverflow's. If I have a technical issue that I'm sure someone will run into again, I'll almost always toss it into Slack so I can ctrl-f for it later.
(This is different for their free offering; there, yes, things vanish into the void. But this isn't aimed at pals chatting away in the evening.)
I'm repeating myself, but I've found Zulip many times better than Slack. It's more or less the same, but everything there is a thread, which makes following things much easier. It also supports much better message views (you can "zoom in/out" on them), and it's very fast and extremely keyboard-friendly.
> everything there is a thread
Microsoft Teams is the same, but in certain tech circles MS Teams seems to be hated.
As someone who's staunchly in the Linux camp, I don't have any strong feelings -- I use MS Teams and it's ok. In the corporate world people are ok with it too.
Which brings up an interesting cultural disconnect: people in tech use different tools from folks in the non-tech enterprise/corporate world. As someone who straddles both worlds, it's an interesting divide to observe.
(Side note: this is also why many tech folks vastly underestimate the influence of Azure in most enterprises, which always seemed to me to be an interesting blind spot. This seems very similar to the blind spots that occur in politics.)
Microsoft Teams is the same, but in certain tech circles MS Teams seems to be hated.
As someone who's staunchly in the Linux camp, I don't have any strong feelings -- I use MS Teams and it's ok. In the corporate world people are ok with it too.
Which brings up an interesting cultural disconnect: people in tech use different tools from folks in the non-tech enterprise/corporate world. As someone who straddles both worlds, it's an interesting divide to observe.
(Side note: this is also why many tech folks vastly underestimate the influence of Azure in most enterprises, which always seemed to me to be an interesting blind spot. This seems very similar to the blind spots that occur in politics.)
I would like the Teams UI to be compressed more and some other things but otherwise it is alright. There is a problem with people creating teams channels, upload documents there and then people come and go and some of those documents that should have been in some public repository is instead in that channel (SharePoint) only.
It does not have to be that way but it is very easy to end up that way.
It does not have to be that way but it is very easy to end up that way.
I found the Teams UI confusing and it became one of those "places information goes to get lost" tools (see also: Asana), when I had to use it for a while about a year ago.
[EDIT] also like Asana, I gather people who were in it & related MS tools basically all day—so, managers and similar—thought it was fine.
[EDIT] also like Asana, I gather people who were in it & related MS tools basically all day—so, managers and similar—thought it was fine.
By "everything there is a thread", do you mean there can be multiple topics (subchannels) per channel? Couldn't you achieve the same by namespacing Slack channel names?
First I've heard of Zulip, so perhaps I'm misunderstanding what you mean by thread.
First I've heard of Zulip, so perhaps I'm misunderstanding what you mean by thread.
Slack has channels, each channel has messages, each message has threads. Zulip is basically the same, only you have channel namespaces (streams), channels (topics) and threads (messages).
It's like if you had one channel per topic in Slack, only they're much easier to follow/mute/display.
> Couldn't you achieve the same by namespacing Slack channel names?
You could, but that's super heavy. In Zulip, creating a topic is as easy as replying, and everyone in that stream sees the topic by default, so you don't need to invite people to each one separately.
The most accurate simile really is "Slack, but everything in a channel is a thread, no messages".
It's like if you had one channel per topic in Slack, only they're much easier to follow/mute/display.
> Couldn't you achieve the same by namespacing Slack channel names?
You could, but that's super heavy. In Zulip, creating a topic is as easy as replying, and everyone in that stream sees the topic by default, so you don't need to invite people to each one separately.
The most accurate simile really is "Slack, but everything in a channel is a thread, no messages".
This is a problem with Slack, not the users. The entire platform encourages noise.
Here's an experiment. The next time someone in a channel asks a question, immediately post another question that is unrelated and see how much people see/respond to the first one. It's as good as dead. What a mess.
Here's an experiment. The next time someone in a channel asks a question, immediately post another question that is unrelated and see how much people see/respond to the first one. It's as good as dead. What a mess.
I have a similar problem with batching questions in email, though.
Like even in one-to-one correspondence, you send an email with two questions, you invariably get a response to the easy one and no acknowledgement whatsoever of the difficult, time-sensitive one.
Like even in one-to-one correspondence, you send an email with two questions, you invariably get a response to the easy one and no acknowledgement whatsoever of the difficult, time-sensitive one.
> The next time someone in a channel asks a question, immediately post another question that is unrelated and see how much people see/respond to the first one. It's as good as dead.
This varies hugely based on the culture of the Slack you're in, the channel you're in, etc.
This varies hugely based on the culture of the Slack you're in, the channel you're in, etc.
[deleted]
My personal experience is that the vast majority of slack complaints are solved by:
- Allowing all users to freely create channels as needed
- Raising user awareness of how to use the very flexible channel notification settings (and muting channels that aren't relevant but still things you want to keep an eye on)
- Threading conversations whenever it makes sense
- Encouraging limited usage of @channel and @here (only use when very important)
Humans are remarkably capable at self-organization when given the opportunity.
At the end of the day, Slack is about enabling natural conversations between people. It is not email. It's chat. If you try to enforce rules on how people naturally converse with each other, you are going to encounter a lot of resistance and friction.
- Allowing all users to freely create channels as needed
- Raising user awareness of how to use the very flexible channel notification settings (and muting channels that aren't relevant but still things you want to keep an eye on)
- Threading conversations whenever it makes sense
- Encouraging limited usage of @channel and @here (only use when very important)
Humans are remarkably capable at self-organization when given the opportunity.
At the end of the day, Slack is about enabling natural conversations between people. It is not email. It's chat. If you try to enforce rules on how people naturally converse with each other, you are going to encounter a lot of resistance and friction.
I would agree if I worked at company where a majority of the users saw all of the above as a problem. In my experience (three tech companies with a 4 to 10 times larger non-tech crowd) people who care about asynchronous written communication just leave or ignore the noisy groups and their concern are ignored.
Once CEO stormed our open space and yelled at the entire tech team for having muted the main channel. We’ve had to make a presentation to the whole company about why. That was kind of an eye-opening moment.
> Encouraging limited usage of @channel and @here (only use when very important)
I’ve through about it slightly differently:
* use those only if everyone or a majority of people in the channel will need to change their day-to-day habits because of what you are saying (say, the channel is about an internal tool and that tool is undergoing maintenance);
* do not use those if you are asking for help and want the attention of one person in the group (specific or not); people who have the time will answer. If you use those too often, people who can help you will ignore the channel.
We’ve had to implement a bot in a key internal chanel that, unless you were an admin/support team, would remind people of those rules. We also displayed a ratio of who among the support group had chosen to ignore those signals to convey the point.
Once CEO stormed our open space and yelled at the entire tech team for having muted the main channel. We’ve had to make a presentation to the whole company about why. That was kind of an eye-opening moment.
> Encouraging limited usage of @channel and @here (only use when very important)
I’ve through about it slightly differently:
* use those only if everyone or a majority of people in the channel will need to change their day-to-day habits because of what you are saying (say, the channel is about an internal tool and that tool is undergoing maintenance);
* do not use those if you are asking for help and want the attention of one person in the group (specific or not); people who have the time will answer. If you use those too often, people who can help you will ignore the channel.
We’ve had to implement a bot in a key internal chanel that, unless you were an admin/support team, would remind people of those rules. We also displayed a ratio of who among the support group had chosen to ignore those signals to convey the point.
Thanks for sharing your guidelines.
> Review and edit messages before sending
Part of the joy of Slack is that sending messages to your team is super low-friction so more people are likely to contribute. The example use case is "I have this thought-through proposal I'd like to do. Is it okay with you." In this case it makes sense to review more thoroughly before sending in order to communicate the proposal more clearly.
In other cases, you may want to engage in more back and forth as you debug something together or make a plan together. In these debugging/planning sessions, I think it’s valuable to have the full thought process of the team recorded in Slack. This unfiltered discussion might provide useful context to someone else later.
I like to augment this frictionless back and forth with a summary at the end of the discussion. This makes it easier for someone other than those involved in the conversation to benefit from it. And then they can refer to the full conversation for more details.
I'm one of the creators of a tool that's designed to make these summaries accessible (https://bytebase.io).
> Review and edit messages before sending
Part of the joy of Slack is that sending messages to your team is super low-friction so more people are likely to contribute. The example use case is "I have this thought-through proposal I'd like to do. Is it okay with you." In this case it makes sense to review more thoroughly before sending in order to communicate the proposal more clearly.
In other cases, you may want to engage in more back and forth as you debug something together or make a plan together. In these debugging/planning sessions, I think it’s valuable to have the full thought process of the team recorded in Slack. This unfiltered discussion might provide useful context to someone else later.
I like to augment this frictionless back and forth with a summary at the end of the discussion. This makes it easier for someone other than those involved in the conversation to benefit from it. And then they can refer to the full conversation for more details.
I'm one of the creators of a tool that's designed to make these summaries accessible (https://bytebase.io).
The comments here do a great job highlighting the broad and deep flaws in the OP. I'm happy to see the article only has a few upvotes; I don't understand why it got bumped to the frontpage.
some good tips here but ultimately the tool encourages the undesirable behavior and guidelines likely won't overcome that (even if humans actually read them).
if you feel similarly, would love to get your feedback on a tool that's built to combat slack's issues https://usepingpong.com
if you feel similarly, would love to get your feedback on a tool that's built to combat slack's issues https://usepingpong.com
If etiquette is needed for an app then that's the wrong tool or the tool is that bad. In this case I think it's the wrong tool. If people are that concerned about the visual noise in slack, maybe use something else that is more limited. If emojis are there, that implies they can be used. If there is abuse the option is either to remove them or add an additional feature that tries to solve the problem.
This! Slack was supposed to be better than email. Now it's clear it's just another annoying tool whose purpose is to be nagged by colleagues too lazy or busy to put together their thoughts on a nicely written email.
> If etiquette is needed for an app then that's the wrong tool or the tool is that bad.
Strong disagree. Every form of communication requires some etiquette. Email has etiquette, too. So do newsgroups, forums, blog comments, telephone conversations, face to face conversations, etc.
Strong disagree. Every form of communication requires some etiquette. Email has etiquette, too. So do newsgroups, forums, blog comments, telephone conversations, face to face conversations, etc.
Any tool sufficient powerful to be used can also be misused. All tools need etiquette/agreed norms and conventions.
I disagree. If there's anything you can count on is the end user abusing and taking your features to their limit. Using games as an example, you can't release game and then publish guidelines on how players should not cheat. If your game allows players to cheat easily, they simply will, so it just follows that it's on the developer to release something that will be used appropriately (my point is there is no other way, if you think you can educate the masses, good luck).
So if someone is chewing loudly unmuted on Google Hangouts, it's not bad etiquitte, it's that the tool is bad?
slack abuse is definitely my favorite working in SV in the 2010s trend...
That seems exactly backwards - email works well asynchronously, Slack demands immediate attention. I can check email a few times per day. On Slack, the best you can do is shut off notifications for a while to make some space to not be interrupted.
In my (recent) experience, people expect an answer to an email within 24 hours, they expect a response to a Slack message immediately.