
Creating a Slack Writing Etiquette Guide for Your Workplace - rcvictorino
https://slab.com/blog/slack-etiquette-guide/
======
Thrymr
"It's not built for synchronous communication the way emails and documentation
tools are."

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.

------
juanuys
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.

~~~
chanmad29
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.

~~~
hnrodey
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.

------
water42
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>?

~~~
Bartweiss
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!_

~~~
blackearl
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.

~~~
iamatworknow
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:.

------
pavel_lishin
> _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.)

------
StavrosK
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.

~~~
wenc
> 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.)

~~~
cc81
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.

------
matchbok
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.

~~~
neutronicus
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.

------
remmargorp64
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.

~~~
bertil
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.

------
cborenstein
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](https://bytebase.io)).

------
gowld
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.

------
jamauro
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](https://usepingpong.com)

------
proc0
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.

~~~
seattle_spring
So if someone is chewing loudly unmuted on Google Hangouts, it's not bad
etiquitte, it's that the tool is bad?

~~~
nexuist
Most group audio clients allow you to mute individual users to solve this
exact problem. A group audio client that doesn't let you mute individual users
is therefore inherently bad relative to other competitors in the space.

------
5cott0
slack abuse is definitely my favorite working in SV in the 2010s trend...

