14 ms·

For myself, Slack is such a time waster that I'm at the point where I only check on it periodically. I tell coworkers that if there's an emergency that needs t

For myself, Slack is such a time waster that I'm at the point where I only check on it periodically. I tell coworkers that if there's an emergency that needs to be tended to right away, just text, call, or talk to me in person. If there's something that can wait, email is better. After 2+ years of using Slack on several different teams, I have yet to see any enhanced group communications. I do however see massive amounts of distractions and failed concentration. I'm sure "I'm doing it wrong", but this has been my experience with Slack.

fs2 8y ago
My experience exactly. The most common observation with Slack is how people praise it as the next big thing in productivity. But this is always during the honeymoon phase, after a few months of working with Slack it usually quickly wears off.
- rjdagost 8y ago
  I think the worst part of it (as the article mentions) is that it feels like you are doing something productive when you're using Slack, but the majority of time you're actually not. You're generating conversations, notifications, and in general producing tangible output that for me is subconsciously gratifying. That hooks me in to using the service even though consciously I know that I'm not getting real work done.
  - ethbro 8y ago
    The benefit I've found is in cross-team communication. Specifically of the "I need to reach out to this team I don't know about their product" variety. A) If they interact with Slack, I can search previous answers B) It promotes a culture of openness. Huge benefit in some orgs! We talk about our projects, warts and all, in public channels. If all your org channels are private, you're definitely Doing It Wrong C) It's far more scalable than ticketing. Issues can be resolved in three lines of text, rather than ticket creation, queue, assignment, closing, etc. As an above commenter noted though, you can and should push back on expectations of constant availability. Slack is asynchronous, not for initiating hi-pri issues.
    - Jedd 8y ago
      > Slack is asynchronous. You are describing a proprietary, expensive, intrusive, demanding rewrite of SMTP.
      - grogenaut 8y ago
        Don't forget mailman + elastic search.
      - StavrosK 8y ago
        I very much like Zulip, it's open source and much closer to email, even culturally. It encourages long-form replies and messages with subjects, so it requires at least a tiny amount of thought before you start talking to someone. I think it's a great cross between Slack and email.
        ethbro 8y ago
        Just looked at it. What keeps Zulip threads from exploding in practice? Either on the UI or usage side? E.g. How to I keep from going from "One channel with a hundred unread messages" to "One channel with twenty unread threads"? Also, what features exist when a thread diverges from the original topic? E.g. We were talking about the "afternoon lunch" at the "annual meeting", and then someone mentioned their favorite restaurants in the area, and now people are replying to both? Organization seems more like a usage problem than a technology problem. Or at least one that I can't see manual categorization solving.
        tabbott 8y ago
        The point is that it's a lot faster to process 20 unread threads with 100 messages than 100 unread messages, because they're nicely grouped. E.g. you can skip reading the 30 messages in the thread about "afternoon lunch", without having to look at those messages (as you would with slack if you wanted to find out that the 'annual meeting' announcement happened). For diverging topics, you can easily edit the topics of the messages that are a diversion to be a new topic. This helps a huge amount when you have new users who haven't learned the convention of creating a new topic when bringing up something unrelated, since anyone can clean it up in a few seconds.
  - tw20190412hbqcg 8y ago
    > it feels like you are doing something productive when you're using Slack, but the majority of time you're actually not That's been my main complaint about GitHub throughout its meteoric rise. Its public contribution graphs and user profiles littered with hundreds of dead forks certainly encourage this behavior. And I say this not as a person who has an unreasonable disdain for things like business processes and engineering tools (such as bugtrackers); I tend to favor (good) process more than other people—I've had personal projects where I'm the only contributor and user, and yet if you peek into the bugtracker you'll see hundreds of comments from me explaining exactly what's going on wrt the root cause and any fixes, and all known issues at any given time have an appropriate bug on-file. But when I use GitHub, it's like every interaction ends up getting sidetracked either due to input from users trying to feel productive by leaving comments that are ultimately value-negative, or some weirdo contributor responding to my bug report as if I'm filing a support request and who then tries to "help" me by explaining how I can work around it (I have no problems working around it—in fact, by the time you're hearing from me, that's old news. But this is a bugtracker! For, you know, tracking bugs!), or the peanut gallery using the bugtracker like it's a phpBB forum dedicated to general chatter and expressions of gratitude related to the project (instead of, you know, tracking bugs!). The worst is when somebody is showing off a project, I take a look, find something like a simple typo, and let the person know, and then they ask me to file a PR. First, I'm probably not even interested in your project even as a leeching user. Secondly, if you can't be bothered to do anything about this thing in your own project that you already understand that that you probably already have opened in your IDE right now, do you really expect me to clone the repo, poke around until I understand the busted directory structure you're using to organize the code, locate the appropriate source file, commit it, and then use GitHub's needlessly convoluted pull request workflow that involves pushing those changes to a third fork and asking you to review them? Do you understand that all this is happening on top of the assumption that I even have a GitHub account in the first place? Why don't you just Alt-Tab over there and help yourself instead of offloading work onto some random stranger who has no vested interest in your project but who decided to spend a little effort typing out a message that would be of interest to the person currently pimping out their project? ... and then every time I mention this, someone comes around, totally misses the point, and leaves an obnoxious comment that "You don't have to clone the repo! You can make minor fixes like that from the GitHub web UI!" It's like nobody knows how to distinguish between busy work vs things that are actually necessary to the process and/or indicators of real, forward motion.
- skohan 8y ago
  I find it has utility in the fact that it's a searchable record of technical conversations I have had with my colleagues where I can go to recover details I might not remember from a month ago. Then again email also does this just fine, and doesn't cost as much.
  - grogenaut 8y ago
    Search is one of slacks worst features and I resort to scrolling which is also majorly painful. I can count on one hand the number of times I've found what I needed via slack search in 4 years with it. I've had it be unable to find the exact text of a message on screen in a channel I'm searching in a day later (tested).
    - alehul 8y ago
      Search is one of my favorite parts of Slack. It assumes that I want to search within a certain channel or messages with a certain person when that's where I'm clicking the search bar from, but I can quickly erase that if desired. Files, messages, and people, are all searchable. It's pretty powerful and extremely user-friendly (most non-techies would have trouble with the syntax for specifying who a message should be from while searching). Meanwhile, with Gmail, I discovered yesterday that when I'm part of a mailing list attached to an email address (let's say product@startup.com), and I search an email address that was cc'd on the product@startup.com email, nothing comes up. Resulted in a lot of wasted time.
    - jasonlotito 8y ago
      I'm gonna also have to disagree. Slack search works. I can rely on it to save the information needed, and my ability to recover it.
    - tanseydavid 8y ago
      I will have to agree, the search feature in Slack is nearly useless. Or, perhaps 'I am using it wrong' to join in the chorus.
    - strokirk 8y ago
- res0nat0r 8y ago
  People keep wanting to blame Slack for this problem, but it really is the folks you're working with who are the issue. Slack is getting such a huge valuation so quickly because it is incredibly simple to use and is very user friendly. IM tools like Skype / Sametime / whatever have been around for companies forever, but Slack is much more user friendly and frictionless to use from the ground up, and with plugins even more useful. I think most of the hate here keeps coming back to issues with peoples coworkers, not whatever IM platform they want to dislike that is currently making tons of cash.
neilv 8y ago
Ugh. I have an anecdote in which I was brought in by a great niche technical contracting firm, as a developer who was also supposed to repair a client relationship, after a previous developer quit. I learned that the problem on client site was not quite what was expected (they already knew the client's manager didn't want contractors). It turned out that a significant part the problem on the ground was simply that the contracting company's on-site manager was bombarding the contractors with instant messages they were required to monitor. There were a few other things (including no onboarding/documentation for client's unique SCM and build environment, some strong personal styles, and a factor that was doing the opposite of what it was supposed to do), but the frustrating message interruptions alone might've made the morale difference that led to the person quitting. In lieu of Slack, one lightweight pattern that often works is something like: * Email for things you should see, possibly urgently (ideally with simple filters/actions, for when/how to alert/expose different messages, which the individual can tune over time, to their needs). * Lightweight chat (maybe IRC/XMPP/etc.) for things you don't have to see (such as questions you don't want to interrupt anyone over, but they can answer if they're available enough to look at chat; and perhaps watercooler chatter for personalizing everyone, especially when you have remote workers). Be careful that this doesn't turn into fear-of-missing-out compulsion or an operational must-see -- emphasize that turning it into must-see is counter to the goal of the medium, becoming a burden for people. * Agreed-upon simple in-repo/wiki/other for capturing information that people need to see in the future. Try to make this lightweight enough that it's not a burden to capture this information in a way that's accessible/usable to people when they need it. The organization can evolve this over time, but the above is not a bad start. A possible side benefit of rolling a lightweight solution on your own is that you don't need to trust a third-party with your company-confidential data (nor inside 'analytics' of your people and company), nor deal with possible goal misalignment with the third-party. (Of course, you can decide any third-party is worthwhile, and sys-admin is usually not what you want to be spending time on in most startups, but you have many options.)
- golergka 8y ago
  So, how did that contracting situation end? Did the manager correct his behaviour?
jasonlotito 8y ago
Seems like you only deal with small teams. Texting, calling, or standing up and talking don't scale well. Talking doesn't work when people aren't sitting next to one another in the same city, state, country, or hemisphere. Calling isn't going to work either, as you are limited to audio only and makes triaging situations more difficult. And texting is clumsy at best, and doesn't assist with triaging. And none of these methods make it easy to integrate tooling. Not to mention any sort of regulations. As for email, it works for longer form stuff. But not for having a real time conversation that involves multiple people. It's akin to saying Google Docs is useless because you can collaborate on a document in email. Like any tool, it's how you use it. Slack can be distracting if you let it. It can be useless if you don't use the tools it gives you. Can you do everything slack does with other tools? Sure. But it will require a massive amount of effort to get you up and running again.
klibertp 8y ago
Calls are really, really bad for shared knowledge building. Either you require each call to end with a note, discourage one-to-one calls and favor group calls, or accept that the speed of knowledge diffusion in the team will slow down to a crawl. I believe it's easy to see the downsides of all of these possibilities. Mailing lists, Usenet, IRC, Slack, bulletin board, wiki, GitHub issues - doesn't matter which, use whatever works for you and is most convenient, but, whatever you do, please communicate in text. Bonus points for storing all that text in a searchable place. Well, once the speech to text is sufficiently accurate, this may change (although there's always that chilling feeling of having so many of your voice samples sent to Google) - but until then, communicate in text as much as possible. Both deaf people, social phobiacs, and new hires will thank you for that.
- rjdagost 8y ago
  I disagree with your "text is superior" stance. You assume that the point of a phone call is to enhance "shared knowledge building", but that's often not the case. A phone call is meant to communicate something directly, and that "something" may or may not be knowledge that should be spread through the team. Phone calls have disadvantages, but so does text. There is information that gets lost when we reduce our communications to text. I find it to be much easier to infer someone's mood and intent when I talk to them vs. reading chat messages. There is no universally better communications mode.
  - klibertp 8y ago
    > I find it to be much easier to infer someone's mood and intent when I talk to them vs. reading chat messages. All the deaf programmers of the world would like to have - haha - a chat with you. You'd surely quickly recognize their mood :P I'm being sarcastic, but the accessibility angle is a serious one. > and that "something" may or may not be knowledge that should be spread through the team Whatever you talked about, either resulted in a decision (which should be documented anyway, because you never know who and when may be affected by it) or it didn't, in which case it could have been an email to one person or a group of people. > I find it to be much easier to infer someone's mood and intent when I talk to them That's a problem with the literacy of that person. All the words needed to express various moods and intents are there in the dictionaries; this is a battle-tested, mature technology (I mean, written English) which only got so much better since we're able to attach funny cat pictures to each sentence now. > There is no universally better communications mode. Of course, as it depends on what you consider "better". What I'm saying is that text is better for accessibility, transparency, scalability and searchability. Speech, on the other hand, makes expressing one's emotions easier. Such an advantage. Probably the only good use for a call is to notify all the right people when some disaster happens (and really quick - seconds to minutes - decisions are required) or in case a CEO prepared a New Year's speech (at least if they honestly worked on their public speaking skill). Everything else is unnecessarily disruptive, favors quick responses when thoughtfulness is often more important, and gets incredibly messy quickly when you start adding more people.
munchbunny 8y ago
I've found a set of cultural rules for Slack that tends to work well for keeping Slack a high quality communication tool. 1. If it can be an email, put it in an email instead. Email has far better tooling than Slack for automatically filtering and triaging messages so that the recipient can focus on the important ones. 2. The busyness of a channel should be inversely proportional to the number of participants. Channels with >10 participants should be virtual ghost towns. 2a. Except when you are using the channel for crisis management. 2b. Except for channels where people are asking "how to" questions, for those, either have the current on-call people triage it and call in the experts as needed, or set the expectation that people will get answers eventually. 3. If you need a response in under an hour, do a voice call or find them in person. 4. Employees should not be expected to have Slack on their phones, and employees should not be expected to respond outside of work hours. Edit: also rule #5: Social channels: they are neither forbidden nor discouraged, but for the sake of your own focus, you should keep them muted.

fs2 8y ago

My experience exactly. The most common observation with Slack is how people praise it as the next big thing in productivity. But this is always during the honeymoon phase, after a few months of working with Slack it usually quickly wears off.

rjdagost 8y ago
I think the worst part of it (as the article mentions) is that it feels like you are doing something productive when you're using Slack, but the majority of time you're actually not. You're generating conversations, notifications, and in general producing tangible output that for me is subconsciously gratifying. That hooks me in to using the service even though consciously I know that I'm not getting real work done.
- ethbro 8y ago
  The benefit I've found is in cross-team communication. Specifically of the "I need to reach out to this team I don't know about their product" variety. A) If they interact with Slack, I can search previous answers B) It promotes a culture of openness. Huge benefit in some orgs! We talk about our projects, warts and all, in public channels. If all your org channels are private, you're definitely Doing It Wrong C) It's far more scalable than ticketing. Issues can be resolved in three lines of text, rather than ticket creation, queue, assignment, closing, etc. As an above commenter noted though, you can and should push back on expectations of constant availability. Slack is asynchronous, not for initiating hi-pri issues.
  - Jedd 8y ago
    > Slack is asynchronous. You are describing a proprietary, expensive, intrusive, demanding rewrite of SMTP.
    - grogenaut 8y ago
      Don't forget mailman + elastic search.
    - StavrosK 8y ago
      I very much like Zulip, it's open source and much closer to email, even culturally. It encourages long-form replies and messages with subjects, so it requires at least a tiny amount of thought before you start talking to someone. I think it's a great cross between Slack and email.
      - ethbro 8y ago
        Just looked at it. What keeps Zulip threads from exploding in practice? Either on the UI or usage side? E.g. How to I keep from going from "One channel with a hundred unread messages" to "One channel with twenty unread threads"? Also, what features exist when a thread diverges from the original topic? E.g. We were talking about the "afternoon lunch" at the "annual meeting", and then someone mentioned their favorite restaurants in the area, and now people are replying to both? Organization seems more like a usage problem than a technology problem. Or at least one that I can't see manual categorization solving.
        tabbott 8y ago
        The point is that it's a lot faster to process 20 unread threads with 100 messages than 100 unread messages, because they're nicely grouped. E.g. you can skip reading the 30 messages in the thread about "afternoon lunch", without having to look at those messages (as you would with slack if you wanted to find out that the 'annual meeting' announcement happened). For diverging topics, you can easily edit the topics of the messages that are a diversion to be a new topic. This helps a huge amount when you have new users who haven't learned the convention of creating a new topic when bringing up something unrelated, since anyone can clean it up in a few seconds.
- tw20190412hbqcg 8y ago
  > it feels like you are doing something productive when you're using Slack, but the majority of time you're actually not That's been my main complaint about GitHub throughout its meteoric rise. Its public contribution graphs and user profiles littered with hundreds of dead forks certainly encourage this behavior. And I say this not as a person who has an unreasonable disdain for things like business processes and engineering tools (such as bugtrackers); I tend to favor (good) process more than other people—I've had personal projects where I'm the only contributor and user, and yet if you peek into the bugtracker you'll see hundreds of comments from me explaining exactly what's going on wrt the root cause and any fixes, and all known issues at any given time have an appropriate bug on-file. But when I use GitHub, it's like every interaction ends up getting sidetracked either due to input from users trying to feel productive by leaving comments that are ultimately value-negative, or some weirdo contributor responding to my bug report as if I'm filing a support request and who then tries to "help" me by explaining how I can work around it (I have no problems working around it—in fact, by the time you're hearing from me, that's old news. But this is a bugtracker! For, you know, tracking bugs!), or the peanut gallery using the bugtracker like it's a phpBB forum dedicated to general chatter and expressions of gratitude related to the project (instead of, you know, tracking bugs!). The worst is when somebody is showing off a project, I take a look, find something like a simple typo, and let the person know, and then they ask me to file a PR. First, I'm probably not even interested in your project even as a leeching user. Secondly, if you can't be bothered to do anything about this thing in your own project that you already understand that that you probably already have opened in your IDE right now, do you really expect me to clone the repo, poke around until I understand the busted directory structure you're using to organize the code, locate the appropriate source file, commit it, and then use GitHub's needlessly convoluted pull request workflow that involves pushing those changes to a third fork and asking you to review them? Do you understand that all this is happening on top of the assumption that I even have a GitHub account in the first place? Why don't you just Alt-Tab over there and help yourself instead of offloading work onto some random stranger who has no vested interest in your project but who decided to spend a little effort typing out a message that would be of interest to the person currently pimping out their project? ... and then every time I mention this, someone comes around, totally misses the point, and leaves an obnoxious comment that "You don't have to clone the repo! You can make minor fixes like that from the GitHub web UI!" It's like nobody knows how to distinguish between busy work vs things that are actually necessary to the process and/or indicators of real, forward motion.
skohan 8y ago
I find it has utility in the fact that it's a searchable record of technical conversations I have had with my colleagues where I can go to recover details I might not remember from a month ago. Then again email also does this just fine, and doesn't cost as much.
- grogenaut 8y ago
  Search is one of slacks worst features and I resort to scrolling which is also majorly painful. I can count on one hand the number of times I've found what I needed via slack search in 4 years with it. I've had it be unable to find the exact text of a message on screen in a channel I'm searching in a day later (tested).
  - alehul 8y ago
    Search is one of my favorite parts of Slack. It assumes that I want to search within a certain channel or messages with a certain person when that's where I'm clicking the search bar from, but I can quickly erase that if desired. Files, messages, and people, are all searchable. It's pretty powerful and extremely user-friendly (most non-techies would have trouble with the syntax for specifying who a message should be from while searching). Meanwhile, with Gmail, I discovered yesterday that when I'm part of a mailing list attached to an email address (let's say product@startup.com), and I search an email address that was cc'd on the product@startup.com email, nothing comes up. Resulted in a lot of wasted time.
  - jasonlotito 8y ago
    I'm gonna also have to disagree. Slack search works. I can rely on it to save the information needed, and my ability to recover it.
  - tanseydavid 8y ago
    I will have to agree, the search feature in Slack is nearly useless. Or, perhaps 'I am using it wrong' to join in the chorus.
  - strokirk 8y ago
res0nat0r 8y ago
People keep wanting to blame Slack for this problem, but it really is the folks you're working with who are the issue. Slack is getting such a huge valuation so quickly because it is incredibly simple to use and is very user friendly. IM tools like Skype / Sametime / whatever have been around for companies forever, but Slack is much more user friendly and frictionless to use from the ground up, and with plugins even more useful. I think most of the hate here keeps coming back to issues with peoples coworkers, not whatever IM platform they want to dislike that is currently making tons of cash.

neilv 8y ago

Ugh. I have an anecdote in which I was brought in by a great niche technical contracting firm, as a developer who was also supposed to repair a client relationship, after a previous developer quit. I learned that the problem on client site was not quite what was expected (they already knew the client's manager didn't want contractors). It turned out that a significant part the problem on the ground was simply that the contracting company's on-site manager was bombarding the contractors with instant messages they were required to monitor. There were a few other things (including no onboarding/documentation for client's unique SCM and build environment, some strong personal styles, and a factor that was doing the opposite of what it was supposed to do), but the frustrating message interruptions alone might've made the morale difference that led to the person quitting. In lieu of Slack, one lightweight pattern that often works is something like: * Email for things you should see, possibly urgently (ideally with simple filters/actions, for when/how to alert/expose different messages, which the individual can tune over time, to their needs). * Lightweight chat (maybe IRC/XMPP/etc.) for things you don't have to see (such as questions you don't want to interrupt anyone over, but they can answer if they're available enough to look at chat; and perhaps watercooler chatter for personalizing everyone, especially when you have remote workers). Be careful that this doesn't turn into fear-of-missing-out compulsion or an operational must-see -- emphasize that turning it into must-see is counter to the goal of the medium, becoming a burden for people. * Agreed-upon simple in-repo/wiki/other for capturing information that people need to see in the future. Try to make this lightweight enough that it's not a burden to capture this information in a way that's accessible/usable to people when they need it. The organization can evolve this over time, but the above is not a bad start. A possible side benefit of rolling a lightweight solution on your own is that you don't need to trust a third-party with your company-confidential data (nor inside 'analytics' of your people and company), nor deal with possible goal misalignment with the third-party. (Of course, you can decide any third-party is worthwhile, and sys-admin is usually not what you want to be spending time on in most startups, but you have many options.)

golergka 8y ago
So, how did that contracting situation end? Did the manager correct his behaviour?

jasonlotito 8y ago

Seems like you only deal with small teams. Texting, calling, or standing up and talking don't scale well. Talking doesn't work when people aren't sitting next to one another in the same city, state, country, or hemisphere. Calling isn't going to work either, as you are limited to audio only and makes triaging situations more difficult. And texting is clumsy at best, and doesn't assist with triaging. And none of these methods make it easy to integrate tooling. Not to mention any sort of regulations. As for email, it works for longer form stuff. But not for having a real time conversation that involves multiple people. It's akin to saying Google Docs is useless because you can collaborate on a document in email. Like any tool, it's how you use it. Slack can be distracting if you let it. It can be useless if you don't use the tools it gives you. Can you do everything slack does with other tools? Sure. But it will require a massive amount of effort to get you up and running again.

klibertp 8y ago

Calls are really, really bad for shared knowledge building. Either you require each call to end with a note, discourage one-to-one calls and favor group calls, or accept that the speed of knowledge diffusion in the team will slow down to a crawl. I believe it's easy to see the downsides of all of these possibilities. Mailing lists, Usenet, IRC, Slack, bulletin board, wiki, GitHub issues - doesn't matter which, use whatever works for you and is most convenient, but, whatever you do, please communicate in text. Bonus points for storing all that text in a searchable place. Well, once the speech to text is sufficiently accurate, this may change (although there's always that chilling feeling of having so many of your voice samples sent to Google) - but until then, communicate in text as much as possible. Both deaf people, social phobiacs, and new hires will thank you for that.

rjdagost 8y ago
I disagree with your "text is superior" stance. You assume that the point of a phone call is to enhance "shared knowledge building", but that's often not the case. A phone call is meant to communicate something directly, and that "something" may or may not be knowledge that should be spread through the team. Phone calls have disadvantages, but so does text. There is information that gets lost when we reduce our communications to text. I find it to be much easier to infer someone's mood and intent when I talk to them vs. reading chat messages. There is no universally better communications mode.
- klibertp 8y ago
  > I find it to be much easier to infer someone's mood and intent when I talk to them vs. reading chat messages. All the deaf programmers of the world would like to have - haha - a chat with you. You'd surely quickly recognize their mood :P I'm being sarcastic, but the accessibility angle is a serious one. > and that "something" may or may not be knowledge that should be spread through the team Whatever you talked about, either resulted in a decision (which should be documented anyway, because you never know who and when may be affected by it) or it didn't, in which case it could have been an email to one person or a group of people. > I find it to be much easier to infer someone's mood and intent when I talk to them That's a problem with the literacy of that person. All the words needed to express various moods and intents are there in the dictionaries; this is a battle-tested, mature technology (I mean, written English) which only got so much better since we're able to attach funny cat pictures to each sentence now. > There is no universally better communications mode. Of course, as it depends on what you consider "better". What I'm saying is that text is better for accessibility, transparency, scalability and searchability. Speech, on the other hand, makes expressing one's emotions easier. Such an advantage. Probably the only good use for a call is to notify all the right people when some disaster happens (and really quick - seconds to minutes - decisions are required) or in case a CEO prepared a New Year's speech (at least if they honestly worked on their public speaking skill). Everything else is unnecessarily disruptive, favors quick responses when thoughtfulness is often more important, and gets incredibly messy quickly when you start adding more people.

munchbunny 8y ago

I've found a set of cultural rules for Slack that tends to work well for keeping Slack a high quality communication tool. 1. If it can be an email, put it in an email instead. Email has far better tooling than Slack for automatically filtering and triaging messages so that the recipient can focus on the important ones. 2. The busyness of a channel should be inversely proportional to the number of participants. Channels with >10 participants should be virtual ghost towns. 2a. Except when you are using the channel for crisis management. 2b. Except for channels where people are asking "how to" questions, for those, either have the current on-call people triage it and call in the experts as needed, or set the expectation that people will get answers eventually. 3. If you need a response in under an hour, do a voice call or find them in person. 4. Employees should not be expected to have Slack on their phones, and employees should not be expected to respond outside of work hours. Edit: also rule #5: Social channels: they are neither forbidden nor discouraged, but for the sake of your own focus, you should keep them muted.