Slack channels are a waste of time(zulipchat.com)
zulipchat.com
Slack channels are a waste of time
https://zulipchat.com/why-zulip/
50 comments
(I lead the Zulip project.)
If you talk to people who use Zulip, they will tell you that a better information architecture actually does make a big difference for communicating effectively. See, for example:
* https://twitter.com/b0rk/status/986444234365521920
* https://www.recurse.com/blog/112-how-rc-uses-zulip
* https://news.ycombinator.com/item?id=17622987 (on the HN frontpage right now)
If you talk to people who use Zulip, they will tell you that a better information architecture actually does make a big difference for communicating effectively. See, for example:
* https://twitter.com/b0rk/status/986444234365521920
* https://www.recurse.com/blog/112-how-rc-uses-zulip
* https://news.ycombinator.com/item?id=17622987 (on the HN frontpage right now)
Slack channels are largely defined by _membership_, not necessarily by _topic_. At least in my organization (we use Slack), there is generally a channel (or channels) for each team and larger channels for the whole company.
As these channels get bigger, they inevitably split into sub channels (#myteam becomes #myteam-status, #myteam-oncall, #myteam-eng, ...). But this is clunky and can lead to a lot of confusion as to what chats should go where. Furthermore information retrieval can be cumbersome as I’ve found myself flipping through 5 chats and searching them all for a conversation.
I don’t have any experience with zulip, but it’s strategy of partitioning conversations largely aligns with how I think when I look for things on Slack: First I recall who I was talking to (channel), then I drill down and look for the thread I’m thinking of.
As these channels get bigger, they inevitably split into sub channels (#myteam becomes #myteam-status, #myteam-oncall, #myteam-eng, ...). But this is clunky and can lead to a lot of confusion as to what chats should go where. Furthermore information retrieval can be cumbersome as I’ve found myself flipping through 5 chats and searching them all for a conversation.
I don’t have any experience with zulip, but it’s strategy of partitioning conversations largely aligns with how I think when I look for things on Slack: First I recall who I was talking to (channel), then I drill down and look for the thread I’m thinking of.
| If this were an information architecture problem, it would have been solved already by Slack itself.
That is a strange/dangerous position to take. You seem to be saying that this one company's current implementation of mostly text chat is the best possible way to communicate.
| If you have a noise problem is because you have a system that pushes information to its users faster than they can consume it
I also disagree slightly here. Users don't need to consume all information that they have access to. It's okay to dismiss notifications without reading their content, if you can determine it's noise for you. But the problem with channels/room-focused chat services is that they tend to have a few fixed number of channels, and users have to scan/read through content to determine if there's any signal in there.
To me, that seems to be the core differentiator of Zulip. For example if I've been gone for a few hours or few days, I can quickly see that I can dismiss conversations in streams like Dev/lunch-ideas, but I might choose to read up on Dev/prod-outages. In most/current chat services, all that conversation would be mixed up in the same room/chat history.
EDIT: Another way to think about it is that people have conversations, but most chat services only gives you rooms. People generally only care about some of the conversations that takes place in some of the rooms, so low signal to noise ratio. Most chat services leaves it to the user to deal with that, eg make a new room per new conversation. Zulip offers another, perhaps more user-friendly way.
That is a strange/dangerous position to take. You seem to be saying that this one company's current implementation of mostly text chat is the best possible way to communicate.
| If you have a noise problem is because you have a system that pushes information to its users faster than they can consume it
I also disagree slightly here. Users don't need to consume all information that they have access to. It's okay to dismiss notifications without reading their content, if you can determine it's noise for you. But the problem with channels/room-focused chat services is that they tend to have a few fixed number of channels, and users have to scan/read through content to determine if there's any signal in there.
To me, that seems to be the core differentiator of Zulip. For example if I've been gone for a few hours or few days, I can quickly see that I can dismiss conversations in streams like Dev/lunch-ideas, but I might choose to read up on Dev/prod-outages. In most/current chat services, all that conversation would be mixed up in the same room/chat history.
EDIT: Another way to think about it is that people have conversations, but most chat services only gives you rooms. People generally only care about some of the conversations that takes place in some of the rooms, so low signal to noise ratio. Most chat services leaves it to the user to deal with that, eg make a new room per new conversation. Zulip offers another, perhaps more user-friendly way.
The reason why Slack ends up being prone to "noise" is because there's no sense of what each "sound" is about or its origin. Given the same number of messages, a Zulip-like model of putting messages in topics in channels makes it (hopefully) at least somewhat eaiser to differentiate between the sound for which you're listening and the other sounds about which you couldn't really care less.
If you have one of those voice-driven personal assistant gadgets (Echo, Google Home, etc.), try putting it between you and some other sound source (say, a TV) and give it a command. It'll probably hear you correctly, since it knows to listen in a particular direction and can differentiate between you and the TV. Now put yourself between the Echo and the TV and give the exact same command. The Echo probably won't even hear you, and if by some miracle it does, it'll get overwhelmed by all the noise coming at it. Same amount of data, but how that data is arranged matters significantly.
Same thing here. You're the Echo, the information you want is the user, and the information you don't want is the TV. Slack puts the user between the Echo and the TV, while Zulip claims to put the Echo between the user and the TV.
If you have one of those voice-driven personal assistant gadgets (Echo, Google Home, etc.), try putting it between you and some other sound source (say, a TV) and give it a command. It'll probably hear you correctly, since it knows to listen in a particular direction and can differentiate between you and the TV. Now put yourself between the Echo and the TV and give the exact same command. The Echo probably won't even hear you, and if by some miracle it does, it'll get overwhelmed by all the noise coming at it. Same amount of data, but how that data is arranged matters significantly.
Same thing here. You're the Echo, the information you want is the user, and the information you don't want is the TV. Slack puts the user between the Echo and the TV, while Zulip claims to put the Echo between the user and the TV.
They simply force threads with a short topic and provide a subchannel-like view for them.
Threads in Slack are hard to enforce (please don't write 20 "get well soon" replies in the main channel). They are hard to parse (you have to scroll past all the threads, including the "get well soon" chain). And impossible to mute without leaving a whole channel behind.
I can imagine this approach to help (but we use slack at work...)
Threads in Slack are hard to enforce (please don't write 20 "get well soon" replies in the main channel). They are hard to parse (you have to scroll past all the threads, including the "get well soon" chain). And impossible to mute without leaving a whole channel behind.
I can imagine this approach to help (but we use slack at work...)
Maybe Slack already has this feature (I haven't used it in a couple of years), but it would be great if we could personally "downvote" users that have an unsatisfactory signal:noise ratio, and their comments would fade into the background colour of the page (like HN does with downvoted comments). Or use a decreasing font size or something to show me that I consider their input less important in general. This would only apply to messages shown to me, it wouldn't impact what other users saw.
One of the problems I had with Slack was people with only a tangential relationship with the channel filling it up with irrelevant noise. Something like that would help me filter it out a bit.
One of the problems I had with Slack was people with only a tangential relationship with the channel filling it up with irrelevant noise. Something like that would help me filter it out a bit.
Well Slack is typically used for work so it's probably not a widespread problem but one thing you could do is open a #random channel so people can post all the noise there.
This was in a work environment and we had over 50 department and team-specific channels already, as well as a bunch of random noise channels. Funnily enough, it was the application developers who were the problem in this instance since they were being more of a hindrance than a help. Being able to mute them or quiet them down while I fixed their mistakes and was documenting the workarounds/solutions would have been very useful.
Perhaps it says more about that company than Slack in general though; it's the only place I've worked where Slack was used let alone considered mandatory.
Perhaps it says more about that company than Slack in general though; it's the only place I've worked where Slack was used let alone considered mandatory.
Ain't #random already a default channel? At the very least, I recall it in every Slack org of which I've ever been a member.
I would definitely like more granular filtering by user. I'm a purely remote freelancer, so I'm in a number of client Slacks, and I sign into Slack on my phone in case anything comes up I should respond to quickly when I'm AFK.
I would love to get notifications for "DMs on this Slack from the following people" (who only Slack me to joke around or with nonurgent questions I don't need to know about in the supermarket or the gym) or "@all messages in these channels except from these users" (who I don't directly work with at all but sometimes post "@all who wants lunch from the sushi place").
I would love to get notifications for "DMs on this Slack from the following people" (who only Slack me to joke around or with nonurgent questions I don't need to know about in the supermarket or the gym) or "@all messages in these channels except from these users" (who I don't directly work with at all but sometimes post "@all who wants lunch from the sushi place").
> Remote workers can’t participate
Maybe not the correct headline at least, they mean folks in other time zones. But a little sleep hacking fixes this, for me.
> Channels rapidly devolve into GIF posts
Sometimes I wish they would. I've found recent Slack orgs I'm in to be dead. And you try start a topic and no one replies for hours or days, and I sometimes delete posts out of embarrassment that I said something wrong or just boring.
Last I looked at Zulip they were using the web-app in a "native" wrapper approach to desktop clients. I wish them the best, but wish just _one_ enterprise chat competitor would take a different approach. I know the appeal and I'm a JS developer myself, but even if you have to make a Mac-only solution, there is a market for that cause nearly every small-to-medium office seems to be all Mac.
Maybe not the correct headline at least, they mean folks in other time zones. But a little sleep hacking fixes this, for me.
> Channels rapidly devolve into GIF posts
Sometimes I wish they would. I've found recent Slack orgs I'm in to be dead. And you try start a topic and no one replies for hours or days, and I sometimes delete posts out of embarrassment that I said something wrong or just boring.
Last I looked at Zulip they were using the web-app in a "native" wrapper approach to desktop clients. I wish them the best, but wish just _one_ enterprise chat competitor would take a different approach. I know the appeal and I'm a JS developer myself, but even if you have to make a Mac-only solution, there is a market for that cause nearly every small-to-medium office seems to be all Mac.
Actually Slack (and chat in general) has been a benefit for me. I'll slowly losing my hearing as I age and this habit of communicating by text messages throughout the day with my work team makes it easier for me to understand things clearly.
You do not need to read your entire slack channel history.
Personally, I simply scan for messages addressed to me with an @mention or @channel.
If there's no @mention, I load the channel, press the escape key and go on with my day.
Personally, I simply scan for messages addressed to me with an @mention or @channel.
If there's no @mention, I load the channel, press the escape key and go on with my day.
yeah the way to use slack (for distributed teams) is the same as the way you use the water cooler (for office-based teams). you only hear what you're there to hear. if someone put an audio recorder at your office cooler you'd never listen to the recording.
however, i think that's their entire point. it's actually not very useful for actual topical discussions
however, i think that's their entire point. it's actually not very useful for actual topical discussions
It depends on the work place, but for the agency I used to work at you would be working on a particular client's project on any given day and therefore you only needed to tune into one channel. But more than that, any decisions or discussions particular to a task happened in the ticket for that task, not in slack. Slack was used for short periods of quick deliberation and problem solving environments or configuration, or general state of the project type conversations. In other words if it didn't fit in a ticket it went into slack.
That worked really well for isolating slack communication to silos of attention and it solved the problem of information important to a task living in slack.
Ultimately it's not the tools fault for any of this though. It's just a bunch of chat channels. It's up to you and your company to form good policies and practices.
That worked really well for isolating slack communication to silos of attention and it solved the problem of information important to a task living in slack.
Ultimately it's not the tools fault for any of this though. It's just a bunch of chat channels. It's up to you and your company to form good policies and practices.
Maybe that would be a compelling idea: have a channel-level chat for those ephemeral conversations, where the messages disappear after a certain number of minutes/hours/days/messages (maybe configured per-channel), and then have named topics within the channels for more persistent/ongoing conversations.
Maybe Zulip already does that. Haven't tried it yet.
Maybe Zulip already does that. Haven't tried it yet.
Indeed, the only thing I actively watch are direct messages, everything else I check periodically through the "unread messages" area at the top with a quick "mark all as read".
For you and your parent comment: Shift+Esc will mark _all_ messages as read - no need to waste time going to each channel that has new messages!
> You do not need to read your entire slack channel history.
Nope. But you sure as hell search it.... comes in handy to see if something has been discussed before.
Nope. But you sure as hell search it.... comes in handy to see if something has been discussed before.
Headline is a little click-baity, but I get their point. “Streams” seems like just adding another layer of abstraction to your existing channels. For the Slacks I’m on having multiple topic-specific channels is extremely useful, and the easy way to get rid of the .gif wars is to just silo them in #random. People generally only need a small nudge to change behavior like that.
Half my time in Slack is just banter and gifs, the other half is skimming discussions that would've been a meeting otherwise. I think the time I waste chit chatting about cancels out the time I've saved from emails, meetings, briefings, and forced context switching from shoulder tapping. From a productively standpoint, it's neither a gain or loss. But the real win for Slack (but also shared with email and tickets) is the journaling aspect of chat, which is typically leaps and bounds ahead of meetings without minutes or hallway discussions.
I've also noticed that any channel that has more than ~10 active participants quickly turns off topic or impossible to follow. That I can blame on Slack's awful implementation of threading which Zulip seems to do better at.
I've also noticed that any channel that has more than ~10 active participants quickly turns off topic or impossible to follow. That I can blame on Slack's awful implementation of threading which Zulip seems to do better at.
The first problem is actually easy to fix -- make it a rule that anyone that sends unrelated gifs/makes funny banter gets to buy lunch for the others ;-) (or makes a charitable donation in proportion to the number of people -- if the users are geographically dispersed). And enforce it strictly. You'll find that your slack channel is automatically devoid of unnecessary chatter...something about having to buy lunch for colleagues brings out the miser in them :-).
They talk about threads and asynchronous flow as being key attributes that make email better than Slack. I'm sorry, but those are both possible with Slack. I've replied to old messages long after they were sent and they're often in message threads. All the problems they claim Slack has, I think email has them too. I'd rather have those problems in Slack than email. Actually, I'd rather have them in Mattermost now these days. ;)
Named threads is a cool idea, but if it makes a big difference I expect we will see it in Slack soon enough... If you build a challenger SaaS based on minor feature tweaks, you risk just doing product research for the better staffed incumbent.
> you risk just doing product research for the better staffed incumbent
Zulip is older than Slack, and it's been owned by Dropbox for years, so it's not accurate to think of them as a startup challenging Slack.
I wouldn't call it a "minor feature tweak" either...it's pretty easy to implement, but it's a design choice that Slack has decided against.
Zulip is older than Slack, and it's been owned by Dropbox for years, so it's not accurate to think of them as a startup challenging Slack.
I wouldn't call it a "minor feature tweak" either...it's pretty easy to implement, but it's a design choice that Slack has decided against.
(I work on the Zulip core team.)
> it's been owned by Dropbox for years
I want to correct this here, precisely because we haven't yet done a good job of making it clear on the web: this statement is actually a couple of years out of date.
Dropbox was very graciously helpful for the Zulip project in 2015-2016 (after acquiring the original startup in 2014). Major things include open-sourcing the code, obviously -- but then also helping those early users who'd been that startup's private beta users, who'd determinedly hung on to it for that couple of years despite the minimal support and uncertain future, migrate their data seamlessly to the hosting company set up by tabbott, one of the original startup's founders. (See https://news.ycombinator.com/item?id=17623701 today for one such user's telling.)
Digression: That is a far nicer experience than what usually happens when a startup you like using is acquired by a company that has no interest in the product! I think they deserve a lot of credit for deciding to do that.
And then since 2016, Dropbox hasn't been involved. I actually used to work there myself -- I left in order to start working on Zulip. The core team is employed by that new company (Kandra Labs): https://zulipchat.com/team/
PS: > it's pretty easy to implement
I think making a threading experience like Zulip's really work well is harder than you think. ;-) The original startup's team was stacked with engineers with systems-heavy backgrounds -- most of them colleagues of mine from Ksplice (rebootless kernel updates) and/or MIT -- and they put quite a bit of careful engineering into the architecture.
But as you say, it's also a design choice, and moving from Slack's current UX to a fully threaded one would be a radical product pivot (lots and lots of details are shaped by that choice) that it's hard to see them making.
> it's been owned by Dropbox for years
I want to correct this here, precisely because we haven't yet done a good job of making it clear on the web: this statement is actually a couple of years out of date.
Dropbox was very graciously helpful for the Zulip project in 2015-2016 (after acquiring the original startup in 2014). Major things include open-sourcing the code, obviously -- but then also helping those early users who'd been that startup's private beta users, who'd determinedly hung on to it for that couple of years despite the minimal support and uncertain future, migrate their data seamlessly to the hosting company set up by tabbott, one of the original startup's founders. (See https://news.ycombinator.com/item?id=17623701 today for one such user's telling.)
Digression: That is a far nicer experience than what usually happens when a startup you like using is acquired by a company that has no interest in the product! I think they deserve a lot of credit for deciding to do that.
And then since 2016, Dropbox hasn't been involved. I actually used to work there myself -- I left in order to start working on Zulip. The core team is employed by that new company (Kandra Labs): https://zulipchat.com/team/
PS: > it's pretty easy to implement
I think making a threading experience like Zulip's really work well is harder than you think. ;-) The original startup's team was stacked with engineers with systems-heavy backgrounds -- most of them colleagues of mine from Ksplice (rebootless kernel updates) and/or MIT -- and they put quite a bit of careful engineering into the architecture.
But as you say, it's also a design choice, and moving from Slack's current UX to a fully threaded one would be a radical product pivot (lots and lots of details are shaped by that choice) that it's hard to see them making.
> this statement is actually a couple of years out of date
This is the first I've heard of it, guess there's a lot of outdated information floating around.
> I think making a threading experience like Zulip's really work well is harder than you think.
Well this is HN, where you can build Dropbox yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem.
This is the first I've heard of it, guess there's a lot of outdated information floating around.
> I think making a threading experience like Zulip's really work well is harder than you think.
Well this is HN, where you can build Dropbox yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem.
For the record, my OP wasn't meant to dispariage hard work by the Zulip team. When one company has 100x the employees of the other, there is a lot of room for substantive work to be "easily" replicated.
My main issue is that HN loves to compare products based on UI features that stand out to front line users, especially dev, and underestimate other aspects (admin features, sales strategy, community development) that drive value for users and success for products. Without attention to these things, you can do good design and difficult engineering without the impact you're looking for.
My main issue is that HN loves to compare products based on UI features that stand out to front line users, especially dev, and underestimate other aspects (admin features, sales strategy, community development) that drive value for users and success for products. Without attention to these things, you can do good design and difficult engineering without the impact you're looking for.
We tried Zulip but it is a lot more work to use than Slack/Flowdock. I really like the Slack/Flowdock UI better. So we stopped using Zulip.
Honestly, this read so much like desperate marketing. You're making baseless claims. "Senior people rarely use Slack channels". Care to back that up with some facts please?
It takes away from everything the product is trying to do by focusing so intently on misguided flaws of the competitor product. It's like those Galaxy vs iPhone ads.
Make the product better.
It takes away from everything the product is trying to do by focusing so intently on misguided flaws of the competitor product. It's like those Galaxy vs iPhone ads.
Make the product better.
I don't understand why you're being downvoted as this is an excellent comment.
This article read like an advertisement. There's nothing wrong with advertising, but this isn't even a particularly good ad.
I'd be more likely to try whatever the heck this service is called if they talked about what they do, and focused less on calling out Slack.
The problem with ads that shoot down your competitors is that your readers are busy thinking up counterpoints when they should be learning your points.
This article read like an advertisement. There's nothing wrong with advertising, but this isn't even a particularly good ad.
I'd be more likely to try whatever the heck this service is called if they talked about what they do, and focused less on calling out Slack.
The problem with ads that shoot down your competitors is that your readers are busy thinking up counterpoints when they should be learning your points.
Some services are solutions to a problem people don’t realize they have. To tell them about the solution, you first have to convince them that they have the problem. And the problem, in this case, is something created by the UX choices made by the ecosystem of their competitors.
The first car with seat-belts had to explain in its advertising just how existing cars are dangerous, before it could explain how seatbelts fix that problem. People would start off thinking that existing cars are just fine; the ad needed first-and-foremost to make them believe that they weren’t; to foment a state of irritation or even disgust at “the way things are.”
——
Not to say it’s always a real problem, necessarily. You can convince people they have a problem whether or not they would have agreed they have a problem if they were just provided with some additional straight facts.
See: the invention of deodorant. First take something society doesn’t actually care about, even if it’s pointed out—the fact that you smell sour after a hard day’s labor—and make it into an etiquette faux pas for people to be able to notice that about you in the public sphere. Then you can sell the solution.
Admittedly, even this manipulative version of the technique can still have unintentional positive knock-on effects: public transit probably never would have been bothered with as a concept without you and the sardines around you on the train being deodorized first.
The first car with seat-belts had to explain in its advertising just how existing cars are dangerous, before it could explain how seatbelts fix that problem. People would start off thinking that existing cars are just fine; the ad needed first-and-foremost to make them believe that they weren’t; to foment a state of irritation or even disgust at “the way things are.”
——
Not to say it’s always a real problem, necessarily. You can convince people they have a problem whether or not they would have agreed they have a problem if they were just provided with some additional straight facts.
See: the invention of deodorant. First take something society doesn’t actually care about, even if it’s pointed out—the fact that you smell sour after a hard day’s labor—and make it into an etiquette faux pas for people to be able to notice that about you in the public sphere. Then you can sell the solution.
Admittedly, even this manipulative version of the technique can still have unintentional positive knock-on effects: public transit probably never would have been bothered with as a concept without you and the sardines around you on the train being deodorized first.
I don't think seat belts are a very good example of effective ads. The first ads for seat belts started showing up in the late 1950s. By 1981, only 11% of people regularly buckled up. 11% uptake on a device that will keep you from being killed after ~ 25 years isn't particularly good. Seat belt use didn't become a big deal until State Farm Insurance sued the NHTSA (and won) in 1983.
As for the rest of your post, you're right, though you can introduce a problem without devoting hundreds of repetitive words to bashing a competitor. Talk about how hard it is to use chat in remote teams, or talk about any of the other problems with chat. That will at least get people to agree.
In this ad, greater than half the content was devoted to bashing Slack. At best, that's unprofessional. At worst, it's a very poor strategy.
If I were Slack, I'd keep an eye on whatever the hell this company is called and build the feature of it catches on.
As for the rest of your post, you're right, though you can introduce a problem without devoting hundreds of repetitive words to bashing a competitor. Talk about how hard it is to use chat in remote teams, or talk about any of the other problems with chat. That will at least get people to agree.
In this ad, greater than half the content was devoted to bashing Slack. At best, that's unprofessional. At worst, it's a very poor strategy.
If I were Slack, I'd keep an eye on whatever the hell this company is called and build the feature of it catches on.
Switch to IRC, you won't regret it. Two points concerning the post. IRC is "senior-friendly" and you won't have that GIF problem as it's text-only.
What planet are you living on where you can say with a straight face that IRC is a senior-friendly thing to use?
Do people who advocate for IRC even understand what made Slack successful? Seriously. Stay relevant or you are gonna get left in the dust when the world moves on.
> GIF problem
GIFs are a feature, not a bug.
Do people who advocate for IRC even understand what made Slack successful? Seriously. Stay relevant or you are gonna get left in the dust when the world moves on.
> GIF problem
GIFs are a feature, not a bug.
GIFs are a useless feature at best, and a distraction at worst.
Don't get me wrong, I love using them, but they ain't exactly a productivity boost.
Don't get me wrong, I love using them, but they ain't exactly a productivity boost.
well lucky for you, Slack has a solution for that:
https://twitter.com/slackhq/status/565314985405206529?lang=e...
https://twitter.com/slackhq/status/565314985405206529?lang=e...
You're aggressive and vehement.
It's not me. The post uses those terms. It seems you didn't read the post.
I'm not part of your "world". Some people complain about Slack. I say IRC is better.
It's not me. The post uses those terms. It seems you didn't read the post.
I'm not part of your "world". Some people complain about Slack. I say IRC is better.
We solve this with Slack where I work by just making one-off channels that are for specific topics.
These are usually project-focused channels where we only talk about the project that we're currently working on. The channels can last anywhere from a few days to a few months, and once the project is done we close the channel.
We find this works really well to keep noise to a minimum since we still have team-specific channels where the usual noise happens, but if we're just trying to do work we only focus on the project channel.
These are usually project-focused channels where we only talk about the project that we're currently working on. The channels can last anywhere from a few days to a few months, and once the project is done we close the channel.
We find this works really well to keep noise to a minimum since we still have team-specific channels where the usual noise happens, but if we're just trying to do work we only focus on the project channel.
Sorry, but most of that is simply not true.
I worked for a large news company that moved from virtually nothing to slack. There is now something like 800 channels.
Each channel has a purpose that is distinct from each other (for example system-outage-44, or graphics-team, or aws-help)
Each team normally has a public and private channel, one to provide support, the other brisk frank discourse. Seniors are expected to contribute(in fact the members of the board are on there), and its the only way that remote workers can get real time collaberation. In fact it allowed people to work at home and feel included.
So to say its a waste of time sounds like either a marketing ploy, or an organisational problem.
I worked for a large news company that moved from virtually nothing to slack. There is now something like 800 channels.
Each channel has a purpose that is distinct from each other (for example system-outage-44, or graphics-team, or aws-help)
Each team normally has a public and private channel, one to provide support, the other brisk frank discourse. Seniors are expected to contribute(in fact the members of the board are on there), and its the only way that remote workers can get real time collaberation. In fact it allowed people to work at home and feel included.
So to say its a waste of time sounds like either a marketing ploy, or an organisational problem.
Having to sift through 800 channels to find the relevant topic sounds like a nightmare.
Our company has a similar number of channels, if not more, and you don't scan all of the channels for input. People typically subscribe to their team and related team channels as well as any topics of interest. Slack makes it easy to bring someone in just by mentioning them, so people get added to the places they didn't know about as needed.
Once you start seeing that you're subscribed to too many channels, you just leave them as they lose relevance to you. There's even a middle ground where you can mute notifications from a channel, but can still watch what's going on.
The main problem with slack is the poor search capability, and that's very relevant to your comment.
Once you start seeing that you're subscribed to too many channels, you just leave them as they lose relevance to you. There's even a middle ground where you can mute notifications from a channel, but can still watch what's going on.
The main problem with slack is the poor search capability, and that's very relevant to your comment.
I get that you can selectively subscribe to only certain channels. The problem is that now you have 800+ channel names to read in order to determine the ones to which you might want to subscribe. Sure, someone else could invite you to some new topic-oriented channel if one remembers to actually do so. More often than not, in my observation, that doesn't really happen in a timely manner (if at all).
You don't, because slack is ephemeral.
You join/are joined to a channel because its relevant to what or who you are working _now_. If you want help, then you go to #department or #thing those are the default public channels.
For example I was in a "SRE/devop/sysadmin" role, and I would be embedded in a production/feature team. So I would be part of sre-private and sre. I would also be part of #widget #widget-private and any sub feature teams.
This means that noise is neatly compartmentalised. I don't have to sift because its already in a labelled bucket.
You join/are joined to a channel because its relevant to what or who you are working _now_. If you want help, then you go to #department or #thing those are the default public channels.
For example I was in a "SRE/devop/sysadmin" role, and I would be embedded in a production/feature team. So I would be part of sre-private and sre. I would also be part of #widget #widget-private and any sub feature teams.
This means that noise is neatly compartmentalised. I don't have to sift because its already in a labelled bucket.
At work we started doing private project-specific channels for whatever initiative we're working on that's cross functional. As soon as that project is complete, we archive the channel and move on the next thing. It's worked out really well surprisingly. Our public channels rarely get activity now because their subject matter is so vague but the private channels are incredibly active and productive.
We also do this coupled with project specific Trello boards. Solved many of the signal v noise issues we had.
At the risk of sounding petty and nit-picky...
I hate it when companies start their marketing about how shitty their main competitor is. Really? You couldn't muster an elegant elevator pitch without throwing some shade first?
Granted this seems to be a 'alternative marketing' page ("Why Zulip?") that calls out Slack directly... but, then again, so does the main page of the site.
If you can't define what your product does without namedropping a popular alternative first... C'mon man.
I hate it when companies start their marketing about how shitty their main competitor is. Really? You couldn't muster an elegant elevator pitch without throwing some shade first?
Granted this seems to be a 'alternative marketing' page ("Why Zulip?") that calls out Slack directly... but, then again, so does the main page of the site.
If you can't define what your product does without namedropping a popular alternative first... C'mon man.
We adopted slack after a year of HipChat and a year of Teams. Different products little value. Most of the talks is in DM and probably full of gifs or memes. If things get complicated people talk face to face or use the phone. Meetings are still done the usual way and the gist is send over email.
I think we adopted a chat product just because everyone else does.
Only thing I really like in slack are the integrations. You can have channels for different kind of events happening in your company: sales, solved jira tickets etc. So you feel in the loop about what is happening without actually communication about it.
I think we adopted a chat product just because everyone else does.
Only thing I really like in slack are the integrations. You can have channels for different kind of events happening in your company: sales, solved jira tickets etc. So you feel in the loop about what is happening without actually communication about it.
Slack's problem is noise and that's not something you can solve easily. Trying to create new abstractions is only going to increase the cognitive load for your users. Who wants to have a hundred notification bubbles begging for attention? No one would ever catch up on anything relevant with this approach.
If you have a noise problem is because you have a system that pushes information to its users faster than they can consume it. No amount of information re-decoration or re-abstraction will solve this problem. This is also the reason why all the social media platforms eventually move away from chronological feeds and start using algorithmic feeds.
The solution is to narrow the scope of information that is useful or relevant to the users, but the paradox here is that Slack success comes from creating a product that is a solution for FOMO (Fear of Missing Out) and not a solution for keeping people informed about what matters.