Unslacking Tideways Company(beberlei.de)
beberlei.de
Unslacking Tideways Company
https://beberlei.de/2018/10/28/unslacking_tideways_company.html
161 comments
Slack's value isn't communication efficiency. It's value is in enabling people to feel more part of a team. It's a culture tool as much as a communication tool.
> where many hobbists come in and have questions on this software/hardware project
I'm rather baffled by the use of chat for this kind of problem. (and I never clicked with IRC either)
So - I've got a problem and I come to a chat channel. It's probably been asked before. If I'm lucky I'll find my answer in a searchable chat archive and I won't need to visit at all. Otherwise I face two options:
1. Scroll back and try and find any previous mentions. Nearly impossible in my experience.
2. Ask my question and hope that people aren't sick of hearing it. If I'm lucky enough that a) someone is present who knows the answer and b) they respond in a timely manner then I still face the problem that - assuming it's busy enough for a and b to be likely - then my conversation is interspersed with several unrelated discussions. Also - the person helping me is likely to go quiet for long periods or disappear altogether because most probably they are doing other stuff.
Note that the final flaw (the interleaving of discussions) is a problem in all cases.
Now - can someone explain to me how this is better than a forum or Stack Overflow style site?
I'm rather baffled by the use of chat for this kind of problem. (and I never clicked with IRC either)
So - I've got a problem and I come to a chat channel. It's probably been asked before. If I'm lucky I'll find my answer in a searchable chat archive and I won't need to visit at all. Otherwise I face two options:
1. Scroll back and try and find any previous mentions. Nearly impossible in my experience.
2. Ask my question and hope that people aren't sick of hearing it. If I'm lucky enough that a) someone is present who knows the answer and b) they respond in a timely manner then I still face the problem that - assuming it's busy enough for a and b to be likely - then my conversation is interspersed with several unrelated discussions. Also - the person helping me is likely to go quiet for long periods or disappear altogether because most probably they are doing other stuff.
Note that the final flaw (the interleaving of discussions) is a problem in all cases.
Now - can someone explain to me how this is better than a forum or Stack Overflow style site?
I think forums are a better solution for this kind of problem.
However, forums suffer from two crippling problems: 1. It's really hard to find active forums (discoverability), and 2. Forums are often overwhelmed with spam and security problems (integrity).
If those two problems could be solved, or at least mitigated better, then forums might make a comeback.
However, forums suffer from two crippling problems: 1. It's really hard to find active forums (discoverability), and 2. Forums are often overwhelmed with spam and security problems (integrity).
If those two problems could be solved, or at least mitigated better, then forums might make a comeback.
Re: searching, I like Gitter for that - they have their chat history out in public, indexed by Google.
I occasionally I find them very usable. Before you ask on IRC (on a channel you haven't visited before) you will google it extensively. If the question is either a quick question that anyone in the know can answer directly with a yes/no like answer then IRC can be a good option.
But I especially find that IRC is better for very niche questions that won't benefit anyone else (and won't have been asked before) that also requires some back-and-forth debug style to get to the bottom of it.
Similar to problems where email doesn't work and you need make a call instead. A ten minute call can sometimes save you a week of emails if they are not quick enough to answer (common with large timezone differences).
Also much quicker, you either get the answer or you don't, either way both are good to know (so that you know to try something else).
But I especially find that IRC is better for very niche questions that won't benefit anyone else (and won't have been asked before) that also requires some back-and-forth debug style to get to the bottom of it.
Similar to problems where email doesn't work and you need make a call instead. A ten minute call can sometimes save you a week of emails if they are not quick enough to answer (common with large timezone differences).
Also much quicker, you either get the answer or you don't, either way both are good to know (so that you know to try something else).
1. Those interleaved discussions are what makes it a worthwhile hangout for experienced users.
2. Conversely, they also mean that maybe you'll help someone else out while you're waiting.
3. It's easier to diagnose a problem in an informal back-and-forth than in the writing-for-posterity style that SO and fora encourage.
2. Conversely, they also mean that maybe you'll help someone else out while you're waiting.
3. It's easier to diagnose a problem in an informal back-and-forth than in the writing-for-posterity style that SO and fora encourage.
Chat might be ok for facilitating diagnosis, but when I'm searching for help I want an SO style answer. Bear in mind I've been doing IRC for a couple of decades, so it's not lack of experience.
Many people looking for help aren't up to asking an SO style question.
On a semi-related note - I've been browsing HN for years, and a few times I've tried to recall an article/discussion about a topic, but can't recall the right keywords to type into the search box at the bottom.
What would be great is some sort of IRC or Slack for HN where I could ask if someone recalls the article I'm thinking about, as well as general chit-chat for the community. I searched for this as well, and I think someone had tried to start up an IRC channel or even a slack, but it wasn't well populated.
Maybe there's a Discord I'm not aware of?
What would be great is some sort of IRC or Slack for HN where I could ask if someone recalls the article I'm thinking about, as well as general chit-chat for the community. I searched for this as well, and I think someone had tried to start up an IRC channel or even a slack, but it wasn't well populated.
Maybe there's a Discord I'm not aware of?
> Why not have meetings or meet up in real life rather than hiding behind a screen without any physical interaction?
Well, that's pretty hard to do if you're working remotely!
Well, that's pretty hard to do if you're working remotely!
Author here. I agree about forums and "hobbyiest communities". I had a paragraph on this in the post, and how I manage them by muting most of the channels and reading up later. Removed the paragraph for simplicity :-)
Meetings are also bad productivity killer and if you are co-located in an office you must be careful not to summon ad-hoc meetings that interrupt one participant from their deep work.
Meetings are also bad productivity killer and if you are co-located in an office you must be careful not to summon ad-hoc meetings that interrupt one participant from their deep work.
>, I believe that slack in general is a waste of time in a TEAM. Why not have meetings or meet up in real life rather than hiding behind a screen without any physical interaction?
In the book "Facebook Effect" by David Kirkpatrick[1], one programmer described how Mark Zuckerberg and the other programmers extensively chatted on AOL AIM even though they all sat at the same table elbow-to-elbow.
When one of the new programmers responded to one of MZ's chat texts by just looking up and vocalizing an answer, MZ didn't look away from his laptop to respond. Basically, the new programmer unintentionally broke the silence etiquette. The early Facebook team was using chat as virtual hallway conversations.
It seems the "correct" way to use realtime chat depends on differing personalities?
[1] there was more than one chat story in the book and this was one of them (but don't know for sure if Google Books link will show you the page excerpt): https://books.google.com/books?id=PxTvbM-VCPEC&pg=PA137&lpg=...
In the book "Facebook Effect" by David Kirkpatrick[1], one programmer described how Mark Zuckerberg and the other programmers extensively chatted on AOL AIM even though they all sat at the same table elbow-to-elbow.
When one of the new programmers responded to one of MZ's chat texts by just looking up and vocalizing an answer, MZ didn't look away from his laptop to respond. Basically, the new programmer unintentionally broke the silence etiquette. The early Facebook team was using chat as virtual hallway conversations.
It seems the "correct" way to use realtime chat depends on differing personalities?
[1] there was more than one chat story in the book and this was one of them (but don't know for sure if Google Books link will show you the page excerpt): https://books.google.com/books?id=PxTvbM-VCPEC&pg=PA137&lpg=...
Yeah. When minimizing off-topic chatter and using the chat features carefully (e.g. threads or private messages in addition to channels), chat hits a perfect balance of immediate but asynchronous coordination.
Personalities aside, chats are a track record (and searchable). Imagine remembering what your colleague asked you last Friday, and you promised to answer. Compare it with scrolling up and finding the exact question.
I'll take phone conversations to email (including a quick recap of the conversation) for precisely this reason. A searchable record of business comms can be invaluable.
Did FB really start with library rules? My understanding is it’s the opposite now, stretching the limits of construction technology to build the largest possible open office.
Open offices with library rules often work fine. The problem is more when you have no rules, at which point it's an interruption free for all.
Libraries are the ultimate open offices after all. Tons of work used to and still gets done in libraries, and they're pretty much all open tables.
Libraries are the ultimate open offices after all. Tons of work used to and still gets done in libraries, and they're pretty much all open tables.
All the more reason to have library rules.
Every in-office job I've had has been the same way. Not that we didn't ever talk in person, but so much of the normal communication happened over text, even if we were in the same room.
I'd also suggest giving Discord [0] a try. There's a few tech communities that have migrated from Slack to Discord, with one of the main benefits being that you can access and search the full history for free. It also uses fewer resources and it's overall snappier in my experience. The top example that comes to mind is Reactiflux [1], which at the time of migration I believe was one of the largest free Slack servers.
IMO, Slack can be pretty great for remote teams, although I agree you can definitely abuse it too hard and end up wasting time. One benefit of using text chat to have a discussion is that it you can easily scan through it and reference any section. There's also certain kinds of discussions which I think are easier to have through text, especially when you want to provide references and examples. It also makes it easier for introverts and non-fluent speakers to participate. On the other hand, physical discussions are hard to beat when you're whiteboarding or drawing diagrams, especially if you're still exploring the problem domain. You don't have to limit yourself to any single discussion format.
[0] https://discordapp.com/
[1] https://www.reactiflux.com/
IMO, Slack can be pretty great for remote teams, although I agree you can definitely abuse it too hard and end up wasting time. One benefit of using text chat to have a discussion is that it you can easily scan through it and reference any section. There's also certain kinds of discussions which I think are easier to have through text, especially when you want to provide references and examples. It also makes it easier for introverts and non-fluent speakers to participate. On the other hand, physical discussions are hard to beat when you're whiteboarding or drawing diagrams, especially if you're still exploring the problem domain. You don't have to limit yourself to any single discussion format.
[0] https://discordapp.com/
[1] https://www.reactiflux.com/
Slack is useful for group chat of 3-5 people. Occasionally a channel will have useful information. And then it's mostly important for coordinating lunch and sharing funny links.
I'd say it's a 50/50 on work related and just screwing around.
And sidenote I am not sure where term "ping you" came from, but it needs to go away. It honestly conveys the message I don't need to or want to talk to the person that said it.
I'd say it's a 50/50 on work related and just screwing around.
And sidenote I am not sure where term "ping you" came from, but it needs to go away. It honestly conveys the message I don't need to or want to talk to the person that said it.
> I am not sure where term "ping you" came from
I assume it's like using sports euphemisms in the office to convey a concept... this is likely a military euphemism (from radar/sonar). On one hand I don't mind it because it removes the specifics about how the person will contact you, it just simply states that they will contact you (and the method may vary depending on the time of day/week). Sure, there are other ways to say that, just as there are other ways to say something is "on deck" or you're "punting" a decision.
I assume it's like using sports euphemisms in the office to convey a concept... this is likely a military euphemism (from radar/sonar). On one hand I don't mind it because it removes the specifics about how the person will contact you, it just simply states that they will contact you (and the method may vary depending on the time of day/week). Sure, there are other ways to say that, just as there are other ways to say something is "on deck" or you're "punting" a decision.
I assumed it was from the networking 'ping'.
I kind of figured, but that terminology and specific phrasing in the tech world is obnoxious and pretentious. Just say "hey can we talk later?" No need to use to buzzword terms to ask for a simple conversation.
Honestly, I hardly acknowledge those ping requests anymore. I'm sure there is a packet loss pun, but it's late and I'm tired.
Honestly, I hardly acknowledge those ping requests anymore. I'm sure there is a packet loss pun, but it's late and I'm tired.
As did I. Actually, it never occurred to me that it could have come from anywhere else.
Right, but don't you think that was named after radar/sonar pings too?
> And sidenote I am not sure where term "ping you" came from, but it needs to go away. It honestly conveys the message I don't need to or want to talk to the person that said it.
It's weird, isn't it. We all have our triggers, I suppose.
For example, I assume anyone who explicitly qualifies only a small number of their comments with 'tbh' or 'Honestly...' is lying to me the rest of the time.
It's weird, isn't it. We all have our triggers, I suppose.
For example, I assume anyone who explicitly qualifies only a small number of their comments with 'tbh' or 'Honestly...' is lying to me the rest of the time.
My trigger is unnecessary shorthand that leads to inefective communication. Short hand can be used at times, but it should be limited and the context will make it clear. And honestly I instantly hate anyone that messages "ty" instead of actually spelling out thank you.
that seems... extreme.
People shouldn't need to look up lingo to find out what it means constantly. Plus if a person can't spend the effort to spell out thank you. It really decreases the thank you.
Doing everything in chat is pure insanity. It's great for the day-to-day collaborating on projects... but it's all short-term memory. Are you going to be referencing a chat from 3 years ago?
We use an internal forum in addition to chat. Anything substantive goes in the forum. We'll regularly reference 5 year old posts.
We use an internal forum in addition to chat. Anything substantive goes in the forum. We'll regularly reference 5 year old posts.
If you can reference 5 year old forum posts why can't you reference 3 year old chat conversations?
Structured threads vs an unending ticker tape of noise.
Why can't you have threads in a chat app?
This article is really, "We couldn't adapt our processes to Slack, so we blamed the tool and replaced a chat app with processes, because we're special snowflakes and how could anything Not Invented Here apply to our totally unique problems of communication?"
Sure, they ended up with a series of other tools to cover their workflows, the thing they "invented" was how those tools work together to cover the gaps created by not actually having a comprehensive and well-configured chat app.
This article is really, "We couldn't adapt our processes to Slack, so we blamed the tool and replaced a chat app with processes, because we're special snowflakes and how could anything Not Invented Here apply to our totally unique problems of communication?"
Sure, they ended up with a series of other tools to cover their workflows, the thing they "invented" was how those tools work together to cover the gaps created by not actually having a comprehensive and well-configured chat app.
You can, but it's not the default; you need discipline and moderators to force people to thread conversations and structure their thread starters in such a way as to optimize for searching.
IMO just use forum software if you're going that way. Much more low volume, too (generally).
IMO just use forum software if you're going that way. Much more low volume, too (generally).
You don't need moderators, just policy. Where I work we have threaded conversations and no one needs to moderate anything.
Further, "optimize for searching" isn't a thing. Teams gives full text search, and you can find any word or phrase you need to instantly.
I think you're optimizing for familiarity.
Further, "optimize for searching" isn't a thing. Teams gives full text search, and you can find any word or phrase you need to instantly.
I think you're optimizing for familiarity.
Zulip has topics and it's absolutely amazing, but I still don't think it helps reference years old messages.
You can reference years old messages.
For example https://chat.zulip.org/#narrow/stream/3-backend/topic/Vagran...
For example https://chat.zulip.org/#narrow/stream/3-backend/topic/Vagran...
I’m guessing the word “internal” has a lot to do with it.
Any recommendations for sensible forum software? (self-hosted would be ideal)
Great question, and I'm eager to hear the results. We're going to try creating a private subreddit to test the idea of forums for "long form discussions". I used vBulletin back around the early 00s, and I loved it, but I've found a number of people don't "get" forums. Discourse is something else I'd like to try.
I'm curious why people don't like forums for discussions.
I'm curious why people don't like forums for discussions.
We tried to move from vBulletin over to Discourse but it didn't work out; in comparison, Discourse is very complicated and heavy weight. I want to like it, but it's just as snappy.
Instead, we went for XenForo, made by the original vB developers. It's got just enough modern technology to make it a bit more pleasant, and it's super fast (faster than vB 3). Migrating vB to that was easy enough too (took a while, but faster than Discourse which needed three days for the basic import and then still had a million tasks to run in the background)
Instead, we went for XenForo, made by the original vB developers. It's got just enough modern technology to make it a bit more pleasant, and it's super fast (faster than vB 3). Migrating vB to that was easy enough too (took a while, but faster than Discourse which needed three days for the basic import and then still had a million tasks to run in the background)
We're working on something like subreddits - but just for your community - at https://threadbase.io
Forums rarely get things right -- that had been solved by Usenet.
Proper threading.
Read/Unread tracking.
Keyboard UI. (And the mouse UI tends to be bad as well.)
Responsiveness. (Especially: page loads which are not instantaneous.)
Killfiles.
They generally have mediocre search functions unless they are entirely visible to Google.
These are off the top of my head.
Proper threading.
Read/Unread tracking.
Keyboard UI. (And the mouse UI tends to be bad as well.)
Responsiveness. (Especially: page loads which are not instantaneous.)
Killfiles.
They generally have mediocre search functions unless they are entirely visible to Google.
These are off the top of my head.
Does usenet have points? That's what I find missing in most forums, except Reddit and HN, where best comments flow towards the top, instead of being present arbitrarily deep in the timeline.
Sorry, no native point system. You can bolt on something NoCeM-like, server or newsreader based, and enjoy distributing article reputation right now. But it supplies only a show/no show signal out of the box. I think the cancelmoose would have preferred it to be somehow more nuanced and only live in newsreaders...
http://home.httrack.net/~nocem/
https://www.systutorials.com/docs/linux/man/8-perl-nocem/
https://www.techopedia.com/definition/18172/cancelmoose
http://home.httrack.net/~nocem/
https://www.systutorials.com/docs/linux/man/8-perl-nocem/
https://www.techopedia.com/definition/18172/cancelmoose
I actually prefer having the thread with the most recent post at the top (or bottom depending on how one sorts it) of the list. That, I find is helpful in terms of keep up to date with the most recent comments. The equivalent in HN would be that the next time you load HN's front page, this particular article would appear at the top of the list and this comment (along with other new comments) would be highlighted when you load the comments section.
Thunderbird does this by default. Reddit breaks threading when sorting by "new". On HN, you have to search the comments page "minutes ago" or "hours ago" to find new comments in an existing thread.
Thunderbird does this by default. Reddit breaks threading when sorting by "new". On HN, you have to search the comments page "minutes ago" or "hours ago" to find new comments in an existing thread.
My company just started using XenForo, and we've been pretty happy with it. We're self-hosting on a cheap AWS Lightsail instance.
We really wanted to to like Dicourse, but everyone on my team found some little thing that really annoyed them ("why does it hijack ctrl-f?", etc.). It was death by a thousand cuts. XenForo is the most modern of the traditional forum platforms that I reviewed. Everyone just gets it.
We really wanted to to like Dicourse, but everyone on my team found some little thing that really annoyed them ("why does it hijack ctrl-f?", etc.). It was death by a thousand cuts. XenForo is the most modern of the traditional forum platforms that I reviewed. Everyone just gets it.
Fossil is a source control system that has, among other things, a builtin forum.
I'm convinced that tight integration between source control, issue trackers, wiki pages, and forums is a good thing. Generally you can use URLs, but that's often cumbersome.
I'm convinced that tight integration between source control, issue trackers, wiki pages, and forums is a good thing. Generally you can use URLs, but that's often cumbersome.
Depending on what exactly you are trying to do, I've found wikis like Confluence pretty good for quite a few things.
It used to have a halfway decent forum addon, and the ability to have the wiki features/content embedded was enough to convince us not to try and use a separate forum.
It used to have a halfway decent forum addon, and the ability to have the wiki features/content embedded was enough to convince us not to try and use a separate forum.
I think a good way to use Slack is to eliminate channel idea. No one has to constantly monitor a channel and that's expected.
Otherwise we know we can muted a channel but we cannot just do that to some certain channel because that's where the team annouencement happens.
Email isn't good either. Email can be easily get lost and not easy to search.
To me, Slack is super useful in 2 cases:
1. 1-1 or group chat between members on same topic 2. Archive log: I pipe all the information such as AWS activity(login, spin up server, AWS cloudtrait, Audit Log: ssh in out, K8S event...)
1. is useful to discuss on specific topics on a specificed thing.
2. is useful for on-call people to correlate with something, such as when AWS personal dashboard has issue we will know, when a server is added to autoscaling pool trigger Nginx reload, we may have trigger websocket reload and create a spike...those kind of things are very useful and easier to see compare to email to me.
Otherwise we know we can muted a channel but we cannot just do that to some certain channel because that's where the team annouencement happens.
Email isn't good either. Email can be easily get lost and not easy to search.
To me, Slack is super useful in 2 cases:
1. 1-1 or group chat between members on same topic 2. Archive log: I pipe all the information such as AWS activity(login, spin up server, AWS cloudtrait, Audit Log: ssh in out, K8S event...)
1. is useful to discuss on specific topics on a specificed thing.
2. is useful for on-call people to correlate with something, such as when AWS personal dashboard has issue we will know, when a server is added to autoscaling pool trigger Nginx reload, we may have trigger websocket reload and create a spike...those kind of things are very useful and easier to see compare to email to me.
I'm so wary of this, it has become one of my questions to interviewers - first whether, and then how, they use Slack.
So basically, the moral of the story is to talk with your team about what kind of communication scenarios are important to them. And find out if your current tools are making those scenarios better or worse.
Slack is still good for automated purposes, i.e. piping alerts and messages from a service. I don’t think I’ve ever found it useful for communicating with other people.
Slack is proprietary IRC and IRC is one of the original Internet time wasters.
We use email. Amazing how well it works for this. Who'd have thought?
Hello! One thing I'm curious about, beberlei: is your company colocated, remote, or a mix of the two?
a mix, "nearmote" :-) We all live in the same city, but everyone works remote a few hours or days per week. Also our workdays don't always match (early risers vs night owls).
I can understand the frustration with Slack but the comment about large companies using it doesn’t have much ground. I’m at a 3000+ employee company and slack works great for us. I think that one thing that has helped many people is to remember that you never have to reply immediately. Also, if you’re a stakeholder on something, then a final decision should not be made without your input. I’m sure that if you limit yourself to checking slack as much as you check your email, then it won’t be such an issue.
> ...remember that you never have to reply immediately.
Yeah, but you have to check immediately, unless you have immense willpower. And so the distraction is already made, the focus is lost, and the time spent switching contexts can't be recovered.
Yeah, but you have to check immediately, unless you have immense willpower. And so the distraction is already made, the focus is lost, and the time spent switching contexts can't be recovered.
Author here. I removed this comment after a few re-reads myself, because as you said, I don't actually have a clue about this.
How do you conclude that it 'works great' for your company?
Slack makes this very difficult and at least for me, is a primary cause of anxiety and fear of missing out
I unironically wonder how widespread this problem is among the specific group of people who blame their lack of productivity on Slack, or failing that, how many people would admit their FOMO is enhanced by chat apps.
So many of the "productivity killing" problems I hear people griping about with Slack aren't really issues with slack, but human issues with boundaries of what we allow to take our attention not being defined, and ultimately, yes: FOMO. Things are going to get missed, you're going to come in late to certain conversations, but I often wonder do you need to be on the bleeding edge of these talks if they don't directly relate to you or even reside in the periphery of your responsibility radius?
Probably not, I would wager-but tl;dr very rarely does it seem like Slack is the cause of productivity problems, it just seems the convenient scapegoat. Especially since:
"work never happens in a vacuum" (FTA) is a statement that in my opinion, cuts both ways.
I unironically wonder how widespread this problem is among the specific group of people who blame their lack of productivity on Slack, or failing that, how many people would admit their FOMO is enhanced by chat apps.
So many of the "productivity killing" problems I hear people griping about with Slack aren't really issues with slack, but human issues with boundaries of what we allow to take our attention not being defined, and ultimately, yes: FOMO. Things are going to get missed, you're going to come in late to certain conversations, but I often wonder do you need to be on the bleeding edge of these talks if they don't directly relate to you or even reside in the periphery of your responsibility radius?
Probably not, I would wager-but tl;dr very rarely does it seem like Slack is the cause of productivity problems, it just seems the convenient scapegoat. Especially since:
"work never happens in a vacuum" (FTA) is a statement that in my opinion, cuts both ways.
> So many of the "productivity killing" problems I hear people griping about with Slack aren't really issues with slack,
They're not specific to Slack, but they are specific to the existence of an official real time chat app. The boss expects you to read the chat, and if you just ignore it, you'll get in trouble and be deemed "irresponsible" if you aren't acting on it and participating in it.
They're not specific to Slack, but they are specific to the existence of an official real time chat app. The boss expects you to read the chat, and if you just ignore it, you'll get in trouble and be deemed "irresponsible" if you aren't acting on it and participating in it.
I think this implicit assumption of how to use Slack is the problem. The only thing that we expect someone to respond to on Slack is an @ or a dm. Anything else is analogous to a conversation that happened in a room you either weren't in, or had your headphones on. An @ is like someone walking over and tapping you and asking you to take your headphones off and join the conversation and a dm is like walking into your office and asking you something.
That really sounds like the worst environment to be in, where "the chat" replaces actual planning meetings where assignments are delegated out and expectations set.
Not quite sure I understand your argument. You seem to be saying Slack is a scapegoat, but say things like "Things are going to get missed, you're going to come in late to certain conversations, but I often wonder do you need to be on the bleeding edge of these talks if they don't directly relate to you or even reside in the periphery of your responsibility radius?"
I mean, you're right, you probably don't need to be on that edge, but Slack is this constant reminder of oftentimes BOTH important and unimportant issues, and they are difficult to separate so your attention is distracted regardless.
It's like saying "that endless supply of vodka in the liquor cabinet didn't make you an alcoholic." True, but if one DOES have a tendency to drink toward excess, getting rid of that liquor cabinet would be a great first step.
I mean, you're right, you probably don't need to be on that edge, but Slack is this constant reminder of oftentimes BOTH important and unimportant issues, and they are difficult to separate so your attention is distracted regardless.
It's like saying "that endless supply of vodka in the liquor cabinet didn't make you an alcoholic." True, but if one DOES have a tendency to drink toward excess, getting rid of that liquor cabinet would be a great first step.
Slack is this constant reminder of oftentimes BOTH important and unimportant issues, and they are difficult to separate so your attention is distracted regardless.
But the platform has a remedy for this does it not? In allowing you to turn on notifications for highlight words that you specify? Seems reasonable to me that if one wants to be alerted of conversations happening around certain topics, but work in peace without dings and bells for everything else, this feature works quite well in solving that split of attention between relevant and not relevant, no?
This may be an example of what I mean by boundaries; the user is completely able to define a boundary of distractions, turn them off, or turn them off but for certain highlight words so that they get notifications for, and are able to respond in a timely manner when a discussion comes up that might appreciate their input as a knowledge-holder/SME on the topic. Otherwise they continue to work unperturbed.
Is this a feature that people just don't know about or forgo using for some other reason, in your opinion?
But the platform has a remedy for this does it not? In allowing you to turn on notifications for highlight words that you specify? Seems reasonable to me that if one wants to be alerted of conversations happening around certain topics, but work in peace without dings and bells for everything else, this feature works quite well in solving that split of attention between relevant and not relevant, no?
This may be an example of what I mean by boundaries; the user is completely able to define a boundary of distractions, turn them off, or turn them off but for certain highlight words so that they get notifications for, and are able to respond in a timely manner when a discussion comes up that might appreciate their input as a knowledge-holder/SME on the topic. Otherwise they continue to work unperturbed.
Is this a feature that people just don't know about or forgo using for some other reason, in your opinion?
This feels like the "guns don't kill people, people kill people" argument.
Of course you can assign moral blame however you please, but the relevant "policy" question (in both the gun case and the slack case) is empirical.
You could measure the productivity of a single team with and without slack and see how things compare.
My guess is Slack would not fare well in that experiment, but I've never done it.
Of course you can assign moral blame however you please, but the relevant "policy" question (in both the gun case and the slack case) is empirical.
You could measure the productivity of a single team with and without slack and see how things compare.
My guess is Slack would not fare well in that experiment, but I've never done it.
Of course you can assign moral blame however you please, but the relevant "policy" question (in both the gun case and the slack case) is empirical.
You absolutely can but if there's something about my post that insinuates any sort of 'moral' blame that a comparison to the "Guns don't kill people" trope (there's probably a better word for this) is warranted, then I've massively failed to express my intent clearly. Allow me to unpack this a bit for clarity.
The logical framework for "Slack doesn't disrupt your productivity, you allow your productivity to be disrupted" is certainly there, but that's about where the comparison begins and ends to the "Guns don't kill people" argument.
What I instead mean is tools like Slack and other real-time persistent chat apps definitely exacerbate FOMO and the need to reply, respond or react in someway to a notification. Their express function is to notify, to that end they're doing what we effectively ask them to do by using them in our workplaces. Note: I'm speaking rather broadly here, I'm quite aware you very rarely have a choice in the matter when joining a new company what chat service you're stuck with using.
But as I mentioned in another comment, they have this capacity about as much as a hammer has the capacity to injure a user trying to drive nails and hang a picture.
My curiosity of how we effectively 'blame' (pretend I'm speaking with a velvet glove here when I say blame I mean it as positively and delicately as possible) Slack for breaking our concentration is with the hammer analogy in mind. Certainly it has the capacity to disrupt but just like one would probably hold and use a hammer delicately enough to avoid harming themselves but deliberately enough to drive a nail, our comms stacks can easily be wielded just as well.
(That was a bunch of words up there above, but let me raise my hand right now and admit that I am absolutely guilty of checking every notification I see come in and breaking my own flow, it's why I even hold this position).
You absolutely can but if there's something about my post that insinuates any sort of 'moral' blame that a comparison to the "Guns don't kill people" trope (there's probably a better word for this) is warranted, then I've massively failed to express my intent clearly. Allow me to unpack this a bit for clarity.
The logical framework for "Slack doesn't disrupt your productivity, you allow your productivity to be disrupted" is certainly there, but that's about where the comparison begins and ends to the "Guns don't kill people" argument.
What I instead mean is tools like Slack and other real-time persistent chat apps definitely exacerbate FOMO and the need to reply, respond or react in someway to a notification. Their express function is to notify, to that end they're doing what we effectively ask them to do by using them in our workplaces. Note: I'm speaking rather broadly here, I'm quite aware you very rarely have a choice in the matter when joining a new company what chat service you're stuck with using.
But as I mentioned in another comment, they have this capacity about as much as a hammer has the capacity to injure a user trying to drive nails and hang a picture.
My curiosity of how we effectively 'blame' (pretend I'm speaking with a velvet glove here when I say blame I mean it as positively and delicately as possible) Slack for breaking our concentration is with the hammer analogy in mind. Certainly it has the capacity to disrupt but just like one would probably hold and use a hammer delicately enough to avoid harming themselves but deliberately enough to drive a nail, our comms stacks can easily be wielded just as well.
(That was a bunch of words up there above, but let me raise my hand right now and admit that I am absolutely guilty of checking every notification I see come in and breaking my own flow, it's why I even hold this position).
> but let me raise my hand right now and admit that I am absolutely guilty of checking every notification I see come in and breaking my own flow, it's why I even hold this position
Right, so you are blaming yourself morally here (guilty of...). I'm not saying you're wrong to do so. I'm just saying that to solve the problem you can either:
1. blame yourself, and try to improve your own discipline when using slack.
2. stop using the tool that you know "tempts" you too much.
I'd rather bet on strategy 2. It's entirely analogous to throwing out all the junk food in your house when dieting. Sure, if you had the discipline you wouldn't need to do that, but so what?
Right, so you are blaming yourself morally here (guilty of...). I'm not saying you're wrong to do so. I'm just saying that to solve the problem you can either:
1. blame yourself, and try to improve your own discipline when using slack.
2. stop using the tool that you know "tempts" you too much.
I'd rather bet on strategy 2. It's entirely analogous to throwing out all the junk food in your house when dieting. Sure, if you had the discipline you wouldn't need to do that, but so what?
Author here. Working as the founder mostly alone (or relying on part time freelancers) for a long time I do have control issues that could fuel FOMO.
However how is the "Unread message" status icon, the notifications and e-mails about pings that are sent by default (Yes, you can deactivate them) not an indicator that by default Slack wants you to look into the program as often as possible. Maybe I am using it wrong, but I don't want to fight the defaults of notification overload all the time.
For example on Linux you cant even disable the system tray icon, I wrote a blog post with a hack to do this a few month ago: https://beberlei.de/2017/07/29/hide_slack_unread_and_highlig...
However how is the "Unread message" status icon, the notifications and e-mails about pings that are sent by default (Yes, you can deactivate them) not an indicator that by default Slack wants you to look into the program as often as possible. Maybe I am using it wrong, but I don't want to fight the defaults of notification overload all the time.
For example on Linux you cant even disable the system tray icon, I wrote a blog post with a hack to do this a few month ago: https://beberlei.de/2017/07/29/hide_slack_unread_and_highlig...
However how is the "Unread message" status icon, the notifications and e-mails about pings that are sent by default (Yes, you can deactivate them) not an indicator that by default Slack wants you to look into the program as often as possible.
That's a good point, I know the nagging feeling you speak of just looking at my own iPhone and some of the messages that have queued up for my attention.
I'm not sure if there is really a way to reconcile that against our FOMO tendencies that technology seems to only be exacerbating-so I will concede that point but only so much. Yes the technology exacerbates the need to check in and remain accessible even across high latency channels (like distance, time zones, etc), but IMO only in the way that gravity also exacerbates the possibility that you will smash your finger with a hammer when trying to drive a nail.
One can admit that they might smash a finger when trying to drive nails, but they would still reasonably operate the hammer in a way that minimizes smashed fingers while still using the tool for its intended and designed purpose. I propose a similar view for our communication stacks.
That's a good point, I know the nagging feeling you speak of just looking at my own iPhone and some of the messages that have queued up for my attention.
I'm not sure if there is really a way to reconcile that against our FOMO tendencies that technology seems to only be exacerbating-so I will concede that point but only so much. Yes the technology exacerbates the need to check in and remain accessible even across high latency channels (like distance, time zones, etc), but IMO only in the way that gravity also exacerbates the possibility that you will smash your finger with a hammer when trying to drive a nail.
One can admit that they might smash a finger when trying to drive nails, but they would still reasonably operate the hammer in a way that minimizes smashed fingers while still using the tool for its intended and designed purpose. I propose a similar view for our communication stacks.
> Things are going to get missed
Hit the nail on the head here. Things will get missed. The nice thing about Slack is that you can at least catch up with some conversations you missed at the end of day or in your free time. When you miss an IRL meeting, it's much harder to catch up. FOMO will be an even bigger problem when people start setting up meetings, especially ones where you aren't invited to or you can't attend because you're in another meeting.
Hit the nail on the head here. Things will get missed. The nice thing about Slack is that you can at least catch up with some conversations you missed at the end of day or in your free time. When you miss an IRL meeting, it's much harder to catch up. FOMO will be an even bigger problem when people start setting up meetings, especially ones where you aren't invited to or you can't attend because you're in another meeting.
We don't stop communicating since we unslacked though. Instead we now moved discussions more to Github PRs+issues and Basecamp. So its still possible to read up, but it feels more structured around certain tasks.
it feels more structured around certain tasks.
This might be the key to whatever becomes the big "Slack-killer", assuming one comes around: Real-time-ish chat that with respects to workflow and UI/UX are structured around action-items (be they user stories, support tickets, or deployment artifacts), easily searchable, with support for taxonomy.
This might be the key to whatever becomes the big "Slack-killer", assuming one comes around: Real-time-ish chat that with respects to workflow and UI/UX are structured around action-items (be they user stories, support tickets, or deployment artifacts), easily searchable, with support for taxonomy.
When I was at a fully local company, slack was good for conversations where a few people might be actively discussing an issue and then I could come in hours later and skim the history, if it was a channel I felt relevant to be aware of.
But slack was also super easy to use wrongly and drain so much time into. It really helped to declare slack a lossy source of comms. You shall not expect people to read it and you shall not use it as a data store. Important things go into email, wiki, tickets.
On a fully remote team, slack is so important, but all the same rules need to apply.
But slack was also super easy to use wrongly and drain so much time into. It really helped to declare slack a lossy source of comms. You shall not expect people to read it and you shall not use it as a data store. Important things go into email, wiki, tickets.
On a fully remote team, slack is so important, but all the same rules need to apply.
Almost agree, but email should also be treated as lossy.
It drives me crazy when people send mass company emails with, for example, new policy or forms attached, and don't post them elsewhere. New hires only see them if someone remembers they exist and forwards them, plus it's impossible to figure out current state without spending a bunch of time playing email archeologist.
It drives me crazy when people send mass company emails with, for example, new policy or forms attached, and don't post them elsewhere. New hires only see them if someone remembers they exist and forwards them, plus it's impossible to figure out current state without spending a bunch of time playing email archeologist.
Shameless plug here, but this is exactly why we built Carrot ( OSS / SaaS https://carrot.io/ )
We've been remote founders and employees in numerous distributed startups, and have always found the same issue, the noisy nature of chat/Slack and lossy nature of email necessitates a 3rd place to keep the important decisions, announcements and history of the company.
Lots of companies use wikis and forum software for this, and those can work, but we're betting that a dedicated solution can work better.
We've been remote founders and employees in numerous distributed startups, and have always found the same issue, the noisy nature of chat/Slack and lossy nature of email necessitates a 3rd place to keep the important decisions, announcements and history of the company.
Lots of companies use wikis and forum software for this, and those can work, but we're betting that a dedicated solution can work better.
Email is generally regarded as the most reliable in my experience.
To the parent's point, how do you get a future employee to receive the information in an email that was sent before they started?
Exchange has so-called "Public Folders" you could also access through IMAP, but it was more convenient to use and search with Outlook. Conceivably you could make a similar 'public' maibox on a different mail platform, a poor man's newsgroup.
You include it in their onboarding
So now you have to store each email that includes important information in a second place, so that you remember to include it in their onboarding. Why not just post it to the intranet in a well-known location in the first place?
Ideally the information goes where it’s supposed to in your permanent knowledge repo. This could be a wiki, a website, etc.
The email is sent as a notification that the content has been added, updated or moved.
Email should ideally serve as a notification system and a lossy communication system where things you want to retain need to be backed up somewhere else.
The nice thing wth email is that being an open eco system there are a lot of integrations that are supported easily.
The email is sent as a notification that the content has been added, updated or moved.
Email should ideally serve as a notification system and a lossy communication system where things you want to retain need to be backed up somewhere else.
The nice thing wth email is that being an open eco system there are a lot of integrations that are supported easily.
Right. But too often, as gregmac said, "people send mass company emails with, for example, new policy or forms attached, and don't post them elsewhere". Email should be used for notification and ephemeral communication, and not for information dissemination. In that way it's the same as chat.
Onboarding does not necessarily have to be email. However, let's not conflate onboarding with regular communication.
An internal NNTP server would work better in that aspect when compared to email.
I don't know, Github + Basecamp are also used by fully remote teams and they don't focus on realtime chat functionality.
Some kind of tool is necessary for sure, but different tools set a different focus to provide a solution for organization teams and companies.
I guess everyone should find what works best for them.
Some kind of tool is necessary for sure, but different tools set a different focus to provide a solution for organization teams and companies.
I guess everyone should find what works best for them.
Agreed. I'm not advocating for slack. I'm more advocating that slack isn't strictly bad like some seem to be saying. It can work. It can also be misused.
Some form of communication that's reasonable to be real-time is important. Slack is one of the better options for this.
It makes much more sense to change the expectations / culture surrounding Slack usage at a company than to drop it outright.
You can use Slack and related applications for asynchronous communication in direct messages. On the other hand, I don't want to have to wait multiple hours for a reply when I only need a quick clarification in regards to a previous e-mail.
I don't want to waste my time with e-mail, and I don't think it's a better alternative.
There is real value in Slack and programs like it, and you give that up when you only use e-mail and GitHub issues and such. This is better if you have no one working remote, but it's far from ideal. Besides, if I had an office job I could ignore Slack messages. I couldn't ignore someone walking up and interrupting me in-person.
It makes much more sense to change the expectations / culture surrounding Slack usage at a company than to drop it outright.
You can use Slack and related applications for asynchronous communication in direct messages. On the other hand, I don't want to have to wait multiple hours for a reply when I only need a quick clarification in regards to a previous e-mail.
I don't want to waste my time with e-mail, and I don't think it's a better alternative.
There is real value in Slack and programs like it, and you give that up when you only use e-mail and GitHub issues and such. This is better if you have no one working remote, but it's far from ideal. Besides, if I had an office job I could ignore Slack messages. I couldn't ignore someone walking up and interrupting me in-person.
What's wrong with the phone as a real-time communication tool?
1. I can't easily go and look back at everything that was said in a call. Notes are not a replacement for this.
2. Phone calls are too real-time, to the point where you can't manage multiple separate phone calls near the same time or do something else if a phonecall only requires some attention.
Calls have their place, but I don't think they're a replacement for written communication.
2. Phone calls are too real-time, to the point where you can't manage multiple separate phone calls near the same time or do something else if a phonecall only requires some attention.
Calls have their place, but I don't think they're a replacement for written communication.
Good luck finding out about free food in the office without Slack.
My coworkers go out of their way to tell each other, in person, about the free food.
Funny thing is free food in the office was a thing before Slack.
Email works just fine for that.
>If you wait for a long time to reply to a message on chat, then the discussion thread is already spread in the history of the chat room and messages back and forth interleaved with many additional messages that are not related is not helpful.
Use zulip - https://zulipchat.com . Opensource. Designed for threaded context.
Use zulip - https://zulipchat.com . Opensource. Designed for threaded context.
The only threaded chat I've used is Microsoft Teams, and I came away hating it.
One problem is that if you are trying to catch up on conversions, instead of just being time based, it's thread+time based, so while you can see which threads added messages while you were gone, it's not easy to actually read through them all.
The other big problem I found was people inevitably "reply" by (accidentally) creating a new thread, which then splits the conversation. If you're participating in real-time and there's not many separate conversions happening this isn't a big deal: but that's opposite to the situation where threading is actually theoretically useful, and catching up on multiple split threads is the worst combination of everything.
Maybe this is only really a problem with Microsoft's implementation, but I'm curious what other people have experienced?
One problem is that if you are trying to catch up on conversions, instead of just being time based, it's thread+time based, so while you can see which threads added messages while you were gone, it's not easy to actually read through them all.
The other big problem I found was people inevitably "reply" by (accidentally) creating a new thread, which then splits the conversation. If you're participating in real-time and there's not many separate conversions happening this isn't a big deal: but that's opposite to the situation where threading is actually theoretically useful, and catching up on multiple split threads is the worst combination of everything.
Maybe this is only really a problem with Microsoft's implementation, but I'm curious what other people have experienced?
Also enjoy Zulip for their very explicit threading system.
I mean,slack has threads, too.
Yeah. But threads in Slack are secondary and are mostly meant for having conversations that people don't care about.
Zulip has a much superior threading model. Each and every conversation is a new thread and has a topic. This model makes it extremely easier to catch up and participate in conversations.
https://zulipchat.com/why-zulip/
https://zulipchat.com/why-zulip/
They’re just a usability nightmare.
If only Slack was the only source of interruptions!
The more responsibility you gain, the more interruptions you get. I have to make a conscious effort to ignore people for a few hours in order to get into a "flow" these days.
This can lead to some friction but I can't think of another way around the problem.
The more responsibility you gain, the more interruptions you get. I have to make a conscious effort to ignore people for a few hours in order to get into a "flow" these days.
This can lead to some friction but I can't think of another way around the problem.
Even in my company with just two people I could already see us making bad Slack habits. Things that should be in email/google groups/basecamp were showing up in Slack.
I still have Slack, mainly because I like the #github channel that has all the GitHub activity, and the #industrynews channel, which has a bunch of RSS feeds of industry specific news. But those could be easily replaced with google groups/basecamp too.
Maybe I will just shut down the Slack...
I still have Slack, mainly because I like the #github channel that has all the GitHub activity, and the #industrynews channel, which has a bunch of RSS feeds of industry specific news. But those could be easily replaced with google groups/basecamp too.
Maybe I will just shut down the Slack...
Personally, I really like Slack. It's just really useful as a centralized communication place, especially since it integrates with almost every SaaS platform under the sun.
I guess it's not suitable for every team though.
I guess it's not suitable for every team though.
I guess it's not suitable for every team though.
This is the key probably. I can understand it doesn't work the way the author used it but personally I'm fairly happy with it (not to say it's the best, it's just one of the chat apps which mostly just works) and don't use all bells and whistles.
We use slack for 2 main things, 1 is chatty stuff which doesn't go to the issue tracker which has the important stuff which still needs to be there in a year (seems the OP had like everything in Slack, probably a source of problems mentioned) and due to me being a freelancer at that company it's perfectly normal I don't answer in a day or more. We learned to use it like that so no FOMO going on. The other use is as a 'dev/ci status channel' which is only viewed at passively: it gets all build info, PR/issue notifications etc which is a great overview, for us at least.
This is the key probably. I can understand it doesn't work the way the author used it but personally I'm fairly happy with it (not to say it's the best, it's just one of the chat apps which mostly just works) and don't use all bells and whistles.
We use slack for 2 main things, 1 is chatty stuff which doesn't go to the issue tracker which has the important stuff which still needs to be there in a year (seems the OP had like everything in Slack, probably a source of problems mentioned) and due to me being a freelancer at that company it's perfectly normal I don't answer in a day or more. We learned to use it like that so no FOMO going on. The other use is as a 'dev/ci status channel' which is only viewed at passively: it gets all build info, PR/issue notifications etc which is a great overview, for us at least.
I've only ever seen Slack in 1 of 2 modes:
- Dozens of people in every room having multiple conversations, and any comment you make is quickly lost in the flow of other discussions.
- Ghost town.
- Dozens of people in every room having multiple conversations, and any comment you make is quickly lost in the flow of other discussions.
- Ghost town.
We use Slack and don't have either of those environments.
I suppose we make heavy use to group DM's and project specific channels, but it really helps us keep communication streamlined and direct.
We don't really use email. If we need to ping someone on a PR review, it's done in Slack. If one of our systems is having issues, it's automated through a specific Slack channel.
I suppose we make heavy use to group DM's and project specific channels, but it really helps us keep communication streamlined and direct.
We don't really use email. If we need to ping someone on a PR review, it's done in Slack. If one of our systems is having issues, it's automated through a specific Slack channel.
How much planning, training, and other efforts does your company put into mainlining group DMs and team channels?
Check out Twist. https://twist.com
I have no affiliation with the company/team, but love the product so much that I want to share it here!
The whole idea behind Twist is to be a team communication that doesn't have the productivity issues Slack does. I think it's a very well positioned and timed product.
We've been using it for months at our startup, Canny. Threads are a useful level of organization, such that it's always easy to find what I'm looking for. However, I don't feel like I need to check it constantly.
I have no affiliation with the company/team, but love the product so much that I want to share it here!
The whole idea behind Twist is to be a team communication that doesn't have the productivity issues Slack does. I think it's a very well positioned and timed product.
We've been using it for months at our startup, Canny. Threads are a useful level of organization, such that it's always easy to find what I'm looking for. However, I don't feel like I need to check it constantly.
Author here. We tried Twist a while ago and it looked great, especially as you mentioned the Threads. But at the time had performance problems with larger threads and the REST API was very complicated to add simple posts. We didn't try it again afterwards. We use Basecamp now, and it has a forum and threads as well per team or project.
I've always thought that things ought to be thread based, much like forums today are. I'm not sure how I feel yet about how twist does their interface. I'd like to see things more like traditional forums, but incorporate Slack-like features.
In addition to the points in this article, I've also found real-time chat is much less efficient for deep discussions than email or voice. For some reason, people tend to break up their thoughts and post them as individual sentences. Maybe it's because that's similar to vocal communication - you want peoples' attention as you're speaking and sending what you want to say bit by bit is sort of like "having the floor". Or maybe it's the anxiety that the subject will change before you're done typing. But it's terribly inefficient because typing is slow and it results in people misunderstanding each other due to poorly structured writing. I find discussing significant plans/changes is much better done over email, where you get to craft your argument and make sure it reads well before you make several other people spend their time reading it.
Different teams use Slack differently, so it's kind of hard to gauge whether un-slacking works for a team.
We have a team of < 20 and Slack (and other comms tools like Hipchat which we used prior) were extremely useful and barely counter productive. There are a few channels that are noisier than others, but we do have a few important ones that are low volume where discussions do take place but are often forked into a separate discussion on another channel.
It's all about how your team uses the tool IMO and your team's organization of Slack. The key to FOMO is to not FOMO - missing out on conversations is fine (there are plenty you miss out on if everyone starts communicating and meeting offline), as long as you don't miss out on the important ones (which should be in a shared important channel).
Also, in a small company, over-communication is often more important than non-communication
We have a team of < 20 and Slack (and other comms tools like Hipchat which we used prior) were extremely useful and barely counter productive. There are a few channels that are noisier than others, but we do have a few important ones that are low volume where discussions do take place but are often forked into a separate discussion on another channel.
It's all about how your team uses the tool IMO and your team's organization of Slack. The key to FOMO is to not FOMO - missing out on conversations is fine (there are plenty you miss out on if everyone starts communicating and meeting offline), as long as you don't miss out on the important ones (which should be in a shared important channel).
Also, in a small company, over-communication is often more important than non-communication
I know everyone has their own take on why slack is bad. From the interruption factor to Electron using all their memory. For me, the issue is that it gives teams a false sense about their tech debt.
In every case I've seen, Slack slowly replaces persistent documentation. Every issue one runs into can be resolved with a quick @here to the proper channel, or a DM to the tamer of Eldritch horrors (every company has one). This reduces the incentive to eliminate footguns or properly document everything, because look at us being all collaborative and solving problems together!
The smell for this behavior is having to search Slack for that last time someone helped you solve your problem. Slack is a great way to spread information, but it's a terrible tool to organize and store information.
In every case I've seen, Slack slowly replaces persistent documentation. Every issue one runs into can be resolved with a quick @here to the proper channel, or a DM to the tamer of Eldritch horrors (every company has one). This reduces the incentive to eliminate footguns or properly document everything, because look at us being all collaborative and solving problems together!
The smell for this behavior is having to search Slack for that last time someone helped you solve your problem. Slack is a great way to spread information, but it's a terrible tool to organize and store information.
> The smell for this behavior is having to search Slack for that last time someone helped you solve your problem. Slack is a great way to spread information, but it's a terrible tool to organize and store information.
If you ever have to do this, you take it as a sign to transfer that information into a document somewhere.
If you ever have to do this, you take it as a sign to transfer that information into a document somewhere.
A good plan, for certain. In my experience very very few people follow this advice, myself definitely included.
With the fire of 1000 suns I despise Slack. Aside from the interruptions it creates (which is not exclusive to Slack admittedly) the PC version of the app is a resource hog. So is the android mobile version.
Sounds like he could have saved a whole lot of hassle just by removing some slack bots and using threads.
I don't understand why folks want less information by eliminating Slack. I've adopted Slack and 2 companies so far and find it a tremendous performance optimizer. It's a tool for passively receiving info by choice about many things, and for efficient conversations - especially with folks not sitting next to me - about specific things that are important to me.
FWIW my impressions is hatred of Slack is more a hatred of "I can't control by impulse to read everything so it's a tremendous time waster." Slack's not the problem, it's the person's self-control that's the problem in these situations.
FWIW my impressions is hatred of Slack is more a hatred of "I can't control by impulse to read everything so it's a tremendous time waster." Slack's not the problem, it's the person's self-control that's the problem in these situations.
Author here. You might be right, we could be using Slack wrong. But have you read the book "Hooked"? The author writes about Slack here: https://www.nirandfar.com/2014/11/slack.html - Slack is built to addict people to use it. I don't want to fight against that, I want to have tools that support my workflow.
Well Slack might have not worked for you. It doesn't work for everyone! Probably it works the worst for devs? Here is a story. I was working with a team of couple people located in different corners of the city. Everyone is remote except two who share an office. Up until a month ago everything was done over email. Sometimes you would send an email and get a reply in minutes, other times after hours. This was highly inefficient, to the point where I would call people to ask them to open emails... Guess what happened since we installed Slack and a couple of general open channels?
Why can't you do something else while you're waiting?
You can, but the thing is that unlike with emails, with Slack most conversation happen in public and no one has to CC you in email (or rather remember to CC you in these convos) basically slack replaces CC and BCC part of the email really well
Yes, i don't doubt that Slack works for companies. It doesn't work for our company and our value of trying to maximize uninterrupted work time.
I found the great success of Slack was reducing interruptions. It replaces things that would have otherwise been a "hard" interruption (in-person conversation or phone call) with a "softer" interruption (notification). And it provides a much better way for people who need to speak with "someone from the x team" to talk to whoever happens to be relatively free at the moment, rather than picking someone to interrupt.
(Also are you sure minimizing interruptions should be a goal? If you cut off all communications you'll avoid interruptions, but that probably won't be good for your business)
(Also are you sure minimizing interruptions should be a goal? If you cut off all communications you'll avoid interruptions, but that probably won't be good for your business)
>I have learned to be productive when I have a quiet space and can tinker on a problem without getting interrupted. Slack makes this very difficult [...]
My ultimate goal is to get longer stretches of uninterrupted time to work on features, customer support or operational issues.
A question for HN for a hypothetical feature: What if the Slack client app had "ambient awareness" such that it suppressed notifications when the active window with focus is an IDE like MS Visual Studio, JetBrains, Xcode, emacs, etc. Would that help you?
Basically, it would work similar to Slack's "Do Not Disturb" feature[1]. DND could be expanded beyond "hours" to include a list of apps that shouldn't be interrupted.
Once a programmer switches away from the code IDE to the email program, that's the point the Slack chat notifications would appear. The idea is that programmers already sort of interrupt themselves[2] but since that timing is controlled by the programmer, a Slack notification is less stressful. Thoughts?
>Since work never happens in a vacuum, I would be happy to have only a single realtime notification tool (OpsGenie/PagerDuty) that sends notifications to poeple currently on-call, and only about problems that require realtime attention.
I don't use chat apps at work these days but when I did, I put AOL AIM, Yahoo Messenger, etc inside of a virtual machine that was minimized on screen. That way, everybody saw that I was "online" but their notifications were blocked behind the vm instead of making it to my desktop's taskbar. The vm acted like a firewall. I could then look at chat messages on my own schedule at my leisure -- typically once or twice and hour. For workplaces that expect you to reply to chat messages in 5 seconds, this hack won't work.
[1] https://www.youtube.com/results?search_query=slack+do+not+di...
[2] https://xkcd.com/303/
A question for HN for a hypothetical feature: What if the Slack client app had "ambient awareness" such that it suppressed notifications when the active window with focus is an IDE like MS Visual Studio, JetBrains, Xcode, emacs, etc. Would that help you?
Basically, it would work similar to Slack's "Do Not Disturb" feature[1]. DND could be expanded beyond "hours" to include a list of apps that shouldn't be interrupted.
Once a programmer switches away from the code IDE to the email program, that's the point the Slack chat notifications would appear. The idea is that programmers already sort of interrupt themselves[2] but since that timing is controlled by the programmer, a Slack notification is less stressful. Thoughts?
>Since work never happens in a vacuum, I would be happy to have only a single realtime notification tool (OpsGenie/PagerDuty) that sends notifications to poeple currently on-call, and only about problems that require realtime attention.
I don't use chat apps at work these days but when I did, I put AOL AIM, Yahoo Messenger, etc inside of a virtual machine that was minimized on screen. That way, everybody saw that I was "online" but their notifications were blocked behind the vm instead of making it to my desktop's taskbar. The vm acted like a firewall. I could then look at chat messages on my own schedule at my leisure -- typically once or twice and hour. For workplaces that expect you to reply to chat messages in 5 seconds, this hack won't work.
[1] https://www.youtube.com/results?search_query=slack+do+not+di...
[2] https://xkcd.com/303/
I really like the idea around "ambient awareness". I'll look into it.
Currently, I've built a slack bot for personal use that integrates with my calendar where I can create stretches of times as "Focus" events and during that time, the bot helps me establish an async communication model.
The bot sets my status to "Do Not Disturb" during the event and if somebody tries to message me, they get a message that I am in heads down mode. They can then leave a note on why they were contacting me or if I they need me urgently, they can click a button and I get an immediate notification. When my focus time ends, I get a list of notes from my team on why they needed me and I can answer them one by one.
Effectively, I've found that once a team moves to Slack, all internal communication moves to Slack (instead of using slack for urgent sync and email for other async), and this brings back email like async model to Slack for the times when you need it.
You can try out the slack bot at https://slack.com/apps/A5MJB641F-oliv
In full disclosure, I've build the bot for my personal usage and don't intend to monetize it. It's just my way of giving back to the community. It's not very polished and doesn't have an onboarding flow, so if you need any help in using it, contact me at ishan.chhabra [at] gmail.com. I'll be happy to help.
Currently, I've built a slack bot for personal use that integrates with my calendar where I can create stretches of times as "Focus" events and during that time, the bot helps me establish an async communication model.
The bot sets my status to "Do Not Disturb" during the event and if somebody tries to message me, they get a message that I am in heads down mode. They can then leave a note on why they were contacting me or if I they need me urgently, they can click a button and I get an immediate notification. When my focus time ends, I get a list of notes from my team on why they needed me and I can answer them one by one.
Effectively, I've found that once a team moves to Slack, all internal communication moves to Slack (instead of using slack for urgent sync and email for other async), and this brings back email like async model to Slack for the times when you need it.
You can try out the slack bot at https://slack.com/apps/A5MJB641F-oliv
In full disclosure, I've build the bot for my personal usage and don't intend to monetize it. It's just my way of giving back to the community. It's not very polished and doesn't have an onboarding flow, so if you need any help in using it, contact me at ishan.chhabra [at] gmail.com. I'll be happy to help.
That is something I always wished Slack had. Enable DND mode and then when you return from it, a way to review a summary of everything what happened. But individual chat messages are hard to aggregate for such a summary.
I feel that many of these objections already have solutions within Slack.
If you don't want to be disturbed by notifications, there is the Do Not Disturb option to snooze notifications.
If you don't want to lose context, use Slack threads, which localize discussion around an issue to a single place.
If you have a fear of missing out because you're piping everything to Slack - have you considered segregating your alerts into specific channels and muting those you don't care about? (Alerts are a bad example, though - really, you should use Slack for a visibility record during an incident, but the only alerts you should care about should bother you with PagerDuty or OpsGenie - if they're important, they should bother you).
I do work for a larger company (some 400 employees) and we use Slack quite effectively. One thing that's really helped us is that, by consensus, we don't make decisions in Slack - everything of actual import should have a ticket to condense everything in. Slack becomes useful for us if we need immediate assistance, have questions or need to communicate in real time during an incident. It's also invaluable when you have remote employees (!).
If you don't want to be disturbed by notifications, there is the Do Not Disturb option to snooze notifications.
If you don't want to lose context, use Slack threads, which localize discussion around an issue to a single place.
If you have a fear of missing out because you're piping everything to Slack - have you considered segregating your alerts into specific channels and muting those you don't care about? (Alerts are a bad example, though - really, you should use Slack for a visibility record during an incident, but the only alerts you should care about should bother you with PagerDuty or OpsGenie - if they're important, they should bother you).
I do work for a larger company (some 400 employees) and we use Slack quite effectively. One thing that's really helped us is that, by consensus, we don't make decisions in Slack - everything of actual import should have a ticket to condense everything in. Slack becomes useful for us if we need immediate assistance, have questions or need to communicate in real time during an incident. It's also invaluable when you have remote employees (!).
> One thing that's really helped us is that, by consensus...
This is why the things that work for you don't work for others: Communication requires that all (or at least a significant majority) of parties agree to a protocol. It's not enough for a lone employee to start putting up Do Not Disturb when the culture insists on real-time responses.
I read somewhere that the crazy hours on Wall Street (purportedly 7 AM - 11 PM for new employees) are not because it takes 80 hours a week to get work done, but that there's a kind of social proof that one must demonstrate in order to be part of the "club". (Nobody's saying that you can't work 9 AM - 5 PM, they're just saying that everyone who was ever successful with the company put in the long hours, and you want to be successful, don't you?)
Similarly, it seems that Slack and other real-time communication removes some of the defenses that employees once had against these implicit demands. Note I'm not just talking about demands made by management of employees, I'm also talking about demands that employees put on themselves. (All it takes is one or two employees answering messages in the middle of the night to change people's expectations of when they'll get a response.)
As we enter an era of knowledge work, we're going to have to get better at recognizing and avoiding the social dynamics that can cause distraction and wasted time.
This is why the things that work for you don't work for others: Communication requires that all (or at least a significant majority) of parties agree to a protocol. It's not enough for a lone employee to start putting up Do Not Disturb when the culture insists on real-time responses.
I read somewhere that the crazy hours on Wall Street (purportedly 7 AM - 11 PM for new employees) are not because it takes 80 hours a week to get work done, but that there's a kind of social proof that one must demonstrate in order to be part of the "club". (Nobody's saying that you can't work 9 AM - 5 PM, they're just saying that everyone who was ever successful with the company put in the long hours, and you want to be successful, don't you?)
Similarly, it seems that Slack and other real-time communication removes some of the defenses that employees once had against these implicit demands. Note I'm not just talking about demands made by management of employees, I'm also talking about demands that employees put on themselves. (All it takes is one or two employees answering messages in the middle of the night to change people's expectations of when they'll get a response.)
As we enter an era of knowledge work, we're going to have to get better at recognizing and avoiding the social dynamics that can cause distraction and wasted time.
Rather than take a product that wants to be a chat room and adapting it in a million ways to make it not a chat room, there could be wisdom in using a product that attempts to address these issues from the ground up? We use Basecamp instead of Slack and find it infinitely better than when we used Slack, even with a ton of plug-ins and settings and hacks.
Hey, these all sound like very good hints on how to use Slack, especially the consensus on decision making. Maybe we have used Slack wrong, but especially the context was important for me and Slack threads are hard to enforce, you can "break out of the jail" easily, often by mistake.
> Slack threads are hard to enforce, you can "break out of the jail" easily, often by mistake.
In particular, image uploads (and possibly other attachments?) are always posted to the main channel, even if the message they were attached to was in a thread. Trying to conduct an image-heavy discussion -- like a discussion about a graphical design -- in a thread will just mean the main chat gets interrupted by a bunch of out-of-context images.
In particular, image uploads (and possibly other attachments?) are always posted to the main channel, even if the message they were attached to was in a thread. Trying to conduct an image-heavy discussion -- like a discussion about a graphical design -- in a thread will just mean the main chat gets interrupted by a bunch of out-of-context images.
This was improved over recent months by Slack.
This resonates with me more easily than the tone of the OP. Slack is a very good tool. For some reason, bashing it is all the rage now, but most of the criticism is misplaced and unsubstantial. FWIW, I use Slack even though I work alone, just because the integration with various 3rd parties makes it a fantastic notifications hub (which I can silence/relay/amplify at will).
Hah, but I am the op :-) I didn't want it to come out negative. I don't think my critique is unsubstantial though. Essentially we switched Slack with Basecamp, which also offers a chat part, so you can replicate the same behavior, but it also offers other means to communicate. Slack in this case was just the chat tool we used, I think the problem is with chat as primary company communication, independent of vendor.
Yeah, I wish you could migrate messages to a thread retroactively.
People enjoy vilifying Slack but like any tool what matters is how you apply it and build structure around it Replace 'Slack' with 'email', 'Skype', anything in these gripes and it all reads the same.
I agree that slack can have a place as long as there are expectations around what to use it for.
How do people coordinate around incidents without something like slack? It used to be that everyone had to hop on a conference bridge, which I personally never liked.
For important discussions and decisions, we often paste a log of a chat and a link into tickets or change requests. This helps capture the conversation and people can review and/or challenge what happened.
How do people coordinate around incidents without something like slack? It used to be that everyone had to hop on a conference bridge, which I personally never liked.
For important discussions and decisions, we often paste a log of a chat and a link into tickets or change requests. This helps capture the conversation and people can review and/or challenge what happened.
A ticket for tracking the incident (with posts to graphs, alerts, other tickets and so on - what you use slack for) + conference bridge for live discussion focused on restoring availability is what I personally like.
As long as you keep it technical and kick the salespeople out of it, the conference call is very useful tool to keep people focused on mitigating the problem ASAP instead of spending time looking for the root cause (ex: restarting the application/reverting the bad commit instead of fixing a bug, creating a new build and pushing it through).
If the issue is not killing the company you can chat about it, sure, feel free to use the tool you feel most comfortable with. If we are in a "the site is down" situation though chatting is too slow (and I always promise the SWEs I will insta-revert their last deployment when that happens until I find a good one, though I rarely do so), and talking keeps your hands free.
As long as you keep it technical and kick the salespeople out of it, the conference call is very useful tool to keep people focused on mitigating the problem ASAP instead of spending time looking for the root cause (ex: restarting the application/reverting the bad commit instead of fixing a bug, creating a new build and pushing it through).
If the issue is not killing the company you can chat about it, sure, feel free to use the tool you feel most comfortable with. If we are in a "the site is down" situation though chatting is too slow (and I always promise the SWEs I will insta-revert their last deployment when that happens until I find a good one, though I rarely do so), and talking keeps your hands free.
We use everything. We work with a lot of other companies on a very large project and every company uses something different. But, I would say most of my messages come in by Slack or Skype.
I suspect all these people who get anxious using Slack have never used IRC or similar stuff; their only experience with IM might be whatsapp, twitter DMs, etc
I find it hard to follow these kind of no-chat articles since they usually come off as a bit contrarian rather than something that makes sense:
* Why does a chat blackout naturally follow a fear of missing out?
* What's different from the good ol' IRC days? Mute the channels, see them as transient, and focus on 1on1 conversations.
* Important conversations should not be solely communicated through a short-lived channel chat, but be summarized through email or whatever.
* You're already missing out on all the 1on1 conversations you're not in.
And I write this as someone who chronically checks for slack updates.
Maybe the "fear of missing out" isn't really about missing out on important information, as I initially thought, but about missing out on participation and the inevitable social/office dynamics around that?
* Why does a chat blackout naturally follow a fear of missing out?
* What's different from the good ol' IRC days? Mute the channels, see them as transient, and focus on 1on1 conversations.
* Important conversations should not be solely communicated through a short-lived channel chat, but be summarized through email or whatever.
* You're already missing out on all the 1on1 conversations you're not in.
And I write this as someone who chronically checks for slack updates.
Maybe the "fear of missing out" isn't really about missing out on important information, as I initially thought, but about missing out on participation and the inevitable social/office dynamics around that?
Author here.
I have never used IRC in a company, so I can't compare. Slack is the topic, because we used Slack. If we have had used IRC or HipChat or Microsoft Teams, then maybe we have come to the same conclusion.
Yes, summarization is important. However switching to E-Mail causes all its problems. New colleagues don't have the mails for example. Basecamp has chat and a forum/message board or todolists. We can easily link between these.
I have never used IRC in a company, so I can't compare. Slack is the topic, because we used Slack. If we have had used IRC or HipChat or Microsoft Teams, then maybe we have come to the same conclusion.
Yes, summarization is important. However switching to E-Mail causes all its problems. New colleagues don't have the mails for example. Basecamp has chat and a forum/message board or todolists. We can easily link between these.
Personally, I find it more helpful to move the locus of control inwards and teach myself how to be productive in a diversity of circumstances. In this case, that would mean being more intentional about how I use Slack, and managing others’ expectations of their Slack messages to me. If you have a coworker who expects broad latitude to demand your undivided attention at a moment’s notice at any time, then that’s a problem that isn’t necessarily exclusive to Slack. More realistically, it’s fine if you batch Slack communications in your down moments like you would for any other communications (email).
I work remote for many years now and I never liked synchronous communication in general.
What are your alternative approaches?
What are your alternative approaches?
Our solution to this has been to keep Slack, but only for conversations that need to happen in real time.
Anything else goes into our Discourse-based internal forum.
Anything else goes into our Discourse-based internal forum.
There's a great opportunity for someone to build a team communication tool that's more forum-centric than channel-centric. Let me explain the core problem with slack (or any channel-centric chat).
When I join a wide slack channel (e.g. #Design), I'm not interested in half a dozen different threads of communication happening on it everyday. But there might be couple of discussions per week that are pertinent and important for me to do my job well. There's NO way to ignore 90% of non-pertinent conversations without actually reading all the messages on the channel (yikes!).
When I join a wide slack channel (e.g. #Design), I'm not interested in half a dozen different threads of communication happening on it everyday. But there might be couple of discussions per week that are pertinent and important for me to do my job well. There's NO way to ignore 90% of non-pertinent conversations without actually reading all the messages on the channel (yikes!).
Fwiw, I have found that GitHub/Lab issue work great. Not only do they serve as TODOs but those paper trails (so to speak) become part of the project's DNA and "documentation".
Someone new coming on board has a fairly organized point of entry, warts, bumps and all.
Someone new coming on board has a fairly organized point of entry, warts, bumps and all.
I’d love to see some hard evidence on the effectiveness of slack. I’m at least skeptical. I feel like it’s just another channel to watch. Is there any company that got rid of email and is on slack only?
> I have learned to be productive when I have a quiet space and can tinker on a problem without getting interrupted. Slack makes this very difficult.
I have personally suffered from this far too long, specially when my work has been a hybrid of maker and manager. It becomes extremely hard to create pockets of maker time.
My solution has been to schedule 2-3 hour blocks of focused time around a project (Feature X) or responsibility (customer support) once or twice a day so that at the very least, I can create focus during those times. The key is to not over do it and get hung up on scheduling every minute, but just a few hours per day like this.
To facilitate this, I've built a slack bot that integrates with my calendar and I can mark these events as "Focus" events. The bot sets my status to "Do Not Disturb" during the event and if somebody tries to message me, they get a message that I am in heads down mode. They can then leave a note on why they were contacting me or if I they need me urgently, they can click a button and I get an immediate notification. When my focus time ends, I get a list of notes from my team on why they needed me and I can answer them one by one.
Effectively, I've found that once a team moves to Slack, all internal communication moves to Slack (instead of using slack for urgent sync and email for other async), and this brings back email like async model to Slack for the times when you need it.
You can try out the slack bot at https://slack.com/apps/A5MJB641F-oliv
In full disclosure, I've build the bot for my personal usage and don't intend to monetize it. It's just my way of giving back to the community. It's not very polished and doesn't have an onboarding flow, so if you need any help in using it, contact me at ishan.chhabra [at] gmail.com. I'll be happy to help.
I have personally suffered from this far too long, specially when my work has been a hybrid of maker and manager. It becomes extremely hard to create pockets of maker time.
My solution has been to schedule 2-3 hour blocks of focused time around a project (Feature X) or responsibility (customer support) once or twice a day so that at the very least, I can create focus during those times. The key is to not over do it and get hung up on scheduling every minute, but just a few hours per day like this.
To facilitate this, I've built a slack bot that integrates with my calendar and I can mark these events as "Focus" events. The bot sets my status to "Do Not Disturb" during the event and if somebody tries to message me, they get a message that I am in heads down mode. They can then leave a note on why they were contacting me or if I they need me urgently, they can click a button and I get an immediate notification. When my focus time ends, I get a list of notes from my team on why they needed me and I can answer them one by one.
Effectively, I've found that once a team moves to Slack, all internal communication moves to Slack (instead of using slack for urgent sync and email for other async), and this brings back email like async model to Slack for the times when you need it.
You can try out the slack bot at https://slack.com/apps/A5MJB641F-oliv
In full disclosure, I've build the bot for my personal usage and don't intend to monetize it. It's just my way of giving back to the community. It's not very polished and doesn't have an onboarding flow, so if you need any help in using it, contact me at ishan.chhabra [at] gmail.com. I'll be happy to help.
This is a huge problem for the open source project I work on. New users are overwhelmed with channels to plumb, and search is not great.
I'm open to advice on how to wean our project from chat to email (probably?) Or some better platform that helps new users and developers onboard without so much static
I'm open to advice on how to wean our project from chat to email (probably?) Or some better platform that helps new users and developers onboard without so much static
After leaving slack entirely from a robotics team and a science club, our productively increased.
No longer were we going off topic wasting precious time and making everyone in the channel read every 500+ messages some people engaged in. We instead chose to make more plans during meetings and through direct chat (Messenger).
However, Slack is usefull for forums such as donkeycar.slack.com where many hobbists come in and have questions on this software/hardware project. Slack is easily accessible for anyone to ask questions and with proper use, I was pretty productive in communicating effectively across channels.
Despite this, I believe that slack in general is a waste of time in a TEAM. Why not have meetings or meet up in real life rather than hiding behind a screen without any physical interaction? Slack, however, is a great alternative for forums since there is great searching capabilities within channels and there's always someone there to help.