Each company has different practices when it comes to Slack; and, as someone who has used Slack so much that it's mentioned about him at those companies (not always in a positive light?), I have a few thoughts and rules about the best Slack usage that I think help, in general.
1) At any not-small company, you're going to want to almost immediately change your Sidebar from "Everything" to "Unread and starred conversations".
2) Star all channels that you personally need to keep track of (or want to keep track of for a certain amount of time) and all people that you want to talk to or are currently in an important conversation with.
3) Unstar channels and people where #2 is no longer the case.
4) Create private channels for any conversation / project or issue that will ever require more than the people that are currently in a 'multi-person private message'. Archive them when the issue is over.
5) Use @here sparingly and @channel way more sparingly. If you're at a company that doesn't use @here / @channel sparingly, mute them for the channels that use them in excess. My current company has a meeting room shortage, so every single time a meeting room is freed up unexpectedly, there's an @here in one of our channels. That channel has @here notifications disabled.
6) If you can, in your broader "all the devs hang out here and can chat about work stuff" or "talk with ops here" channels, consider adding group aliases, so you can say, in those channels @ops, or @team-ops to notify just that group when things are important.
7) Use @here sparingly, yourself. Use it only for extreme situations.
8) Give chatty bots their own channel. Having the pull request bot for your dev team in the same channel as active development is going on, or in the same channel as other teams are supposed to come in to talk to you about a project your team is working on is just not the best.
9) Current, unproven experiment: at my current job, my team is experimenting with a heavy use of threads. Previously, we had multiple projects occurring concurrently and historical knowledge on features is spread across the team with a lot of new members, so we can't use the tricks of private channels per project to as much effect. Threads have a lot of weaknesses when it comes to readability and following; but, they do reduce the chances that someone's important message will get lost in a swarm of other messages on more pressing issues.
edit: Whoops, thought of more.
10) Use snippets for any bit of code even slightly long. I'm thinking like 7 lines or more. There's syntax highlighting, and they're collapsible, saving precious screen real-estate
11) Use Posts for large format messages you want to post to a channel or multiple channels. They have formatting, headers, and so on. They're also collapsible, again to save on screen real-estate.
12) Personal preference: try to not send multiple, short messages, unless that's your company's culture. It breaks up the conversation and makes it a bit hard to follow where a thread is, if you're using threads. For example, which message do you put the response on? The part where the situation got confusing? A random message in the middle? The last one? The first one?
edit 2, 3: more adding (I'll just add more after this and not say I'm adding more, if it happens again), and some removing some unnecessary information
13) Mute channels that you want to remain in, but don't want to be bothered by (maybe unmute @here and @mentions on this channel). This could include your company's random chatting channel, or the operations channel, or even your personal team's channel if you're currently heads down in a major project, but you might need to be pinged for something serious.
My biggest irritation in Slack is when people direct message me with 'Hi' and then wait for me to respond before they tell me what they need from me.
Please just tell me immediately what you need, so I can decide how urgently I need to reply. I don't want to reply to you, and then have to wait for your to type out what you need for me. It's a big distraction.
> Hi
< Hi.
> Do you have time for a question?
*internal sigh*
< What is it?
It wastes both parties' time.
But some people consider it more courteous. In general, courtesy is a low-level de-optimization (non-productive words/interactions) striving to avoid higher-level impediments (taking offense, etc.)
> 4) Create private channels for any conversation / project or issue that will ever require more than the people that are currently in a 'multi-person private message'. Archive them when the issue is over.
This, but I'd change it a bit: don't ever use multi-person private messages. You can't add people, and people can't leave if they figure the conversation isn't relevant to them. They should have a feature to convert a multi-person-pm into a room, including all the previously sent messages.
RE threads: they seem broken to me. Hard to navigate, and when I'm typing, it will show that there are new messages but won't show new messages in the thread until I send my message or delete my draft.
I'll add another one: pay for typing lessons for everyone that isn't reasonably fast. I get very annoyed with people that are slow at typing and take forever to write a response. It gets to the point that I start suggesting to get on a call because I know they can talk at a reasonable speed but typing out the information will take them minutes.
You actually can add people; open up the member list (the stylized "bust" icon at the top left or the information icon to the right) and there's a button there: "Add people".
Yeah, leaving is my main issue. When I get pulled into something and I decide it's not relevant to me, I can close the conversation, but it'll reopen as soon as anyone writes anything, so muting and having it pollute my conversation list is the only option.
Can added people read previous messages, or are they only starting at the moment they enter?
All that does with a private DM group of < 7 people is create a new DM group, and the conversation is not migrated. So you're effectively starting from scratch, and the new addition has no ability to go back and catch up.
I can understand the reasoning for this, but its also an area where private channels are much better at.
This is a great list. When I switched my view to “unread and starred” and started aggressively starring and I unstarring things to keep a sort of living todo list my Slack workflow vastly improved.
I disagree with you on the topic of threads though. IMO threads are Slacks worst feature. They put all of this effort into giving users excellent granular control over presence and notifications but every thread update gets lumped into a single sidebar item with no context. I don’t know if the thread notification is important or not nor who it’s from unless I interrupt my work and click into it. I wish they’d remove it or improve the notifications.
I agree with your idea of private channels, but would also suggest that a naming convention for them is used. Public channel names cannot overlap with private channels.
One Slack community I'm active in wanted to add `testing` as a channel. But we couldn't, because that channel name was already taken as a private channel that was created before we locked down channel creation to the admins only. None of the admins were part of that channel, and we don't know if its still active to this day.
As a result, we had to do `testing_`, with the trailing underscore as the differntiation.
BUT when you do `#testing_` in the slack input, the channel name isn't hyperlinked. :-/
Each company has different practices when it comes to Slack; and, as someone who has used Slack so much that it's mentioned about him at those companies (not always in a positive light?), I have a few thoughts and rules about the best Slack usage that I think help, in general.
1) At any not-small company, you're going to want to almost immediately change your Sidebar from "Everything" to "Unread and starred conversations".
2) Star all channels that you personally need to keep track of (or want to keep track of for a certain amount of time) and all people that you want to talk to or are currently in an important conversation with.
3) Unstar channels and people where #2 is no longer the case.
4) Create private channels for any conversation / project or issue that will ever require more than the people that are currently in a 'multi-person private message'. Archive them when the issue is over.
5) Use @here sparingly and @channel way more sparingly. If you're at a company that doesn't use @here / @channel sparingly, mute them for the channels that use them in excess. My current company has a meeting room shortage, so every single time a meeting room is freed up unexpectedly, there's an @here in one of our channels. That channel has @here notifications disabled.
6) If you can, in your broader "all the devs hang out here and can chat about work stuff" or "talk with ops here" channels, consider adding group aliases, so you can say, in those channels @ops, or @team-ops to notify just that group when things are important.
7) Use @here sparingly, yourself. Use it only for extreme situations.
8) Give chatty bots their own channel. Having the pull request bot for your dev team in the same channel as active development is going on, or in the same channel as other teams are supposed to come in to talk to you about a project your team is working on is just not the best.
9) Current, unproven experiment: at my current job, my team is experimenting with a heavy use of threads. Previously, we had multiple projects occurring concurrently and historical knowledge on features is spread across the team with a lot of new members, so we can't use the tricks of private channels per project to as much effect. Threads have a lot of weaknesses when it comes to readability and following; but, they do reduce the chances that someone's important message will get lost in a swarm of other messages on more pressing issues.
edit: Whoops, thought of more.
10) Use snippets for any bit of code even slightly long. I'm thinking like 7 lines or more. There's syntax highlighting, and they're collapsible, saving precious screen real-estate
11) Use Posts for large format messages you want to post to a channel or multiple channels. They have formatting, headers, and so on. They're also collapsible, again to save on screen real-estate.
12) Personal preference: try to not send multiple, short messages, unless that's your company's culture. It breaks up the conversation and makes it a bit hard to follow where a thread is, if you're using threads. For example, which message do you put the response on? The part where the situation got confusing? A random message in the middle? The last one? The first one?
edit 2, 3: more adding (I'll just add more after this and not say I'm adding more, if it happens again), and some removing some unnecessary information
13) Mute channels that you want to remain in, but don't want to be bothered by (maybe unmute @here and @mentions on this channel). This could include your company's random chatting channel, or the operations channel, or even your personal team's channel if you're currently heads down in a major project, but you might need to be pinged for something serious.