Slack is the opposite of organizational memory(abe-winter.github.io)
abe-winter.github.io
Slack is the opposite of organizational memory
https://abe-winter.github.io/plea%27s/help/2018/02/11/slack.html
259 comments
> if you are a remote company, you need [to make it easier to talk to people]
From the article:
> Remote work culture is a defense mechanism against the distracting open office, and slack is the end run around that defense mechanism.
Slack kills off any benefit there is of being remote, because it is immediate: you need to be online all the time, and you need to answer / participate / chat instantly.
A good alternative to Slack would be a Reddit-like interface with threads and an asynchronous model. That's also the superiority of email over any chat solution. I don't understand why people and organizations get so excited about real-time conversations.
We always had real time. Cavemen had real time. Writing was invented to free us from real time, to transfer information in non-real time and to future generations.
But now it seems the cavemen are back, with a vengeance.
From the article:
> Remote work culture is a defense mechanism against the distracting open office, and slack is the end run around that defense mechanism.
Slack kills off any benefit there is of being remote, because it is immediate: you need to be online all the time, and you need to answer / participate / chat instantly.
A good alternative to Slack would be a Reddit-like interface with threads and an asynchronous model. That's also the superiority of email over any chat solution. I don't understand why people and organizations get so excited about real-time conversations.
We always had real time. Cavemen had real time. Writing was invented to free us from real time, to transfer information in non-real time and to future generations.
But now it seems the cavemen are back, with a vengeance.
Slightly more than half of my working days in my 19-year career have been remote. In my experience, Slack is hands-down the best tool for bridging onsite/remote. I can choose to engage with it in real-time for active participation for inevitable unplanned discussions, but there's also a historical record to reference. If the real-time chat merits "let's hop on a call" it happens then and there (in which case someone needs to be scribe, to summarize the takeaways in-channel, for
posterity).
Catching up w/ the conversation after a heads-down stretch (or vacation, whatever) is straightforward. Proper use of channels is important (ie, not just a firehose in #general) but very easy to establish, and the benefits compound.
It's not just real-time, it's real-time plus async/archival. Best of both worlds if done right.
To borrow your "cavemen" analogy: email and undocumented verbal conversations strike me as prehistoric / uncivilized, in comparison.
(That's leaving aside the benefits of having a single hub for ~everything, which Slack is ~uniquely suited for given all the integrations.)
It's not just real-time, it's real-time plus async/archival. Best of both worlds if done right.
To borrow your "cavemen" analogy: email and undocumented verbal conversations strike me as prehistoric / uncivilized, in comparison.
(That's leaving aside the benefits of having a single hub for ~everything, which Slack is ~uniquely suited for given all the integrations.)
This is an important original post, and I wish the Slack community were having these conversations more often and openly.
The original post nails some important issues: companies really need topic focused discussions, intentional, thoughtful writing, not just chat, more asynch so there is time for deep work and time for more thoughtful discussion and replies, and much better, topic-based search.
I believe in the impact of this problem so deeply that a team of us have been working on an open source solution to it for a couple years now. https://github.com/open-company
What we're trying to build is a place for companies to have focused, asynch discussions about the things that really matter, outside the stream of chat. The UI we've come up with isn't "Reddit-like" really, but it's an attempt to supplement Slack with what's missing, and it will evolve as we learn more.
If anyone is interested in trying it out, you can sign up for early access (we'll get you in very quickly) at: https://carrot.io/
The original post nails some important issues: companies really need topic focused discussions, intentional, thoughtful writing, not just chat, more asynch so there is time for deep work and time for more thoughtful discussion and replies, and much better, topic-based search.
I believe in the impact of this problem so deeply that a team of us have been working on an open source solution to it for a couple years now. https://github.com/open-company
What we're trying to build is a place for companies to have focused, asynch discussions about the things that really matter, outside the stream of chat. The UI we've come up with isn't "Reddit-like" really, but it's an attempt to supplement Slack with what's missing, and it will evolve as we learn more.
If anyone is interested in trying it out, you can sign up for early access (we'll get you in very quickly) at: https://carrot.io/
I don't see how you can ever get something named carrot out of beta (carotene). Your product looks a lot like Yammer (which we have in addition to slack, XMPP and email) in that there are threads. Threads make Yammer better than Slack but there are still two things that I hate (and that Google/Apache Wave got/gets right): 1) Comment threads are hierarchical so side conversations can happen in-line but also be out of the way. 2) Blips that I've read or that I'm not interested in can be collapsed.
The best conversations in Slack should really be a conversation in an issue tracker. Unfortunately, nobody will see those comments when they look at the issue. One issue I see with the carrot UI is that there's not really enough room to have a real conversation in the comments side-panel.
The best conversations in Slack should really be a conversation in an issue tracker. Unfortunately, nobody will see those comments when they look at the issue. One issue I see with the carrot UI is that there's not really enough room to have a real conversation in the comments side-panel.
> you need to be online all the time, and you need to answer / participate / chat instantly
When I work from home, I explain to my colleagues that I mute slack and check it once in a while. If something is really critical, they call, otherwise they'll get an answer later. If I wouldn't communicate about this, people would expect me to be online, but I communicated about this, so they understand why I'm not.
When I work from home, I explain to my colleagues that I mute slack and check it once in a while. If something is really critical, they call, otherwise they'll get an answer later. If I wouldn't communicate about this, people would expect me to be online, but I communicated about this, so they understand why I'm not.
It is an organisational question whether a chat like Slack has to be immediate. What's needed are enough channels to split social "noise" from things which need a response so that everybody has a chance to see those things, even if they are five time zones behind or deep in a debugging session. The other thing needed are non-intrusive notifications. A small icon in the notification bar is enough for me, to do a quick check when I have the capacity. (I'm always wonder how those people with big notifications popping up on each mail can work at all, ...)
>you need to be online all the time, and you need to answer / participate / chat instantly
No, you don't.
No, you don't.
They do and they make sure of it by not having any way to stop notifications.
When you open preferences, Notifications is the top pane. Literally the top notification option is "Notify me about..." and an option is Nothing. In what sense can't you stop notifications?
Well, must be new since last year.
It's not. Here's a still relevant medium post from 2014 about setting things up: https://medium.com/@shawnzvinis/how-to-get-the-most-out-of-s... .
It's fair to be frustrated by defaults or how your org uses Slack (or any other tool), but these discussions often cross the line to FUD by exaggerating annoyances.
It's fair to be frustrated by defaults or how your org uses Slack (or any other tool), but these discussions often cross the line to FUD by exaggerating annoyances.
Can you envision that it didn't work as intended and that it was missing on mobile? Thank you.
Has always been there.
Having it closed and only replying when I get a notification email for unread messages works quite well for me (if you know how to limit your email checking).
Same as donkeyd's comment I've communicated this to my clients and they've adjusted and it's a non-problem.
Seems like they let you turn off all notifications:
https://imgur.com/a/nLePu
I'm fairly sure you can set do-not-disturb times as well.
https://imgur.com/a/nLePu
I'm fairly sure you can set do-not-disturb times as well.
I only use Slack's web client and I explicitly don't give it the ability to raise desk-top notifications.
incorrect!
/dnd, per-channel notif muting, and "away" status combine for reasonably fine-grained control
/dnd, per-channel notif muting, and "away" status combine for reasonably fine-grained control
Should I use an IM to coordinate complex work, I would like to not only be away/online, but publish some schedule (if I have one) and create few tags so people could tag their messages as project-related, organisational, question, asap, etc. And their messages will be inactive until tag time, e.g. all org-related goes to lunch and all failures ring until everyone hears it. Also, to mark messages unread/todo/newtag would be helpful, since I always forget about chats that I delayed to answer. If comm system also allows to say “busy; 3 min ETA” in one click, it would be nice.
Simple group-posting is stupid – groups are muted or annoying, or induces a fear to ask questions. But the absense of group/topic alarm can also turn into inconvenience.
/never used slack, know nothing about it
Simple group-posting is stupid – groups are muted or annoying, or induces a fear to ask questions. But the absense of group/topic alarm can also turn into inconvenience.
/never used slack, know nothing about it
Great thoughts. Remote companies are async by nature, and Slack goes against that. It means that people need to be always on to get the benefits of Slack - which is silly, you'd rather focus on actual work and let people get back to you when they're ready to.
> A good alternative to Slack would be a Reddit-like interface with threads and an asynchronous model.
You're describing Twist -- twistapp.com.
> A good alternative to Slack would be a Reddit-like interface with threads and an asynchronous model.
You're describing Twist -- twistapp.com.
Surely the two can go hand in hand. Most issue trackers provide an asynchronous/threaded environment, and slack is useful if you have a real time question
one issue is that Slack _does_ try to sell itself as the repository for information. It tries to suck in Google Docs links, it has its "Files" tab, it sells its search.
It's an awesome chat application, of course. Not as much of a fan of it as a document store.
It's an awesome chat application, of course. Not as much of a fan of it as a document store.
They have those features, and (possibly) those intentions.
If I use a chainsaw to slice my morning butter, is that the chainsaw's fault?
(I haven't seen Slack identify itself as a document store; I have seen almost every company encompass that use-case. Is that Slack's fault?)
If I use a chainsaw to slice my morning butter, is that the chainsaw's fault?
(I haven't seen Slack identify itself as a document store; I have seen almost every company encompass that use-case. Is that Slack's fault?)
Well what if the chainsaw says "great for butter"?
I'm not trying to nitpick, and this might be misinterpretation, but I do feel like Slack is trying to sell itself as a Basecamp-y tool, instead of chat.
From the features page: > It helps everyone find the answers they need (some blurb about the search)
There's this ad running in trains in Tokyo for Slack which also shows this notion of Slack consuming everything that used to be e-mail attachments and whatnot + finding stuff in it (can't find a clip of this online).
Slack's own Google Drive integration exists almost purely to suck stuff into the system, for easier access.
I do think Slack has a huge potential to be powerful in this space, but it will be hard if everything has to be exposed through the lens of chat.
I'm not trying to nitpick, and this might be misinterpretation, but I do feel like Slack is trying to sell itself as a Basecamp-y tool, instead of chat.
From the features page: > It helps everyone find the answers they need (some blurb about the search)
There's this ad running in trains in Tokyo for Slack which also shows this notion of Slack consuming everything that used to be e-mail attachments and whatnot + finding stuff in it (can't find a clip of this online).
Slack's own Google Drive integration exists almost purely to suck stuff into the system, for easier access.
I do think Slack has a huge potential to be powerful in this space, but it will be hard if everything has to be exposed through the lens of chat.
one issue is that Slack _does_ try to sell itself as the repository for information
Right, wasn’t it originally Single Log of All Chat Knowledge or some acronym like that?
Right, wasn’t it originally Single Log of All Chat Knowledge or some acronym like that?
I find that Slack creates worse "accidental" documentation than some other forms of communication. Prior to my team's adoption of slack, major decisions/designs were usually documented in an email at some point, because they needed to be broadcast. If you can find that email then you have a fairly good self-contained resource for understanding whatever it was about.
Slack is easy and it's broadcast, so some people use it preferentially whenever they need to broadcast. However, the form that it takes is lines of text barfed out and interleaved with unrelated lines of text. There's no summary metadata (like subject lines), there's no organization except time, people put very little thought into what they type so it's at best rough draft form. It's hard to search, and even worse, your team or organization may be hip but cheap, and just get the free version that disappears your message history making search moot.
In short, we used to get better documentation for free, now we get none. Sometimes, old emails can be immensely useful in trying to figure out why something was done, or recovering old understanding and history.
Slack is easy and it's broadcast, so some people use it preferentially whenever they need to broadcast. However, the form that it takes is lines of text barfed out and interleaved with unrelated lines of text. There's no summary metadata (like subject lines), there's no organization except time, people put very little thought into what they type so it's at best rough draft form. It's hard to search, and even worse, your team or organization may be hip but cheap, and just get the free version that disappears your message history making search moot.
In short, we used to get better documentation for free, now we get none. Sometimes, old emails can be immensely useful in trying to figure out why something was done, or recovering old understanding and history.
How many emails just ended up going to a limited distribution list? Worse, many email systems have a retention period. (This is also a problem with Slack, mind you.)
> How many emails just ended up going to a limited distribution list? Worse, many email systems have a retention period. (This is also a problem with Slack, mind you.)
I'm not saying that email is perfect and doesn't have its issues, I'm just saying Slack is worse.
The kind of use case I was thinking of is myself and others searching through our own personal archives for stuff (which people at my company use to get around server retention policies). That works with email but not with Slack.
I'm not saying that email is perfect and doesn't have its issues, I'm just saying Slack is worse.
The kind of use case I was thinking of is myself and others searching through our own personal archives for stuff (which people at my company use to get around server retention policies). That works with email but not with Slack.
I'm very comfortable typing /mute in noisy channels and coming back later. I'm also happy to close slack when I need to be in the zone.
IMHO Don't blame the tools, it's about discipline, you need to own your time, calendar time for yourself and get stuff done. If management doesn't understand this then time to find a new team.
IMHO Don't blame the tools, it's about discipline, you need to own your time, calendar time for yourself and get stuff done. If management doesn't understand this then time to find a new team.
> it's about discipline
I've moved my teams away from "discipline" as a solution. How many times has someone said "I'll stop doing this" or "it won't happen again" and then it does?
Discipline might work for one person (usually the one making the rules), but I've found that it's impossible to get a team to be uniformly disciplined. Even if you can do it, it's extremely time/labor-intensive.
There are many tools demonstrating that discipline doesn't work, such as Chrome add-ons that block Facebook. Even when someone understands they need to be disciplined and want to be, sometimes they just can't.
Some examples of replacing discipline with hard boundaries:
- using only languages with static typing
- rejecting commits with messages less than 3 words long
- rejecting commits without tagged issue(s)
- formatters (similar to gofmt) instead of a style guide
I've moved my teams away from "discipline" as a solution. How many times has someone said "I'll stop doing this" or "it won't happen again" and then it does?
Discipline might work for one person (usually the one making the rules), but I've found that it's impossible to get a team to be uniformly disciplined. Even if you can do it, it's extremely time/labor-intensive.
There are many tools demonstrating that discipline doesn't work, such as Chrome add-ons that block Facebook. Even when someone understands they need to be disciplined and want to be, sometimes they just can't.
Some examples of replacing discipline with hard boundaries:
- using only languages with static typing
- rejecting commits with messages less than 3 words long
- rejecting commits without tagged issue(s)
- formatters (similar to gofmt) instead of a style guide
- not having a bag of goddamned Oreos in the house when you're on a diet.
"Aww, all it takes is a little discipline." Yeah or I can set myself up to succeed.
"Aww, all it takes is a little discipline." Yeah or I can set myself up to succeed.
This seems to me like an incredibly good example, and I've no idea why people would be downvoting it. The GP programming / technical examples are potentially easier for the reader to think "well sometimes I'd want to break that rule because X", whereas this example makes it obvious, and brings up "setting yourself up to succeed".
Good contribution, rdiddly.
Good contribution, rdiddly.
Thanks, yeah the point is to use discipline further upstream. Use discipline once at the outset to permanently avoid influences that require discipline over and over again.
The last couple of places that I have worked also had a number of sensible rules in place to ensure quality. E.g.
- never commit directly to master, always create a PR from a branch
- always make sure tests are green before merging
- branches should be traceable to JIRA IDs
- checklists in JIRA
- etc.
Apart from the checklists, which people tend to skip, most of it makes sense. Running everything through a pull request is a good example of something which slows down the process but which is still worthwhile IMHO.
That being said, I really dislike when too many of these constraints are enforced by the technology. In coding, like in driving a car, there are times when common sense overrides traffic rules. Sometimes, even in the best and most diligent teams, the build server turns red. In that situation you just need to quench the fire ASAP to keep it from spreading. You don't want to create a task in JIRA, you don't want to create a branch, you don't want to involve your colleagues in pull requests, and you don't want to wait for a hour for unit tests to pass. You just want to apply the simple fix or revert the commit.
And that's why I prefer moderate social pressure over some algorithm enforcing stuff. A good team will know why the rules are there, they'll be professional enough to stick to them 99% of the time, and they'll also be professional enough to break them the last 1% of the time.
Apart from the checklists, which people tend to skip, most of it makes sense. Running everything through a pull request is a good example of something which slows down the process but which is still worthwhile IMHO.
That being said, I really dislike when too many of these constraints are enforced by the technology. In coding, like in driving a car, there are times when common sense overrides traffic rules. Sometimes, even in the best and most diligent teams, the build server turns red. In that situation you just need to quench the fire ASAP to keep it from spreading. You don't want to create a task in JIRA, you don't want to create a branch, you don't want to involve your colleagues in pull requests, and you don't want to wait for a hour for unit tests to pass. You just want to apply the simple fix or revert the commit.
And that's why I prefer moderate social pressure over some algorithm enforcing stuff. A good team will know why the rules are there, they'll be professional enough to stick to them 99% of the time, and they'll also be professional enough to break them the last 1% of the time.
> * In coding, like in driving a car, there are times when common sense overrides traffic rules.*
Definitely. It's possible to override any of these things in our setup. Most of them can be overridden by the person doing the coding, but a few of them require the team leader's approval.
If the rules are overridden, it's logged in our issue-tracking system, and we can discuss whether it makes sense to keep the rule or get rid of it.
Definitely. It's possible to override any of these things in our setup. Most of them can be overridden by the person doing the coding, but a few of them require the team leader's approval.
If the rules are overridden, it's logged in our issue-tracking system, and we can discuss whether it makes sense to keep the rule or get rid of it.
> It's impossible to get a team to be uniformly disciplined.
Not if you hire veterans.
Not if you hire veterans.
My least-experienced team member has 10 years of experience. The others have 20 years of experience.
Veterans make mistakes, just like all other humans. Sometimes they're sleepy or distracted or don't have enough time to think what they're doing through.
Also, veterans are more likely to have their own ideas about how to do things, and some aren't easy to compromise with.
Either way, why should I leave it up to chance when there are automated tools that prevent mistakes before they leave someone's desk?
Veterans make mistakes, just like all other humans. Sometimes they're sleepy or distracted or don't have enough time to think what they're doing through.
Also, veterans are more likely to have their own ideas about how to do things, and some aren't easy to compromise with.
Either way, why should I leave it up to chance when there are automated tools that prevent mistakes before they leave someone's desk?
But you weren't talking about mistakes, being sleepy or distracted, or not having enough time to think through things. You also were not talking about leaving things up to chance. You were talking about discipline and I asserted that one way to get "uniformly disciplined" employees is to get employees from the other side of a thing that uniformly disciplines them, i.e. the military.
> IMHO Don't blame the tools, it's about discipline
I've been seeing this meme lately on HN. First it was "Facebook is a time sink". Now it became "If you think Facebook is a time sink that just shows you lack discipline."
No, sorry. Lack of discipline might be the explanation for your private time (Facebook). But as for Slack, you DO have to be a team player. If the entire companies uses Slack you can't just not. If people are pestering me because I'm not responding, that's not my lack of discipline.
I've been seeing this meme lately on HN. First it was "Facebook is a time sink". Now it became "If you think Facebook is a time sink that just shows you lack discipline."
No, sorry. Lack of discipline might be the explanation for your private time (Facebook). But as for Slack, you DO have to be a team player. If the entire companies uses Slack you can't just not. If people are pestering me because I'm not responding, that's not my lack of discipline.
Well, there's also organisational discipline to consider. If the company values "being a team player" (as measured by always being on Slack) over getting work done, then the organisation has a discipline problem. You don't fix such a problem by taking away Slack, some other non-productive measure of being a team player will just take it's place -- answering email at night, always answering your phone, playing enough ping pong, being in your seat at 9am sharp etc.
Figuring out the correct balance between doing directly productive work and paying the overhead tax that goes with collaboration is hard. Just like no single tool will magically fix it (hello, Jira), no tool magically destroys it.
Figuring out the correct balance between doing directly productive work and paying the overhead tax that goes with collaboration is hard. Just like no single tool will magically fix it (hello, Jira), no tool magically destroys it.
> If the company values "being a team player" (as measured by always being on Slack) over getting work done
I don't know what kind of place you work at, but being a team player isn't measured by always being on Slack.
I don't know what kind of place you work at, but being a team player isn't measured by always being on Slack.
Then I don't understand what you meant by this:
> > But as for Slack, you DO have to be a team player.
> > But as for Slack, you DO have to be a team player.
Being a team player is measured by communicating and working together. It just so happens that in some organizations communicating and working together happens on Slack.
That was the point of my original comment: in one of these organizations, the fact that I struggle to work because I have noise coming from Slack that I'm expected to respond to is NOT my lack of discipline. The person I was responding to just took a fashionable meme on HN which was originally meant for Facebook and mindlessly applied it to Slack. Not applicable.
That was the point of my original comment: in one of these organizations, the fact that I struggle to work because I have noise coming from Slack that I'm expected to respond to is NOT my lack of discipline. The person I was responding to just took a fashionable meme on HN which was originally meant for Facebook and mindlessly applied it to Slack. Not applicable.
> I have noise coming from Slack that I'm expected to respond
It's the external expectation to respond that I interpreted as "being a team player as measured by always being on Slack".
Being a team player, broadly defined, isn't incompatible with muting Slack or otherwise managing the noise, and that then comes back to the "discipline" idea. If a person don't mute Slack because they "like" the distractions, then they have a discipline problem, if the organisation doesn't let them mute Slack because a "team player" always responds in three seconds or less, they the organisation has a discipline problem.
It's the external expectation to respond that I interpreted as "being a team player as measured by always being on Slack".
Being a team player, broadly defined, isn't incompatible with muting Slack or otherwise managing the noise, and that then comes back to the "discipline" idea. If a person don't mute Slack because they "like" the distractions, then they have a discipline problem, if the organisation doesn't let them mute Slack because a "team player" always responds in three seconds or less, they the organisation has a discipline problem.
You still use Slack, but you just be disciplined about how you use it. Mute noisy channels, disable notifications, etc.
Again, Slack is just a tool. I have no problem with it, but maybe that's because I work in a company that has a healthy relationship with Slack, and I make generous use of its features to let me focus on what's relevant and interesting to me.
Again, Slack is just a tool. I have no problem with it, but maybe that's because I work in a company that has a healthy relationship with Slack, and I make generous use of its features to let me focus on what's relevant and interesting to me.
You seems to miss the point of this brilliant article. Slack is just a tool but it changes the whole mentality of the organization. You can't mute the whole organization. Please read the article and not only the title.
The article isn't brilliant, it's a sequence of unsubstantiated assertions, although ones that seem to resonate with a lot of people.
But, getting to the core of the matter:
> You can't mute the whole organization.
No, you can't. And you shouldn't. That's literally the whole point of organisations. If the particular mode of communication a given organisation uses isn't good enough, think about how to make it better instead of just brushing the whole thing off. We worked this out with phones, email and mobile phones. The discussion here is ripe with people saying "if it's important, they'll call me". Well, 20 years ago, mobile phones were given the Slack treatment because it was horrible that anyone could just call you.
Some bosses seem to reward underlings who respond to email at odd hours, yet nobody struggles to understand that it's toxic behaviour instead of writing diatribes about who we should stop using email altogether (although people did write those in the 90s). I heard of an organisation where the rumour was that some members of senior management would stalk employees' calendars to see if they were keeping busy. Good thing that organisation was able to end that kind of ridiculous Goodhart style management by ending the use of calendars!
But, getting to the core of the matter:
> You can't mute the whole organization.
No, you can't. And you shouldn't. That's literally the whole point of organisations. If the particular mode of communication a given organisation uses isn't good enough, think about how to make it better instead of just brushing the whole thing off. We worked this out with phones, email and mobile phones. The discussion here is ripe with people saying "if it's important, they'll call me". Well, 20 years ago, mobile phones were given the Slack treatment because it was horrible that anyone could just call you.
Some bosses seem to reward underlings who respond to email at odd hours, yet nobody struggles to understand that it's toxic behaviour instead of writing diatribes about who we should stop using email altogether (although people did write those in the 90s). I heard of an organisation where the rumour was that some members of senior management would stalk employees' calendars to see if they were keeping busy. Good thing that organisation was able to end that kind of ridiculous Goodhart style management by ending the use of calendars!
I disagree. My point is, that organisations that are going to have an unhealthy relationship with Slack are going to be unhealthy with another tool just as much.
Doesn't that prove slack doesn't work? What is the point of channels if the average person has to ignore them to get any work done?
Coming back later really doesn't help (at least for me). Because chats are interspersed throughout, you can't really follow/search anything.
Coming back later really doesn't help (at least for me). Because chats are interspersed throughout, you can't really follow/search anything.
At which point we basically need to resort to threaded conversations, after which it is just a matter of time until someone re-invents Google Wave.
Take a look at Zulip, if you're not already familiar with it. They nailed threaded chat in a way I haven't seen anywhere else, with the possible exception of Zephyr.
That similarity is very much not an accident - Zulip is based on Zephyr. (I forget whether that's true technically or just in terms of inspiration, but the latter is definitely true.)
Inspiration very much so, code and technology not at all. (I'm one of the Zulip developers.)
I have enough friends who've hacked on Zephyr, and they tend to get such a look of horror on their faces when talking about that protocol and codebase, that I'm pretty sure that was the right approach for us. :)
It really was/is a fantastic social product, though.
I have enough friends who've hacked on Zephyr, and they tend to get such a look of horror on their faces when talking about that protocol and codebase, that I'm pretty sure that was the right approach for us. :)
It really was/is a fantastic social product, though.
Thanks for the added info! Indeed, sounds like borrowing only ideas but not code from Zephyr was wise. :)
So this is not Zulip-specific, but I am trying to figure out what it is that they supposedly nailed about threaded chat, and getting really annoyed by the experience of it. It really highlights a number of general issues I have with the way all apps in this space try to sell themselves.
TL;DR: If you proudly state on your features page that you have "First class threading on top of everything you could want from real-time chat", then give a good explanation of what makes it first-class and why it works so well. Don't assume that everyone who visits your page has already tried out a dozen other modern chat programs and therefore is familiar with all the UI idioms. I don't know if that is arrogance or naivety, but it's wrong either way.
So my goal is a quick overview of the UI and a feeling for the UX. How it all comes together, how it flows when used. I have no interest to first install it and explore it to do so, and that would require having conversations and discussions in it, and I don't feel like convincing a bunch of friends to give this a try and make them invest time in testing it.
First, the Zulip webpage (which has a broken back-button.. great). The features page proudly opens with "First class threading on top of everything you could want from real-time chat."[0] Great, so how does that work? No explanation, it just lists all the other features - the "everything you could want" bit - without every going into detail on the conversational threading UX.
Yeah, those features all look nice, but you're not telling me why the threading is better than elsewhere.
Ok, well, if I search on YouTube for videos, I'll probably find a video of some nerd trying to convince me Zulip is better than anything else and why. Although I don't like it when companies lean on that kind of "implicit crowdsourcing", so I am already slightly annoyed.
Turns out that there isn't much on YT either.
A lightning talk by one of the devs, talking about organisational structure and culture of an open source project[1]. Great, but not what I need right now; the fifteen second overview of the UI (with an implicit "you're already familiar with this stuff" tone) does little to help me.
What else? A series on how to install Zulip[2]. No discussion about the interface itself, so same problem. The remaining search results are either promotion videos of other chat platforms, or screen captures of people complaining about bugs in the Zulip app[3]. So far, the latter are the closest thing to something informative: at least it shows the app in action, and since the narration explains what is broken, you also hear what the expected behaviour is. Still not very useful.
As a last resort, I dive into the (extensive) documentation[4]. It lists everything you might want to do with the chat ("how to set up an account", "how to edit a message") and is very extensive. That is great in itself, since it lets people find answers to these specific problems, but I am still missing a good explanation of how it all comes together.
Ok, fine, I'll dig through the docs myself and try to get a picture of the app. Clicking through it I see a lot of things that are familiar from other chat apps. But when it comes to the threading, I find only a few spread-out paragraphs somewhat explaining how Zulip organises its chats:
> Zulip is a group chat app. Its most distinctive characteristic is that conversation within an organization is divided into “streams” and further subdivided into “topics”, so that much finer-grained conversations are possible than with IRC or other chat tools. [4]
> Messages in Zulip are organized into streams and topics. Streams are similar to chatrooms, IRC channels, and email lists in that they determine who receives the message. Each conversation in a stream also has a topic, which plays the role of the subject line of an email (though topics are usually shorter, e.g. "logo" or "logo design", not "feedback on the new logo design?") in that it organizes messages into threads. [5]
> In each stream, messages are sorted by topics. Topics are specific, fine-grained subjects that fit with the overall subject of the stream that they're sent to. Topics ensure sequential messages about the same thing are threaded together, allowing for better reception for users. [6]
As far as I can tell, that's it.
COME ON! So the whole thing is that you have a conversational tree that where for each topic ("streams"), you can have one extra sub-topic ("topics")? So it's essentially just forums and subfora, but with different user interface based on chat idioms?
And I can figure this out due to previous familiarity with this kind of software. I guarantee you that this is still pretty mystifying to people less tech-savvy.
OK, so now I wonder: how to start a topic then? I see pages on how to start a stream, how about topic? There is one about editing one[7], or viewing all messages about a specific topic[8]. Nothing about starting a topic though.
There has to be one, of course, since you can't use this software without this. Dig through the docs long enough, and you'll find it under "Send a new stream message"[9]. No hint that this has anything to do with starting a new topic.
What?! Why is it called "sending a new message"? I guess that in Zulip-idioms, a new message is different from replying to another message; the latter implicitly subscribing to that particular topic. Starting a new message in a stream means defining a new topic.
So in order to figure out Zulip-logic, I must already be familiar with Zulip-logic?! WHAT THE HELL PEOPLE. You cannot expect this from new users. Just call "sending a new message" what it is: starting a new topic. Or make an alias that forwards from one page to another, like merged pages on WikiPedia, or whatever, but not this.
Zulip looks like a great app, but this is ridiculous.
More developers/designers should read https://news.ycombinator.com/item?id=6429848 and ask themselves whenever they develop/design something: "would this way of explaining intimidate the elderly, or anyone else who is less comfortable with technology than me into thinking they are too stupid to use computers?" If you're not somewhat thinking about that, you're doing it wrong.
[0] https://zulipchat.com/features/
[1] https://www.youtube.com/watch?v=lXFO2ULktEI
[2] https://www.youtube.com/watch?v=-qh55hxfGDM
[3] https://www.youtube.com/watch?v=fnXZJSRPy0A
[4] https://zulipchat.com/help/
[5] https://zulipchat.com/help/getting-started-with-zulip
[6] https://zulipchat.com/help/about-streams-and-topics
[7] https://zulipchat.com/help/change-the-topic-of-a-message
[8] https://zulipchat.com/help/view-messages-from-a-topic
[9] https://zulipchat.com/help/send-a-stream-message
TL;DR: If you proudly state on your features page that you have "First class threading on top of everything you could want from real-time chat", then give a good explanation of what makes it first-class and why it works so well. Don't assume that everyone who visits your page has already tried out a dozen other modern chat programs and therefore is familiar with all the UI idioms. I don't know if that is arrogance or naivety, but it's wrong either way.
So my goal is a quick overview of the UI and a feeling for the UX. How it all comes together, how it flows when used. I have no interest to first install it and explore it to do so, and that would require having conversations and discussions in it, and I don't feel like convincing a bunch of friends to give this a try and make them invest time in testing it.
First, the Zulip webpage (which has a broken back-button.. great). The features page proudly opens with "First class threading on top of everything you could want from real-time chat."[0] Great, so how does that work? No explanation, it just lists all the other features - the "everything you could want" bit - without every going into detail on the conversational threading UX.
Yeah, those features all look nice, but you're not telling me why the threading is better than elsewhere.
Ok, well, if I search on YouTube for videos, I'll probably find a video of some nerd trying to convince me Zulip is better than anything else and why. Although I don't like it when companies lean on that kind of "implicit crowdsourcing", so I am already slightly annoyed.
Turns out that there isn't much on YT either.
A lightning talk by one of the devs, talking about organisational structure and culture of an open source project[1]. Great, but not what I need right now; the fifteen second overview of the UI (with an implicit "you're already familiar with this stuff" tone) does little to help me.
What else? A series on how to install Zulip[2]. No discussion about the interface itself, so same problem. The remaining search results are either promotion videos of other chat platforms, or screen captures of people complaining about bugs in the Zulip app[3]. So far, the latter are the closest thing to something informative: at least it shows the app in action, and since the narration explains what is broken, you also hear what the expected behaviour is. Still not very useful.
As a last resort, I dive into the (extensive) documentation[4]. It lists everything you might want to do with the chat ("how to set up an account", "how to edit a message") and is very extensive. That is great in itself, since it lets people find answers to these specific problems, but I am still missing a good explanation of how it all comes together.
Ok, fine, I'll dig through the docs myself and try to get a picture of the app. Clicking through it I see a lot of things that are familiar from other chat apps. But when it comes to the threading, I find only a few spread-out paragraphs somewhat explaining how Zulip organises its chats:
> Zulip is a group chat app. Its most distinctive characteristic is that conversation within an organization is divided into “streams” and further subdivided into “topics”, so that much finer-grained conversations are possible than with IRC or other chat tools. [4]
> Messages in Zulip are organized into streams and topics. Streams are similar to chatrooms, IRC channels, and email lists in that they determine who receives the message. Each conversation in a stream also has a topic, which plays the role of the subject line of an email (though topics are usually shorter, e.g. "logo" or "logo design", not "feedback on the new logo design?") in that it organizes messages into threads. [5]
> In each stream, messages are sorted by topics. Topics are specific, fine-grained subjects that fit with the overall subject of the stream that they're sent to. Topics ensure sequential messages about the same thing are threaded together, allowing for better reception for users. [6]
As far as I can tell, that's it.
COME ON! So the whole thing is that you have a conversational tree that where for each topic ("streams"), you can have one extra sub-topic ("topics")? So it's essentially just forums and subfora, but with different user interface based on chat idioms?
And I can figure this out due to previous familiarity with this kind of software. I guarantee you that this is still pretty mystifying to people less tech-savvy.
OK, so now I wonder: how to start a topic then? I see pages on how to start a stream, how about topic? There is one about editing one[7], or viewing all messages about a specific topic[8]. Nothing about starting a topic though.
There has to be one, of course, since you can't use this software without this. Dig through the docs long enough, and you'll find it under "Send a new stream message"[9]. No hint that this has anything to do with starting a new topic.
What?! Why is it called "sending a new message"? I guess that in Zulip-idioms, a new message is different from replying to another message; the latter implicitly subscribing to that particular topic. Starting a new message in a stream means defining a new topic.
So in order to figure out Zulip-logic, I must already be familiar with Zulip-logic?! WHAT THE HELL PEOPLE. You cannot expect this from new users. Just call "sending a new message" what it is: starting a new topic. Or make an alias that forwards from one page to another, like merged pages on WikiPedia, or whatever, but not this.
Zulip looks like a great app, but this is ridiculous.
More developers/designers should read https://news.ycombinator.com/item?id=6429848 and ask themselves whenever they develop/design something: "would this way of explaining intimidate the elderly, or anyone else who is less comfortable with technology than me into thinking they are too stupid to use computers?" If you're not somewhat thinking about that, you're doing it wrong.
[0] https://zulipchat.com/features/
[1] https://www.youtube.com/watch?v=lXFO2ULktEI
[2] https://www.youtube.com/watch?v=-qh55hxfGDM
[3] https://www.youtube.com/watch?v=fnXZJSRPy0A
[4] https://zulipchat.com/help/
[5] https://zulipchat.com/help/getting-started-with-zulip
[6] https://zulipchat.com/help/about-streams-and-topics
[7] https://zulipchat.com/help/change-the-topic-of-a-message
[8] https://zulipchat.com/help/view-messages-from-a-topic
[9] https://zulipchat.com/help/send-a-stream-message
I'm one of the original developers of Zulip. The long comment I'm replying to is a somewhat rant-y critique of Zulip, but it's basically valid. We honestly have a hard time communicating the stream/topic paradigm, even though in some sense it's just forum/subfora.
I encourage vanderZwan and others to come to https://chat.zulip.org/# to talk to us. We're real people. We like the app we've developed, but we know it's far from perfect, and we especially know that our marketing could use some constructive feedback.
I encourage vanderZwan and others to come to https://chat.zulip.org/# to talk to us. We're real people. We like the app we've developed, but we know it's far from perfect, and we especially know that our marketing could use some constructive feedback.
No need to downplay it: it is a rant, and I knew it when I wrote it, but I wanted to get across the raw frustration that I think a lot of users feel. Plus, as I said at the beginning, it was more to illustrate a more general problem.
You have my respect for taking it in stride and listening to the critique! I already mentioned it does look like a good app, and based on skimming through that lightning talk (not to mention this reply by you), the dev community behind it looks open too.
You have my respect for taking it in stride and listening to the critique! I already mentioned it does look like a good app, and based on skimming through that lightning talk (not to mention this reply by you), the dev community behind it looks open too.
This. Day-long group chats with 20+ people is not how work gets done, IMO.
Doesn't Slack support at least one 'level' of replies? I've come back to busy channels to find replies/discussion in the right pane to earlier messages.
Last I checked, Slack actually does have threaded conversations. I'm not sure why the article claims that it doesn't.
Just to check that we are on the same page: when we say "threaded conversation", be we both mean the ability to visually group the messages in the conversation in hierarchical trees[0], right? Because I don't recall ever seeing anything like that in Slack, nor being taught how to do that. I haven't used it in quite a while though.
Even if it is there, the affordances of the UI[1] don't seem to encourage this style of conversation. There is a huge difference between something being theoretically possible for expert users, or intuitively embedded it in the mode of conversation.
Mind you, I'm not saying that hierarchical trees are a panacea. I think human conversation is much more similar to the way branching and merging works in distributed version control systems, but I can't see how one would easily make a conversational UI based on that.
[0] https://en.wikipedia.org/wiki/Conversation_threading
[1] https://en.wikipedia.org/wiki/Affordance
Even if it is there, the affordances of the UI[1] don't seem to encourage this style of conversation. There is a huge difference between something being theoretically possible for expert users, or intuitively embedded it in the mode of conversation.
Mind you, I'm not saying that hierarchical trees are a panacea. I think human conversation is much more similar to the way branching and merging works in distributed version control systems, but I can't see how one would easily make a conversational UI based on that.
[0] https://en.wikipedia.org/wiki/Conversation_threading
[1] https://en.wikipedia.org/wiki/Affordance
Here's what I'm talking about: https://slackhq.com/threaded-messaging-comes-to-slack-417ffb...
> Even if it is there, the affordances of the UI[1] don't seem to encourage this style of conversation.
I agree. I never use the feature personally.
> Even if it is there, the affordances of the UI[1] don't seem to encourage this style of conversation.
I agree. I never use the feature personally.
I think that Slack's implementation of threaded conversations is severely lacking. It's easy to miss that someone has replied to you and started a thread, and it's hard to find existing threads, you have to scroll up in history and try and find it.
Slack threads almost got me fired. Long story short: I requested leave for a couple of days, by posting in the #leave channel on the company slack, as is company policy. A week later I was sick and took a day off work, that same day my boss (who works remote to the rest of the team and was separate to my supervisor) denied my request, by posting a reply and starting a thread on slack. The next day, when I came into work, my Slack was filled with unread messages and comments. I checked my DMs, and just marked everything else as read since it was mostly people mentioning @channel. Because I only checked my DMs I missed this reply to my request for leave. I only discovered the day before I was due to leave that my request was denied, when one of my colleagues mentioned it to me. I then proceeded to go on leave, which work wasn't too pleased about. I was basically asked to resign, which I did because I was planning on leaving the company anyway.
There were a few problems caused by slack here (as well as my own failings).
Slack has too much noise. After only a day away, I was inundated with messages, and no easy way to sort the wheat from the chaff. This can be mitigated by good management and company policy. Using @channel to chat about your plans for the weekend is not appropriate use of @channel.
With email, I would've gotten a nice list of unread emails, which I could scan down and automatically delete the ones I don't care about, and I would've clearly seen the email titled "re: leave request". Slack DMs also lack any kind of subjects or threads, so it's not possible to send leave requests to a manager with a subject heading, if company policy required me to put leave requests in as a DM, it would sit in a single threaded conversation with my boss along with all my other messages.
I think that slack is a good tool if used properly and appropriately. @all or @here should be used sparingly, and for important messages. DMs shouldn't be used for anything serious. It shouldn't be company policy to have a #leave channel where you post your leave requests, where your boss can publicly second guess your requests for sick leave. It all comes down to how its used. Slack is great if I need to send a quick message to a colleague, or if I need to post a comment in a channel where a prompt reply isn't required.
Slack does try to advertise itself as an alternative to email though, which is BS. It's a tool to use beside email. It's just like how IRC didn't replace email, neither did Skype.
Slack threads almost got me fired. Long story short: I requested leave for a couple of days, by posting in the #leave channel on the company slack, as is company policy. A week later I was sick and took a day off work, that same day my boss (who works remote to the rest of the team and was separate to my supervisor) denied my request, by posting a reply and starting a thread on slack. The next day, when I came into work, my Slack was filled with unread messages and comments. I checked my DMs, and just marked everything else as read since it was mostly people mentioning @channel. Because I only checked my DMs I missed this reply to my request for leave. I only discovered the day before I was due to leave that my request was denied, when one of my colleagues mentioned it to me. I then proceeded to go on leave, which work wasn't too pleased about. I was basically asked to resign, which I did because I was planning on leaving the company anyway.
There were a few problems caused by slack here (as well as my own failings).
Slack has too much noise. After only a day away, I was inundated with messages, and no easy way to sort the wheat from the chaff. This can be mitigated by good management and company policy. Using @channel to chat about your plans for the weekend is not appropriate use of @channel.
With email, I would've gotten a nice list of unread emails, which I could scan down and automatically delete the ones I don't care about, and I would've clearly seen the email titled "re: leave request". Slack DMs also lack any kind of subjects or threads, so it's not possible to send leave requests to a manager with a subject heading, if company policy required me to put leave requests in as a DM, it would sit in a single threaded conversation with my boss along with all my other messages.
I think that slack is a good tool if used properly and appropriately. @all or @here should be used sparingly, and for important messages. DMs shouldn't be used for anything serious. It shouldn't be company policy to have a #leave channel where you post your leave requests, where your boss can publicly second guess your requests for sick leave. It all comes down to how its used. Slack is great if I need to send a quick message to a colleague, or if I need to post a comment in a channel where a prompt reply isn't required.
Slack does try to advertise itself as an alternative to email though, which is BS. It's a tool to use beside email. It's just like how IRC didn't replace email, neither did Skype.
Amazing in two ways.
First that a company would deny a vacation request. Vacation is something that you schedule with your manager, not that you ask for. It's vacation. Of course you're going. You're just letting them know when.
Second that anybody would try to have such an obvious email conversation over slack. That doesn't seem like a good use for group chat. For the reason you describe.
Good on you for escaping that place!
First that a company would deny a vacation request. Vacation is something that you schedule with your manager, not that you ask for. It's vacation. Of course you're going. You're just letting them know when.
Second that anybody would try to have such an obvious email conversation over slack. That doesn't seem like a good use for group chat. For the reason you describe.
Good on you for escaping that place!
It never struck me as good company policy to have all leave requests in a public channel visible to all company employees.
I think that this solution came about because the company had a very strong dislike of email for some reason. All support was done using Intercom.io, rather than email and all company communications were done in Slack. I don't think I sent a single email in the 2 years I worked there.
Being able to create a direct message with a topic would've been the ideal solution, which is literally what email is.
I think that this solution came about because the company had a very strong dislike of email for some reason. All support was done using Intercom.io, rather than email and all company communications were done in Slack. I don't think I sent a single email in the 2 years I worked there.
Being able to create a direct message with a topic would've been the ideal solution, which is literally what email is.
It's perfectly normal for companies to deny leave requests, especially smaller ones.
One common reason is simply boots on the ground, can't have everyone take the same day off. Deadlines, if I ask for leave in the last week before a deadline.
You might be thinking from a programming perspective but imagine your whole support team taking the same two weeks off.
There are loads of reasonable, practical, reasons to deny leave. Every company policy in the UK will usually clearly state don't book tickets, etc. until approval.
Vaguely related, here in the UK there are people who get a bad rep for being greedy by blocking off certain holiday before other people as soon as the year gets 'released' e.g. booking every Friday before a bank holiday Monday off, so no-one else can. Good managers will shut down that behaviour and tell them they can only take X of them, as it causes resentments.
One common reason is simply boots on the ground, can't have everyone take the same day off. Deadlines, if I ask for leave in the last week before a deadline.
You might be thinking from a programming perspective but imagine your whole support team taking the same two weeks off.
There are loads of reasonable, practical, reasons to deny leave. Every company policy in the UK will usually clearly state don't book tickets, etc. until approval.
Vaguely related, here in the UK there are people who get a bad rep for being greedy by blocking off certain holiday before other people as soon as the year gets 'released' e.g. booking every Friday before a bank holiday Monday off, so no-one else can. Good managers will shut down that behaviour and tell them they can only take X of them, as it causes resentments.
That proves Slack doesn't work in the same sense that it proves frictionless professional interaction doesn't work.
As in, it proves nothing except it's an ineffective product for what humans use it for. Same as we'd say if Slack wasn't around -- "is IRC really the best way for us to do this?"
No. Of course not. We don't live in a best-case world, however; the relevant question to their user base is "are we helping you more than alternatives?", and for an entrepreneurial community like HN, "what does the better solution that solves the same problem look like?"
As in, it proves nothing except it's an ineffective product for what humans use it for. Same as we'd say if Slack wasn't around -- "is IRC really the best way for us to do this?"
No. Of course not. We don't live in a best-case world, however; the relevant question to their user base is "are we helping you more than alternatives?", and for an entrepreneurial community like HN, "what does the better solution that solves the same problem look like?"
What’s the point of an office break room if people aren’t there constantly?
It still allows you to have a conversation with the people who are there, with the added benefit of people who walk in later can still see it and chime in.
It still allows you to have a conversation with the people who are there, with the added benefit of people who walk in later can still see it and chime in.
[deleted]
This. I mute all my channels except #engineering (and if it was noisy I'd mute it too). If anything is urgent, people can mention or DM me. I also turn off notifications when I'm busy.
I use Slack in exactly the same manner. That's why I created Slack extenstion that tries to solve this problem (shameless plug: qdochat.com). I think mix of asyncrhonous and syncrhonous communication is the way to go.
It's an interesting argument. When I hear it, I interpret it as "I'm too busy doing stuff to help anyone else do stuff."
The people who do this, from my experience, are also the people least likely to write tests, documentation, comments, or self-explanatory code. Then, when someone makes a mistake based on misreading this member's code, they are labeled as "incompetent."
I agree that Slack has created an interruptible culture, and I'm not a fan of that, but we have yet to make a tool that transfers knowledge without either human contact or extensive documentation. Structured distraction is the alternative - we call them meetings.
Nobody likes meetings either.
The people who do this, from my experience, are also the people least likely to write tests, documentation, comments, or self-explanatory code. Then, when someone makes a mistake based on misreading this member's code, they are labeled as "incompetent."
I agree that Slack has created an interruptible culture, and I'm not a fan of that, but we have yet to make a tool that transfers knowledge without either human contact or extensive documentation. Structured distraction is the alternative - we call them meetings.
Nobody likes meetings either.
I like how you gloss over documentation as if it’s not even a viable solution.
Documentation isn’t hard to generate. Set up a wiki so you can document things there, move your internal “how do I do X” chatter from Slack to email lists and maybe a StackExchange installation, and you end up with multiple indexable, searchable sources of long-form documentation.
Sometimes, documentation is work. So do the work. People and organizations who avoid that kind of work and say “just use Slack” end up trading 1,000 hours of interruption over 1 hour of work.
Documentation isn’t hard to generate. Set up a wiki so you can document things there, move your internal “how do I do X” chatter from Slack to email lists and maybe a StackExchange installation, and you end up with multiple indexable, searchable sources of long-form documentation.
Sometimes, documentation is work. So do the work. People and organizations who avoid that kind of work and say “just use Slack” end up trading 1,000 hours of interruption over 1 hour of work.
My personal experience is that the people willing to answer the questions on slack are also the ones who take those answers and put them in documentation so they don't have to keep answering the same questions.
My experience is also that those who don't bother to be responsive to questions aren't pained enough to write the documentation. Further, due to the blindness of expertise, they document the wrong things.
It's precisely the pain of interruption that leads to empathy and good documentation. My team, as one who sources multiple teams, does a significant amount of work in documentation precisely because we know the pain points.
I had a pain point recently when some behavior changed that broke a consumer. I could track to the change, but I couldn't tell why because this person didn't make a meaningful git commit. They didn't create a changelog that explained neither the technical changes nor the product rationale. So, off to slack, and waiting because someone was "too busy" to do any of this.
I have an idea that teams should have a "slack on call" person who rotates daily to interface with other teams. This means that one person is impacted every couple of days. It sort-of works in practice.
My experience is also that those who don't bother to be responsive to questions aren't pained enough to write the documentation. Further, due to the blindness of expertise, they document the wrong things.
It's precisely the pain of interruption that leads to empathy and good documentation. My team, as one who sources multiple teams, does a significant amount of work in documentation precisely because we know the pain points.
I had a pain point recently when some behavior changed that broke a consumer. I could track to the change, but I couldn't tell why because this person didn't make a meaningful git commit. They didn't create a changelog that explained neither the technical changes nor the product rationale. So, off to slack, and waiting because someone was "too busy" to do any of this.
I have an idea that teams should have a "slack on call" person who rotates daily to interface with other teams. This means that one person is impacted every couple of days. It sort-of works in practice.
I’m not dogmatically opposed to chat, or helping people, or anything like that, and I’ve seen much the same dynamic at play. My problem is more with the culture that arises when conversations move from email to Slack, when interrupting people becomes the preferred mechanism over RTFM, and when I can’t do a goddamn thing without a chat app pinging me because someone @here’d a channel I’m in with something I can’t help with.
Basically, I miss long-form written communication. Slack and PowerPoint are tools that destroy that.
Basically, I miss long-form written communication. Slack and PowerPoint are tools that destroy that.
>> Basically, I miss long-form written communication. Slack and PowerPoint are tools that destroy that.
Only if your business allows them to be. We use Slack with specific reasons on how it should be used, with Basecamp as the documentation/project management layer. Slack is not meant to be abused like it is in the article, and the fact that people do it like that isn't a fault of the tool.
Only if your business allows them to be. We use Slack with specific reasons on how it should be used, with Basecamp as the documentation/project management layer. Slack is not meant to be abused like it is in the article, and the fact that people do it like that isn't a fault of the tool.
That sounds really nice from an idealistic perspective, and I guess Slack's business model isn't as dependent on them focusing on "engagement" over value added, but I still worry.
The problem with Slack and PowerPoint is that they're cheap and easy and you don't necessarily have an incentive to step up from there to full written literacy.
The problem with Slack and PowerPoint is that they're cheap and easy and you don't necessarily have an incentive to step up from there to full written literacy.
>> idealistic perspective
There is nothing idealistic about it. We use them like that, all the time. It works. It isn't hard. You just instruct your managers that this is how you are going to use it, and you are judged in reviews how well you manage people and projects. If you screw it up enough, you are fired.
You treat documentation and conversation like anything else in the company - not some esoteric thing that gets in the way / assists work. The documentation itself should be subject to performance review, and in our company, it is.
We get what we incentivize. Unsurprisingly, we have good documentation and good communication throughout.
There is nothing idealistic about it. We use them like that, all the time. It works. It isn't hard. You just instruct your managers that this is how you are going to use it, and you are judged in reviews how well you manage people and projects. If you screw it up enough, you are fired.
You treat documentation and conversation like anything else in the company - not some esoteric thing that gets in the way / assists work. The documentation itself should be subject to performance review, and in our company, it is.
We get what we incentivize. Unsurprisingly, we have good documentation and good communication throughout.
You may have tried this / it may not help. We have dedicated help channels - a company-wide 'help' (for anything, but normally related to technical issues or looking for general advice on a topic where you don't know who could help), and product / team-specific help channels. There's no need to @here those channels, because there's already the intermediate-level flag of "this channel has new messages, meaning someone needs help" without going all all the way to "notify everyone".
There are enough people around that someone will take a look at the channel in the near future, and they can either answer or point you to a good person to ask, at which point you're back to non-slack-specific style comms i.e. "I want to contact person X, I can either interupt them or send them some async comms".
I probably get 1 or 0 notifications a day from channels as opposed to DMs - there's just no need to @here if you have specific channels for certain types of request.
There are enough people around that someone will take a look at the channel in the near future, and they can either answer or point you to a good person to ask, at which point you're back to non-slack-specific style comms i.e. "I want to contact person X, I can either interupt them or send them some async comms".
I probably get 1 or 0 notifications a day from channels as opposed to DMs - there's just no need to @here if you have specific channels for certain types of request.
> when interrupting people becomes the preferred mechanism over RTFM
Oh god, this is the bane of my existence. Slack, skype, even in-person. Some people will never read the docs. They will seek out people who "know" and disturb them. Earlier they would fire off an email. Now I'll get a message at 2am when I just want to get this last commit in and go to sleep.
Oh god, this is the bane of my existence. Slack, skype, even in-person. Some people will never read the docs. They will seek out people who "know" and disturb them. Earlier they would fire off an email. Now I'll get a message at 2am when I just want to get this last commit in and go to sleep.
So you may be right about responding to @soandso, or even &here. The problem isn't responding to those, it's feeling the need to constantly be reading and responding to random conversations that should have actually been a scheduled meeting with an agenda. Or worse constantly checking back for all the random hits of dopamine you get from pretending that reading random low quality comments is actually work. Working on anything but the most basic of features requires getting your head in the right place, and as such you should be expected to ignore chat for sometimes hours at a time.
Everywhere I've ever worked, "set up a wiki" has meant "create something once that nobody ever remembers the existence of"
Or, it accumulates so much cruft that it's hard to find the valuable information. I think there's room for documentation librarians, whether by role or job title, but it's hard to justify the expense in smaller organizations.
I found that a bit of scripting will make a wiki a bit more maintainable. Replace pages that are out of date with a tag of some sort (e.g. #outdated). Have a script spider the wiki from the home page and send out an email with all the reachable pages with tags. Either fix the page or make sure it’s no longer reachable.
Pro librarian work right here, Nice work!
It's a trained skill - everyone can be a librarian in the team.
One person needs to lead the standards and the organization or the conflicting opinions will drive it apart. The librarian is a role, but that doesn't absolve the rest of the team from following the librarian's lead.
In my experience, documentation stored in source control alongside the code gets updated and maintained. Documentation stored in a wiki is left to rot.
For code documentation, that's definitely true, but you need places to document processes, designs, and other things like that.
Out of sight out of mind is one component of this. The other is how easily you find the documentation. Most people are willing to document if it's easy to do so, and most people will read the docs if they're easy to find.
Everywhere I've worked with wiki, I found that people actually read the wiki and that it contained both important guides for new users/developers/maintainers and old documentation that was crucial for old systems.
The last three corporate wikis that I have worked with have tended to contain some very useful and well maintained sections detailing stuff like developer machine setup and tooling.
They have also contained large amounts of information from separate projects, none of it which was relevant to my task at hand, and on top of that they have contained a wasteland of obsolete pages, the contents of which was trusted by no one.
I don't have a problem with the concept of a Wiki per se but I do have issues with treating them as a magical virtual haystack on top of which you can shovel information and from the midst of which you can painlessly extract needles.
They have also contained large amounts of information from separate projects, none of it which was relevant to my task at hand, and on top of that they have contained a wasteland of obsolete pages, the contents of which was trusted by no one.
I don't have a problem with the concept of a Wiki per se but I do have issues with treating them as a magical virtual haystack on top of which you can shovel information and from the midst of which you can painlessly extract needles.
I swear there's a startup in there... I have some ideas to combat it. It will probably rattle in my brain for another year until someone has already come up with a "good enough" solution and I'll lament that I didn't go for it.
(Life circumstances have me away from the startup life at the moment.)
(Life circumstances have me away from the startup life at the moment.)
I think that if search worked, the Wiki could be a great hub of information.
For the search to work, it should make an effort to get to know you, that is, try to track which pages you have previously edited or opened, or maybe it could access information about which project you are currently assigned to in JIRA or which internal repositories you have recently committed to in git. Also, which pages are popular, which pages are mainteined, etc. This would enable its search engine to filter bubble you and provide far better results that I currently see Confluence doing.
Further, it should be able to contain pages which are just indexed mirrors of other resources. Some pages could be simply uneditable mirrors of markdown files in your repository, making it possible for developers to keep documentation alongside the code if this makes more sense to them. Other pages could be mirrors of Word documents or Excel sheets of PDF files on shared drives or where the company likes to keep this stuff. All of this stuff would be thoroughly indexed by the wiki and would show up in search results.
So I guess what I'm proposing is that wikis become an aggregator of information more than a single store of information. And that they really, really nail the search part.
For the search to work, it should make an effort to get to know you, that is, try to track which pages you have previously edited or opened, or maybe it could access information about which project you are currently assigned to in JIRA or which internal repositories you have recently committed to in git. Also, which pages are popular, which pages are mainteined, etc. This would enable its search engine to filter bubble you and provide far better results that I currently see Confluence doing.
Further, it should be able to contain pages which are just indexed mirrors of other resources. Some pages could be simply uneditable mirrors of markdown files in your repository, making it possible for developers to keep documentation alongside the code if this makes more sense to them. Other pages could be mirrors of Word documents or Excel sheets of PDF files on shared drives or where the company likes to keep this stuff. All of this stuff would be thoroughly indexed by the wiki and would show up in search results.
So I guess what I'm proposing is that wikis become an aggregator of information more than a single store of information. And that they really, really nail the search part.
You've essentially described pagerank. Pagerank's patent just expired. Hopefully, that means it will start appearing in wikis.
Yeah, I probably did. The "personal filter bubble" thing is very much how google does it. I don't know the details about pagerank but I imagine that they are constantly tweaking their secret sauce to increase revenue and that they would rather keep the juicy parts secret than having them described in details in a patent.
Also, I'd imagine that other search engines, such as Bing, have developed similar algorithms although I'm sure thay take great care not to infringe upon the pagerank patent.
Disclaimer: Purely conjecture on my part. No particular knowledge of patent law, and only a high level understanding of the pagerant algorithm.
Disclaimer: Purely conjecture on my part. No particular knowledge of patent law, and only a high level understanding of the pagerant algorithm.
Better have a wiki with some obsolete pages than have nothing and no documentation at all.
True dat. Writing no documentation is also a bad path.
Personally I've come to favor keeping the technical documentation close to the code. That is, keep it as markdown files and check it into git. They are just as easily hyperlinked to as a wiki page on the bitbucket web interface (or whichever system is used). The main README.md should contain information on how to set up the dev environment. Other README.md files, located in the folder root of modules, provide more specific information.
Documentation of a less technical nature may still find a natural home in the Wiki, since we also need a place where various managers, testers, salespeople, support people, etc. can maintain their documentation.
Personally I've come to favor keeping the technical documentation close to the code. That is, keep it as markdown files and check it into git. They are just as easily hyperlinked to as a wiki page on the bitbucket web interface (or whichever system is used). The main README.md should contain information on how to set up the dev environment. Other README.md files, located in the folder root of modules, provide more specific information.
Documentation of a less technical nature may still find a natural home in the Wiki, since we also need a place where various managers, testers, salespeople, support people, etc. can maintain their documentation.
Also, nobody can ever find again, even if they remember. And then they will create a whole new page for the same thing plus a small addition. Then 6 months later some poor soul will notice that you have 10 pages on how to do X and he will delete everything and consolidate them all into one page. Then the cycle begins again. Wikis are fucking useless.
Too many developers simply refuse to do documentation or half-ass it. Developers who write good documentation are not valued or rewarded by companies and teams. Instead the teams grows to expect them to do all of it (while also considering them lesser because they don't do less cool stuff). Hence complete circle.
Unfortunately, not documenting seems to be part of culture.
Unfortunately, not documenting seems to be part of culture.
> move your internal “how do I do X” chatter from Slack to email lists and maybe a StackExchange installation, and you end up with multiple indexable, searchable sources of long-form documentation.
Really, those stores of "long term" documentation complement chat rather than replace it (whether it's Slack, IRC, or whatever). Over time, you should be developing that documentation, so when you have repeated "how do I do X" type of questions in chat, you can often direct people straight to the docs.
But documentation is never foolproof. It's inevitably incomplete, it goes out of date, etc. And for the information that the docs don't cover, you want a real time asynchronous discussion that's not as heavy-weight as a meeting or as slow as email, which is a good fit for chat.
Really, those stores of "long term" documentation complement chat rather than replace it (whether it's Slack, IRC, or whatever). Over time, you should be developing that documentation, so when you have repeated "how do I do X" type of questions in chat, you can often direct people straight to the docs.
But documentation is never foolproof. It's inevitably incomplete, it goes out of date, etc. And for the information that the docs don't cover, you want a real time asynchronous discussion that's not as heavy-weight as a meeting or as slow as email, which is a good fit for chat.
In my experience, it's chat that drives the documentation.
Chat is many things, but “asynchronous” is not often one of them.
Chat is absolutely asynchronous. It supports synchronous discussion, but I specifically like chat because I can ignore it until I dedicate a few minutes to look through the notifications.
You're lucky then. IMs are by their design pretty asynchronous, but there is this common dysfunction in many organizations - expecting you to be constantly on the chat and participate in real-time. That's the organization turning an asynchronous tool into a synchronous one, true, chats tend to facilitate that dysfunction much more than e-mail.
Slack, unintentionally, promotes interruptions under the guise of frictionless communications; it's very difficult to cultivate productivity in such a situation. Email is just as useful for tasking or questions, but without the constant interruptions (the receiver determines when they respond, and there's an asynchronous expectation, unlike Slack).
There is nothing you need on a team immediately, unless your infrastructure is burning down, in which case PagerDuty or SMS is letting you know.
Source: 3 years of Slack use in a fully remote environment, now working remote for an enterprise using Outlook for email, MS Teams for the occasional group chat 1-2 times/week, and Skype chat/phone calls/conference calls for the remainder. I prefer the later, as I get hours of uninterrupted time to focus each day.
There is nothing you need on a team immediately, unless your infrastructure is burning down, in which case PagerDuty or SMS is letting you know.
Source: 3 years of Slack use in a fully remote environment, now working remote for an enterprise using Outlook for email, MS Teams for the occasional group chat 1-2 times/week, and Skype chat/phone calls/conference calls for the remainder. I prefer the later, as I get hours of uninterrupted time to focus each day.
My impression is that companies that use Slack as an email replacement (including Slack themselves) have a culture where it's common to turn off push notifications / popups and check Slack periodically the way you'd check email periodically.
It's a been a year since I used slack but I distinctively remember that they didn't have anything to manage notifications / popups.
Possibly. That was not my experience ("turn off push notifications / popups and check Slack periodically the way you'd check email periodically.").
I use Slack extensively for personal needs (non-profits, subject matter groups, friends/family teams) but I would not voluntarily use it in a business setting. It's one of the first questions I ask when interviewing for new positions.
I use Slack extensively for personal needs (non-profits, subject matter groups, friends/family teams) but I would not voluntarily use it in a business setting. It's one of the first questions I ask when interviewing for new positions.
Hmm
As I get older I dislike meetings less, especially 1:1s. One-on-ones are usually the high point of my day.
As I get older I dislike meetings less, especially 1:1s. One-on-ones are usually the high point of my day.
This is just the same problem everyone has with everything. Tools are useful but you need good culture built around those tools. Slack is great for getting help, or discussing a topic in real time, especially when you're canvasing for views. But it's incumbent on the people to be sure they're contributing to it appropriately. A classic trap young engineers fall into is spewing questions when they haven't thought about something for themselves. In that environment Slack can be very destructive.
The fact that this guy repeatedly refers to middle management kind of hints to me that he doesn't understand that culture aspect.
The fact that this guy repeatedly refers to middle management kind of hints to me that he doesn't understand that culture aspect.
> I agree that Slack has created an interruptible culture
Slack isn't the first chat app used in a workspace, but it is the first one I've used that has tweakable mute settings and filters that can alert me only about things I care about.
At my previous jobs I've used IRC or Google Hangouts/Talk which is equally interrupting but has less features.
Slack isn't the first chat app used in a workspace, but it is the first one I've used that has tweakable mute settings and filters that can alert me only about things I care about.
At my previous jobs I've used IRC or Google Hangouts/Talk which is equally interrupting but has less features.
>Another JIRA flaw: highly formalized process is usually a hindrance, especially considering who in your organization invents, applies and benefits from process. Hint: middle managers.
This just reads as someone who hasn't had to actually think about what is being built, and who is paying for it. Effective teams are more than just "developers write and push code" - it's about being able to predictably say we are implementing this feature (or fixing this bug), therefore it will be available to customers at X time. As organisations grow, it becomes more and more critical to be able to predictably forecast the work that teams will complete, so that the right work can be planned out and roadmapped.
I had plenty of problems with this article, but this one stood out the most.
This just reads as someone who hasn't had to actually think about what is being built, and who is paying for it. Effective teams are more than just "developers write and push code" - it's about being able to predictably say we are implementing this feature (or fixing this bug), therefore it will be available to customers at X time. As organisations grow, it becomes more and more critical to be able to predictably forecast the work that teams will complete, so that the right work can be planned out and roadmapped.
I had plenty of problems with this article, but this one stood out the most.
Your interpretation of the quote is that middle managers don't provide value, but I think that may be too broad. I understood it as "highly formalized process often rewards middle managers", which I do think is true.
The best manager I was lucky enough to report to personalized his approach to his direct reports. He recognized that some people are more creative, others prefer more structure, etc. He still had his responsibilities, e.g. report progress on project X and estimate completion, but this was abstracted away from the team. For all we knew, we each had an area of the system we were responsible for, and we had longer-term collaborative projects that would take on the order of months. I didn't realize how great of a manager he was until I had other managers who firmly believed in the One True Way™ of managing projects, and also pretty much required everyone to be heavily involved in it. (Give estimations for things you haven't worked on, and move tasks as you get to each stage of development.)
Getting back to my original point - highly formalized process often rewards middle managers because it simplifies work for them. Everything is already tracked in the system, it's a matter of moving around and allocating resources. But why does everyone need to be involved in this? Why isn't heavily formalized process compartmentalized to just managers and the people they report to (and maybe their reports that enjoy that process)?
I recognize the value that managers bring - otherwise every individual contributor becomes a mini-PM - but I also believe that the best managers put in the work. They build good personalized relationships with each member of the team, and are able to compile estimates based on their interactions. It's not always a cold science in the vein of "since Alice has 13 points out of a maximum of 18 points per sprint, I should try to allocate 5 more points - the biggest task that fits into that is 4 points, so let's assign that to her."
The best manager I was lucky enough to report to personalized his approach to his direct reports. He recognized that some people are more creative, others prefer more structure, etc. He still had his responsibilities, e.g. report progress on project X and estimate completion, but this was abstracted away from the team. For all we knew, we each had an area of the system we were responsible for, and we had longer-term collaborative projects that would take on the order of months. I didn't realize how great of a manager he was until I had other managers who firmly believed in the One True Way™ of managing projects, and also pretty much required everyone to be heavily involved in it. (Give estimations for things you haven't worked on, and move tasks as you get to each stage of development.)
Getting back to my original point - highly formalized process often rewards middle managers because it simplifies work for them. Everything is already tracked in the system, it's a matter of moving around and allocating resources. But why does everyone need to be involved in this? Why isn't heavily formalized process compartmentalized to just managers and the people they report to (and maybe their reports that enjoy that process)?
I recognize the value that managers bring - otherwise every individual contributor becomes a mini-PM - but I also believe that the best managers put in the work. They build good personalized relationships with each member of the team, and are able to compile estimates based on their interactions. It's not always a cold science in the vein of "since Alice has 13 points out of a maximum of 18 points per sprint, I should try to allocate 5 more points - the biggest task that fits into that is 4 points, so let's assign that to her."
>Your interpretation of the quote is that middle managers don't provide value, but I think that may be too broad. I understood it as "highly formalized process often rewards middle managers", which I do think is true.
I agree, but I don't think that's a bad thing - I think something that rewards management, rewards the team as a whole. If the PO/PM overcommits, it's the team as a whole who suffers. Likewise, if targets are smashed, the team gets recognition.
As such my interpretation wasn't that middle management is bad, but that formalised development processes are bad, which is what I fundamentally disagree with.
Businesses as they grow end up having abstractions on abstractions. Formalising development processes allows for the business to actually be aware of what it's doing, how effectively it's being done, and where opportunities lay for improvements.
Don't get me wrong - too much management creates warrantless red tape and frustrations, however standardising the development process through things like Jira (which the author was complaining about) doesn't fall into that bucket (in my opinion), especially when the author compares that the same can be done with a blank sheet of paper - if senior management want a rough understanding of the roadmap for the next 12 months, why would you "forecast" with some guessing on paper, over actual proven data of this is roughly how this team performs, this is the rough estimates on these initiatives, ergo, we can commit to these X projects.
I agree, but I don't think that's a bad thing - I think something that rewards management, rewards the team as a whole. If the PO/PM overcommits, it's the team as a whole who suffers. Likewise, if targets are smashed, the team gets recognition.
As such my interpretation wasn't that middle management is bad, but that formalised development processes are bad, which is what I fundamentally disagree with.
Businesses as they grow end up having abstractions on abstractions. Formalising development processes allows for the business to actually be aware of what it's doing, how effectively it's being done, and where opportunities lay for improvements.
Don't get me wrong - too much management creates warrantless red tape and frustrations, however standardising the development process through things like Jira (which the author was complaining about) doesn't fall into that bucket (in my opinion), especially when the author compares that the same can be done with a blank sheet of paper - if senior management want a rough understanding of the roadmap for the next 12 months, why would you "forecast" with some guessing on paper, over actual proven data of this is roughly how this team performs, this is the rough estimates on these initiatives, ergo, we can commit to these X projects.
yep. When managers and their subordinates are just following "the policy" instead of improving it, makes sense that everyone hates the big bad JIRA monster.
Most managers and non-managers never get to figure out that JIRA is there to help them, and as such they MUST change it at the first sight of a problem. Those who fail to realize that it is a malleable tool that must be configured according to needs and particular situation are missing out.
But this is not really a surprise. In 99% of orgs I worked for JIRA has been a "dictated tool" instead of a "chosen tool", which means that those who dictated it are not the ones who are using it - and are basically just there to spread suffering to those who do use it.
Most managers and non-managers never get to figure out that JIRA is there to help them, and as such they MUST change it at the first sight of a problem. Those who fail to realize that it is a malleable tool that must be configured according to needs and particular situation are missing out.
But this is not really a surprise. In 99% of orgs I worked for JIRA has been a "dictated tool" instead of a "chosen tool", which means that those who dictated it are not the ones who are using it - and are basically just there to spread suffering to those who do use it.
Thing is, I have always used IM in one form or other for work. Slack is finally one that can handle code snippets well.
It's not worse at interruption than any other IM (and you can tell it to shut up, so), it does not replace documentation, and it does not solve any organisational problems (it's a technical solution, how could it).
What it is, however, is a chat client that can handle code snippets well. So yay for that.
It's not worse at interruption than any other IM (and you can tell it to shut up, so), it does not replace documentation, and it does not solve any organisational problems (it's a technical solution, how could it).
What it is, however, is a chat client that can handle code snippets well. So yay for that.
If not Slack, then what? Nothing?
I work as part of a fully remote team and I can't really imagine not using Slack.
Generally we discuss in Slack, immortalize in GitHub issues (using ZenHub, thank god), and do ad-hoc video calls for screen sharing and whatnot. Announcements and such usually go out as an email blast.
I'm really curious what life would be like using email/issue comments only. Obviously this must be possible since so many open source projects operate this way, right? But they also have a totally different organizational structure.
Any insights, HN?
I work as part of a fully remote team and I can't really imagine not using Slack.
Generally we discuss in Slack, immortalize in GitHub issues (using ZenHub, thank god), and do ad-hoc video calls for screen sharing and whatnot. Announcements and such usually go out as an email blast.
I'm really curious what life would be like using email/issue comments only. Obviously this must be possible since so many open source projects operate this way, right? But they also have a totally different organizational structure.
Any insights, HN?
Remove asynchronous interruptions and go back to old-fashioned synchronous interruptions (scheduled meetings, either in person or calls/video chats) for the stuff that requires high-bandwidth communication and asynchronous non-interrupting queues (emails, or other similarly-shaped things like tickets or wiki page edits / comments) for the stuff that requires low-bandwidth communication and more intensive thought / work.
If you need asynchronous interruptions, pre-Slack and even pre-email culture had ways to do this - phone calls, pages, knocking on people's doors - but they were viewed as rare and exceptional, and the coworker who would knock on your door all the time to ask if you saw the message they just sent was viewed as rude and distracting.
If you need asynchronous interruptions, pre-Slack and even pre-email culture had ways to do this - phone calls, pages, knocking on people's doors - but they were viewed as rare and exceptional, and the coworker who would knock on your door all the time to ask if you saw the message they just sent was viewed as rude and distracting.
I'ld much rather be IM'ed or emailed than called or paged. If I am called, the phone rings or the pager beeps, and I have little choice but to interrupt my work. My slack client, on the other hand sits in the system tray, silently displaying a little blue or red dot. I can open chat when I feel like it, or ignore it until such a time when I am not concentrating on something else.
Asynchronous communication is empowering: You can choose when you communicate and when you want to concentrate. Synchronous communication does not afford you that luxury.
Asynchronous communication is empowering: You can choose when you communicate and when you want to concentrate. Synchronous communication does not afford you that luxury.
Why is using Slack in this workflow superior to using email? I also know if I have unread emails via the tray icon or mobile app badge, same as with Slack.
Is it just that short frequent messages in email feel weird?
Is it just that short frequent messages in email feel weird?
That, the superior handling of short-message group conversations and the fact that the number of people who could email me is vastly greater than my team members on slack. As such, I tend to check slack relatively frequently, while I check my emails only twice a day - I do not have push notifications enabled for email. Basically, slack means a usually-within-2-hours response time, while email means same-or-next-workday response time.
The problem is, chats are being interpreted as synchronous - you are expected to be available and to reply in real-time.
I found that to be a problem of organizational culture, not of chat itself. In my experience, if it was culturally fine to interrupt other people's work, quick answers were expected via chat, too. If it was the organization's culture to let people work without unscheduled interruptions, that extended to the expectations around chat, too.
Indeed. However, chat facilitates this particular kind of organizational dysfunction much more than e-mail; that's probably why people pin the problem on chats.
[deleted]
How is email non-interrupting but Slack is? You can enable/disable notifications for either of them and respond to either when you like.
Culture and expectations. Same reason I'm listing video calls as non-interrupting when they certainly are capable of interrupting: set expectations that scheduled meetings are normal and unannounced calls are for emergencies.
If you can make your Slack non-interrupting, fantastic, but probably the advantages over email are slim.
If you can make your Slack non-interrupting, fantastic, but probably the advantages over email are slim.
I'm remote from time to time. I really can't think of how the synchronous nature of Slack helps anything. If you need real-time chat, it's faster and more productive to have a phone/video call. If it's a long chat with lots of detail, email or issues? If you are spending > 10 seconds writing something to someone on Slack, you are already wasting time - if it's important, it needs to live elsewhere. It if it just "chat", then talking is faster.
Talking over the phone doesn't show me the code/command/text we are talking about. It takes far more words to "talk" through a problem than it does to show the source...
I think OP assumes collocation, and would suggest in person discussion. See the 'sheet of paper is all you need to plan' note.
Since they also complain about open office, I think their ideal mode of work is a small team with their own office, caring only about their little silo and not much for what the rest of the company is doing. For some types of work, that is indeed optimal!
To me, not having an instant messenger at work would be a great loss. You now either have to come to someone in person, and be way more disruptive - after all you can silence slack notifications, but you can't suppress someone coming to you, make calls - same problem, or do with something like email, where the back-and-forth is much slower.
Since they also complain about open office, I think their ideal mode of work is a small team with their own office, caring only about their little silo and not much for what the rest of the company is doing. For some types of work, that is indeed optimal!
To me, not having an instant messenger at work would be a great loss. You now either have to come to someone in person, and be way more disruptive - after all you can silence slack notifications, but you can't suppress someone coming to you, make calls - same problem, or do with something like email, where the back-and-forth is much slower.
> where the back-and-forth is much slower.
This is a feature. Slower back and forth means people put more thought into it and communicate better.
This is a feature. Slower back and forth means people put more thought into it and communicate better.
Even i think so, need to know why people think otherwise
> "If not Slack, then what? Nothing?"
I've not used it before, but I can see the potential benefits of a tool like Huddle:
https://www.huddle.com/
At the very least, tools like Huddle mean that discussions can be focused on the documents that a team are working on.
I've not used it before, but I can see the potential benefits of a tool like Huddle:
https://www.huddle.com/
At the very least, tools like Huddle mean that discussions can be focused on the documents that a team are working on.
Whatsapp? Obviously lacking the gimmicks but still
You should try Twist (https://twistapp.com/). I switched to Twist with my team and haven't looked back at Slack. Twist organizes discussions around tasks. When the task is finished, that conversation is pretty much over.
Read this post by Amir, the founder of TwistApp - Why We're Betting Against Real Time Messaging - https://blog.doist.com/why-were-betting-against-real-time-te...
Read this post by Amir, the founder of TwistApp - Why We're Betting Against Real Time Messaging - https://blog.doist.com/why-were-betting-against-real-time-te...
Twist looks promising, if a little simplistic. I've been looking for something like this to complement our Slack channels, and to replace Basecamp (which our sales staff and project managers use for our B2B customer collaboration), which I think is terrible.
But the fact that Twist also has real-time chat means that it doesn't really make sense to use both Twist and Slack -- it wants to be the one platform your team uses. At the same time, Twist isn't nearly as polished as Slack (try opening the web app on mobile -- it doesn't scale to the display!).
Are there any good tools like this? Something a little more project/task-oriented than Discourse, but not a full-blown task management system like Trello or JIRA?
But the fact that Twist also has real-time chat means that it doesn't really make sense to use both Twist and Slack -- it wants to be the one platform your team uses. At the same time, Twist isn't nearly as polished as Slack (try opening the web app on mobile -- it doesn't scale to the display!).
Are there any good tools like this? Something a little more project/task-oriented than Discourse, but not a full-blown task management system like Trello or JIRA?
I saw the twist video. And it seems just like slack. Slack, but guys please observe discipline. The UI, design, philosophy everything is identical to slack.
You feel forced to respond to slack chats, so just chill and respond only when you want to. This is literally in the video.
The thread loses track of the topic, so we have exactly the same hierarchy and groupings like slack, but guys please just use the thread for the topic only. This is literally in the video.
Chats are annoying and people keep disturbing you in slack. We have "messages", perfect for small groups and individual conversations. Again, exactly like slack, but let's all promise to be not annoying.
The UI and app look great, I can see that folks really worked hard on this thing. But there is zero differentiation from slack. It looks like somebody took slack, re-colored it, and put "calmer and more organized" on the website.
You feel forced to respond to slack chats, so just chill and respond only when you want to. This is literally in the video.
The thread loses track of the topic, so we have exactly the same hierarchy and groupings like slack, but guys please just use the thread for the topic only. This is literally in the video.
Chats are annoying and people keep disturbing you in slack. We have "messages", perfect for small groups and individual conversations. Again, exactly like slack, but let's all promise to be not annoying.
The UI and app look great, I can see that folks really worked hard on this thing. But there is zero differentiation from slack. It looks like somebody took slack, re-colored it, and put "calmer and more organized" on the website.
> The UI, design, philosophy everything is identical to slack.
This isn't quite right. The way Twist shows threads and information is a lot closer to email, and there's a big difference in how it organizes information: on top of channels, which are based on groups or projects, it has threads as a base organizational unit.
UX does influence behaviour, afaik. The Twist UX facilitates and encourages long-form, on-topic discussion a LOT more than Slack. See also email: have you ever used email like Slack?
imo the main issue is actually that email + some mailing lists still has major advantages over Twist.
This isn't quite right. The way Twist shows threads and information is a lot closer to email, and there's a big difference in how it organizes information: on top of channels, which are based on groups or projects, it has threads as a base organizational unit.
UX does influence behaviour, afaik. The Twist UX facilitates and encourages long-form, on-topic discussion a LOT more than Slack. See also email: have you ever used email like Slack?
imo the main issue is actually that email + some mailing lists still has major advantages over Twist.
How does Twist compare with a forum app like, say, Discourse?
Then why not just use comment threads on tickets?
Agree, this just looks like a subset of JIRA with a snappier UI. Atlassian would do well to pay attention.
In my organization, github PR threads and JIRA comment threads tend to be ignored or forgotten after their inception, and chat gets results right now. We also use Trello, Confluence, google docs, and of course email for some things. I think this sort of thing is common.
They all have their strengths and weaknesses, but it strikes me that a bigger barrier to productivity and strong organizational memory than interruptions is the overall dilution of information.
Sometimes I think that the narrowing of the available tools (channels for information), whatever the weaknesses of the chosen tools might be, would be wise.
They all have their strengths and weaknesses, but it strikes me that a bigger barrier to productivity and strong organizational memory than interruptions is the overall dilution of information.
Sometimes I think that the narrowing of the available tools (channels for information), whatever the weaknesses of the chosen tools might be, would be wise.
We've found this to be partially true in our very small startup. The unstructured nature of Slack conversation do make it hard to go back and reference something that was said only a few days ago, however we have found that the search tool has been very useful in locating a decision or rule that was made a while back in casual conversation.
By and large, the biggest problem we have, even with a handful of users, is the fact that everyone tends to just use Slack as an ideas repository, and bug tracking/feature request tool, rather than log it in our actual Phabricator development tracking tool.
Also, we have (I believe) gone a little overboard with integrating our other tools into Slack (including Phabricator, AWS, Stripe etc.), so we are almost at a 1:1 ration of bot generated messages to user created messages at the moment - leading to a lot of inadvertent mental filtering of channels, resulting in missed (human) messages.
By and large, the biggest problem we have, even with a handful of users, is the fact that everyone tends to just use Slack as an ideas repository, and bug tracking/feature request tool, rather than log it in our actual Phabricator development tracking tool.
Also, we have (I believe) gone a little overboard with integrating our other tools into Slack (including Phabricator, AWS, Stripe etc.), so we are almost at a 1:1 ration of bot generated messages to user created messages at the moment - leading to a lot of inadvertent mental filtering of channels, resulting in missed (human) messages.
As time has wore on our organization has relied on slack less for team collaboration and more for monitoring.
Admittedly, the slack client is great at cross platform notifications and we leverage those in our monitoring processes, where alerts are sent via zabbix to pagerduty and slack simultaneously via webhooks.
In a real sense the responders have “any activity creates a notification” which enables them to react and others to view a record of what happened. This eliminates the casual “what happened?” conversations.
We’ve yet to have an oncall event fall through the cracks.
Admittedly, the slack client is great at cross platform notifications and we leverage those in our monitoring processes, where alerts are sent via zabbix to pagerduty and slack simultaneously via webhooks.
In a real sense the responders have “any activity creates a notification” which enables them to react and others to view a record of what happened. This eliminates the casual “what happened?” conversations.
We’ve yet to have an oncall event fall through the cracks.
Before Slack it seemed like everywhere I worked had chat and IM anyway -- it was just a thinner experience. As a programmer I have mixed feelings about making a point about "distractions". On one hand I'm sympathetic and think people need to be more conscientious... but I also think managing distractions is an important skill as a programmer, and there are a lot of people that seem to relish in acting professionally flustered all the time. At the end of the day sometimes answering questions and coordinating with people is the important work -- even if it might be frustrating.
Also, I mean, you can just turn it off or mute the notifications. I see people do that all the time and nobody cares.
Also, I mean, you can just turn it off or mute the notifications. I see people do that all the time and nobody cares.
Love your last point; I'd respect someone who'd mute notifications and treat it mainly as an asynchronous communications tool.
Combine it with an Urgent channel if need be, where notifications are On, and tell people off for posting crap there..
Combine it with an Urgent channel if need be, where notifications are On, and tell people off for posting crap there..
[shameless plug]
This is exactly why we at FastMail made Topicbox! Email is your personal memory, and it made sense to extend that to organizational memory by making mailing lists not suck.
And we switched from IRC to Slack for our internal comms a while back, so we know the pros and cons :) Chat's great for real time, but not for long-term memory.
https://www.topicbox.com/
[/shameless plug]
This is exactly why we at FastMail made Topicbox! Email is your personal memory, and it made sense to extend that to organizational memory by making mailing lists not suck.
And we switched from IRC to Slack for our internal comms a while back, so we know the pros and cons :) Chat's great for real time, but not for long-term memory.
https://www.topicbox.com/
[/shameless plug]
As a technical writer I have a big problem with Slack. It seems like a black hole of unfindable knowledge. I stick to Stack Overflow and mailing lists when I interact in my product’s communities because they are streamlined repositories of linear knowledge.
A moment of gratitude to Stack Overflow and mailing lists!
A moment of gratitude to Stack Overflow and mailing lists!
The problem I have with large group chats like Slack, Riot, IRC is that it's hard to get information from them when you've been "out of the loop" for a while. Much better to read a bunch of forum threads or tickets, then trying to make sense of a long scrollback.
You shouldn't be trying to. Slack is a tool used for raid iteration, not an event / decision log. Unless you establish some strict conventions, like having an announce / decision channel with very restricted traffic, you should still record important decisions somewhere else, and give that to people when they need to 'catch up'.
That doubles the authoring workload, though.
If you're talking on something like a forum, with individualized contextual threads, then those are already auto-categorized for reference later.
I guess the equivalent would be to start new chat channels per topic, and index them somehow? But realtime chat tends to have more organic topic drift than post-based discussion.
If you're talking on something like a forum, with individualized contextual threads, then those are already auto-categorized for reference later.
I guess the equivalent would be to start new chat channels per topic, and index them somehow? But realtime chat tends to have more organic topic drift than post-based discussion.
Doubling the authoring workload is inevitable for anything particularly important. It's discussed once, then distilled down to a more consumable form a second time. If a new employee joins it's not like they're going to read two years of slack backlog to get going.
> I guess the equivalent would be to start new chat channels per topic, and index them somehow? But realtime chat tends to have more organic topic drift than post-based discussion.
Well said. It's a shame IMO how much forum software has deteriorated in innovation post 2010 or so. Discourse is nice, but not my cup of tea when compared to the layout of "classic" forum software, phpBB, SMF, etc.
Well said. It's a shame IMO how much forum software has deteriorated in innovation post 2010 or so. Discourse is nice, but not my cup of tea when compared to the layout of "classic" forum software, phpBB, SMF, etc.
Classic forums software was pretty much a web based NNTP gateway -- some even supported nntp integration directly. Posts were threaded.
Then along came unthreaded forums in late 90s/early 00s. Things like phpBB are not my cup of tea when compared to the layout of usenet or slashcode.
Then along came unthreaded forums in late 90s/early 00s. Things like phpBB are not my cup of tea when compared to the layout of usenet or slashcode.
> Classic forums software was pretty much a web based NNTP gateway -- some even supported nntp integration directly. Posts were threaded.
Ah. We have a different view of "classic forum software". NNTP was before my time.
Ah. We have a different view of "classic forum software". NNTP was before my time.
Doubling the authoring workload is important, though: it ensures that everyone walks away from a long conversation with the same summary. Even if you're present in a conversation, you can think that someone agreed with something you said when they actually scrolled past it or forgot.
Traditional meetings have secretaries and a procedure for approving minutes for this very reason.
Traditional meetings have secretaries and a procedure for approving minutes for this very reason.
There are 3 primary types of documentation that a growing organization needs :
1. Onboarding 2. Runbook / Troubleshooting 3. Notes and ongoing developer wisdom
Slack helps with #3, but is not what #1 and #2 require.
New hires should not be digging through slack to get up to speed, and ops or engs trying to deal with catastrophe in the wee hours should have playbooks, not try to dig up what worked last time in slack.
1. Onboarding 2. Runbook / Troubleshooting 3. Notes and ongoing developer wisdom
Slack helps with #3, but is not what #1 and #2 require.
New hires should not be digging through slack to get up to speed, and ops or engs trying to deal with catastrophe in the wee hours should have playbooks, not try to dig up what worked last time in slack.
do you have any recommendations for good runbook tools? I'm on the market for one of these.
a wiki?
Yeah a wiki should suffice. Having a good runbook is a process that needs to be tended to every time devs and ops deploy, troubleshoot, and configure services. More of a process than a tool, because it should integrate with all the tools already in use for deployment, logging, debugging, etc.
I wonder if disabling search and restricting chat rooms to a limited buffer would help encourage people to see Slack as a lossy chat service and not an appropriate data store. You would be forced to decide what's important to keep and keep it somewhere.
I especially don't like when Slack is used as an official record.
I especially don't like when Slack is used as an official record.
Why?
It is a great advantage of slack over email / in person that you can later find two people you've never met discussing something similar to your problem, follow their historical discussion, and possibly find a solution.
Or even your own previous conversations for issues deemed too minor to record in a more 'official' record (like a jira ticket, or project documentation).
It is a great advantage of slack over email / in person that you can later find two people you've never met discussing something similar to your problem, follow their historical discussion, and possibly find a solution.
Or even your own previous conversations for issues deemed too minor to record in a more 'official' record (like a jira ticket, or project documentation).
If you have an internal wiki, email list archives, and maybe an internal StackExchange and set up an ElasticSearch cluster over the whole works, you can answer pretty much any question in a one stop shop.
None of those do interactive collaboration like debugging very well. You could copy the result of the collaboration into something like that, but actually getting people to do that is not trivial. If the collaboration happens on slack, you get at least some searchability.
For large organizations, a forum/ticket model is a much better way to leverage organizational memory and knowledge.
For small teams, and teams within organizations, I actually think the Slack model does fine if people mute it. I'm one of those people that loves to help people with technical challenges and this was a big hurdle for me. Almost all of the problems in the article can be solved by muting and only checking during breaks.
I don't think anyone rational would conflate productivity with availability on slack unless their job is to answer questions on slack. It's also just such an obviously bad idea to forgo documentation in favor of Slack that I'd say no rational developer would do that either. Those aren't problems with Slack, those are problems with lazy people who want to blame Slack for poor software development.
For small teams, and teams within organizations, I actually think the Slack model does fine if people mute it. I'm one of those people that loves to help people with technical challenges and this was a big hurdle for me. Almost all of the problems in the article can be solved by muting and only checking during breaks.
I don't think anyone rational would conflate productivity with availability on slack unless their job is to answer questions on slack. It's also just such an obviously bad idea to forgo documentation in favor of Slack that I'd say no rational developer would do that either. Those aren't problems with Slack, those are problems with lazy people who want to blame Slack for poor software development.
For all the hate Slack gets, it works great for me. Yes, you can be interrupted, but you can also ignore it very easily. Without Slack, I’d have people coming up to my desk and asking me questions, which would _really_ be distracting. Maybe I work in a company with a good culture, but the middle managers don’t use Slack in the way he describes. Sure, managers can act that way, but they don’t have to. And in my experience, they don’t.
I don’t understand his comparisons to Trello and JIRA. Those are project management tools. Slack is a chat tool. Completely different things. And his complaint that it’s a bad tool for documentation also rings hollow. It’s a _chat_ app. Is he also going to complain that his hammer it a terrible tool for tightening screws?
I don’t understand his comparisons to Trello and JIRA. Those are project management tools. Slack is a chat tool. Completely different things. And his complaint that it’s a bad tool for documentation also rings hollow. It’s a _chat_ app. Is he also going to complain that his hammer it a terrible tool for tightening screws?
Yeah, maybe Slack is bad in OP's workplace. But in mine, it's been great for increasing communication in an all-remote developer company. JIRA is used for task management, docs are stored in the same repo as the code, and Slack is used just to talk to people or solicit opinions. No one ever uses @here because none of us want to be bothered either.
I feel like most of the complaints on Slack are either because people use it as something other than logged IRC, or because it's getting misblamed for other company culture problems.
I feel like most of the complaints on Slack are either because people use it as something other than logged IRC, or because it's getting misblamed for other company culture problems.
I've often thought about using good old NNTP as a replacement for Slack. It does everything I want from Slack in terms of structured conversation and preservation of information. At the same time it doesn't have the same real-timey feeling (that the OP refers to as urgency).
There are two types of memory: long term memory and short term memory. Slack is short term memory. Both kinds are important -- short term memory without long term memory is amnesia.
I like this metaphor. Thanks for posting.
Ai yai yai. People need to stop adopting tools thinking it'll be the panacea of communication and organization. Insofar as the author says that I agree.
But I think it is equally short sited to blame the tool.
Whatever tool you choose, you have to FULLY adopt. Everyone has to be bought in, learning the features (like do not disturb), setting ground rules which make sense for your company and how people within it like to get things done.
Seriously, I never felt more productive than when I used Trac, I don't think issue tracking has really evolved much more than that save useful social features and code review (essentially what killed Trac because the Git integration was never very good).
When I look back as to why that was, I realize it was because the WHOLE COMPANY was bought in. We all used it, we all used it well and respectfully.
This is the madness of the agile world. Viewing the tool as the solution rather than just that, an implement, a ways to a means that starts before its usage and and ends after its usage.
> Remote work culture is a defense mechanism against the distracting open office
Disagree as to the reason remote work has become a thing, but I do think it's largely because video conferencing works better every year, tools like Slack exist, and code review tools can be done line-for-line remotely.
But, has anyone seen the Slack diagram for whether or not to send a message? It is extremely well thought out, but settings can't be useful if you don't set them.
> Chat, at least on slack, isn’t grouped or threaded.
Yes they are, now.
> ...non-trivial to know what the current topics of conversation are in a slack channel or to assign one of those topics to any given message.
Then speak up and tell people to stick to the topic, change it, or open a new room.
> ctrl-f, the one constant of web interaction, is broken in channels if you’re searching more than one page up.
Use the Slack client
> Middle managers will make deliverables....
And here is where I stop reading. This is an organizational problem you see manifesting on the tool and you are incorrectly assigning blame to the tool.
--
You have to be committed to using whatever tool is chosen. Just choose one and actually use it.
These tools are a discipline not a freedom from discipline.
But I think it is equally short sited to blame the tool.
Whatever tool you choose, you have to FULLY adopt. Everyone has to be bought in, learning the features (like do not disturb), setting ground rules which make sense for your company and how people within it like to get things done.
Seriously, I never felt more productive than when I used Trac, I don't think issue tracking has really evolved much more than that save useful social features and code review (essentially what killed Trac because the Git integration was never very good).
When I look back as to why that was, I realize it was because the WHOLE COMPANY was bought in. We all used it, we all used it well and respectfully.
This is the madness of the agile world. Viewing the tool as the solution rather than just that, an implement, a ways to a means that starts before its usage and and ends after its usage.
> Remote work culture is a defense mechanism against the distracting open office
Disagree as to the reason remote work has become a thing, but I do think it's largely because video conferencing works better every year, tools like Slack exist, and code review tools can be done line-for-line remotely.
But, has anyone seen the Slack diagram for whether or not to send a message? It is extremely well thought out, but settings can't be useful if you don't set them.
> Chat, at least on slack, isn’t grouped or threaded.
Yes they are, now.
> ...non-trivial to know what the current topics of conversation are in a slack channel or to assign one of those topics to any given message.
Then speak up and tell people to stick to the topic, change it, or open a new room.
> ctrl-f, the one constant of web interaction, is broken in channels if you’re searching more than one page up.
Use the Slack client
> Middle managers will make deliverables....
And here is where I stop reading. This is an organizational problem you see manifesting on the tool and you are incorrectly assigning blame to the tool.
--
You have to be committed to using whatever tool is chosen. Just choose one and actually use it.
These tools are a discipline not a freedom from discipline.
> Yes they are, now.
The threading in Slack is abysmal, and trying to keep track of a threaded conversation or seeing conversations inside threaded conversations is almost impossible.
> Use the Slack client
The Slack client is an Electron application running Chrome. Search is still hopelessly broken in the Slack client. Trying to scroll up still causes the "app" to use gigabytes of memory, and it's still terribly broken.
The threading in Slack is abysmal, and trying to keep track of a threaded conversation or seeing conversations inside threaded conversations is almost impossible.
> Use the Slack client
The Slack client is an Electron application running Chrome. Search is still hopelessly broken in the Slack client. Trying to scroll up still causes the "app" to use gigabytes of memory, and it's still terribly broken.
The Slack client is literally just the web app inside of a buggy single-page browser.
>Use the Slack client
I know it's technicalities, but sadly this isn't possible for everyone. Closest thing is using the IRC gateway, but at that point your company might as well be just using IRC...
I know it's technicalities, but sadly this isn't possible for everyone. Closest thing is using the IRC gateway, but at that point your company might as well be just using IRC...
TBH I find using the browser more convenient than the slack client. The search is fine in my experience, and we send ~100k messages a day in our server.
Why is this not possible for everyone?
The internet suggests that the official desktop/web client is not particularly usable with a screen reader:
https://www.marcozehe.de/2016/01/16/status-of-the-accessibil...
https://slackhq.com/designing-slack-for-everyone-456002920bf... (talks mostly about the mobile clients, which were designed later)
Maybe this has changed recently?
https://www.marcozehe.de/2016/01/16/status-of-the-accessibil...
https://slackhq.com/designing-slack-for-everyone-456002920bf... (talks mostly about the mobile clients, which were designed later)
Maybe this has changed recently?
It's closed source and not ported to all operating systems that people might use.
Positioned as a tool for collaboration and productivity, how can Slack legitimately be that when it is designed for online, synchronous communication?
Is it really collaboration when members in a channel do not have a chance to prepare or struggle to participate at that pace?
What is productive about Slack? Perhaps you get questions answered through the tool, but you do not produce through Slack. I think of meetings as productive when progress is made on a problem or a decision is arrived at. How does Slack facilitate that better than scheduled meetings?
I have generally stopped using Slack. If a conversation takes longer than three minutes to conduct on Slack, in real/video/phone life please. There is an illusion that work is getting done faster on Slack; the opposite is true, work is slower and of poorer quality.
Is it really collaboration when members in a channel do not have a chance to prepare or struggle to participate at that pace?
What is productive about Slack? Perhaps you get questions answered through the tool, but you do not produce through Slack. I think of meetings as productive when progress is made on a problem or a decision is arrived at. How does Slack facilitate that better than scheduled meetings?
I have generally stopped using Slack. If a conversation takes longer than three minutes to conduct on Slack, in real/video/phone life please. There is an illusion that work is getting done faster on Slack; the opposite is true, work is slower and of poorer quality.
> How does Slack facilitate that better than scheduled meetings?
Slack is not a replacement for scheduled meetings though.
> If a conversation takes longer than three minutes to conduct on Slack, in real/video/phone life please. There is an illusion that work is getting done faster on Slack; the opposite is true, work is slower and of poorer quality.
People say meetings are high-bandwidth, but getting a bunch of engineers in a room is very expensive (literally - hundreds of dollars an hour) and you get synchronous, blocking discussion (one person speaks at a time - else, chaos). I am much, much less distracted participating in a "long" slack discussion (which I can check in on every few minutes or so) than I am with all my attention paid to listening to a meeting.
Personally, I find few people on any given team are able to communicate well on the fly in a meeting and I see people (including myself) frequently asking for clarification due to misunderstandings, which contributes to a meeting dragging. Meetings are also _notorious_ for encouraging unfocused and unstructured discussion, unless you have a good moderator or some structured approach to a meeting (like a lean coffee style). A lot of this is improved in a Slack conversation because people are forced to distill their thoughts into text, they are able to reread messages for clarification, and we've had good success using Slack threads for focused discussion of particular topics.
Meetings are also not archived by default, which isolates the people unable to attend the meeting - especially when you have in person meetings that are not remote friendly. Slack discussions are at least discoverable through search. One team I was on started recording meetings and rewatching hour long meeting minutes to get information is actually terrible. Searching through Slack is not perfect, but it's infinitely quicker and I frequently do find what I want.
Slack is not a replacement for scheduled meetings though.
> If a conversation takes longer than three minutes to conduct on Slack, in real/video/phone life please. There is an illusion that work is getting done faster on Slack; the opposite is true, work is slower and of poorer quality.
People say meetings are high-bandwidth, but getting a bunch of engineers in a room is very expensive (literally - hundreds of dollars an hour) and you get synchronous, blocking discussion (one person speaks at a time - else, chaos). I am much, much less distracted participating in a "long" slack discussion (which I can check in on every few minutes or so) than I am with all my attention paid to listening to a meeting.
Personally, I find few people on any given team are able to communicate well on the fly in a meeting and I see people (including myself) frequently asking for clarification due to misunderstandings, which contributes to a meeting dragging. Meetings are also _notorious_ for encouraging unfocused and unstructured discussion, unless you have a good moderator or some structured approach to a meeting (like a lean coffee style). A lot of this is improved in a Slack conversation because people are forced to distill their thoughts into text, they are able to reread messages for clarification, and we've had good success using Slack threads for focused discussion of particular topics.
Meetings are also not archived by default, which isolates the people unable to attend the meeting - especially when you have in person meetings that are not remote friendly. Slack discussions are at least discoverable through search. One team I was on started recording meetings and rewatching hour long meeting minutes to get information is actually terrible. Searching through Slack is not perfect, but it's infinitely quicker and I frequently do find what I want.
You are right in that meetings are prone to being wasteful and unarchived. A few considerations that I find necessary for meetings:
- Schedule in advance (if possible)
- Set an agenda and provide reading material (if available) such that attendees can prepare
- Be selective in who attends; those with relevant knowledge, interest or stakeholders
- Record meeting notes (key decisions, unsettled conversations, differing opinions)
- Appoint a chair to keep the meeting on track, as per the agenda. They can also help shut people up and give others a chance to speak.
- Share the meeting notes with the team at large
The author nails my thoughts on Slack (and its OS clone Mattermost). It is less a communications tool, more of a productivity tracker.
I've worked in places where it was unofficially compulsory to have Slack always open. If you didn't respond to a message is a timely fashion then you'd be asked why. It became the case that Activity on Slack = Productivity.
This wouldn't be so bad if it weren't for the fact that I think Slack is a pretty poor way to do workplace communication. It's the textual equivalent of shouting out a question to the whole office. Everything seems to mush together in to one big conversation about everything that is hard to track and search.
I've worked in places where it was unofficially compulsory to have Slack always open. If you didn't respond to a message is a timely fashion then you'd be asked why. It became the case that Activity on Slack = Productivity.
This wouldn't be so bad if it weren't for the fact that I think Slack is a pretty poor way to do workplace communication. It's the textual equivalent of shouting out a question to the whole office. Everything seems to mush together in to one big conversation about everything that is hard to track and search.
My thoughts on your comments are the same as my thoughts on the article. These are cultural problems that Slack is simply exposing. If there was no Slack, something else would fill the need for your middle management to track everyone's 'productivity'.
In regards to "organizational memory", has anyone had any luck not allowing for "private messages?" The idea being that the vast majority of conversations between any two people will be about a work item, if it's about work, and therefore all conversations should be organized around work items, rather than people.
Gitlab seems to do this[0] and I'm curious if it's better than ad-hoc conversations. Too bad their UX is too cluttered. I hear Basecamp has similar functionality.
[0] https://gitlab.com/gitlab-org/gitlab-ce/issues
Gitlab seems to do this[0] and I'm curious if it's better than ad-hoc conversations. Too bad their UX is too cluttered. I hear Basecamp has similar functionality.
[0] https://gitlab.com/gitlab-org/gitlab-ce/issues
I can't imagine that being a good idea -- people form friendships in the office, or they just need to have a private conversation -- it seems like it would be weird and draconian to forbid that kind of thing because something important might be in a private chat.
Ah, I meant forbidding them in the sense that the culture of the organization would discourage people from talking about work related things in a "work context" via ad-hoc messages, not that people literally or practically wouldn't be allowed to message each other. I agree, that would be draconian.
Do you have a suggestion to make our UX work better for you?
I realize that I am nitpicking the nitpicking here...
> JIRA has a screen real estate problem. Have you seen the articles about SERP shrinkage, where a G results page in 2004 was mostly results and now it’s mostly ads? JIRA started out this way. 90% of the text on the screen isn’t your project’s information, it’s JIRA chrome.
Press "z" and "[" in JIRA Cloud to hide the top filter bar and sidebar, respectively, when viewing a project board. These were the first shortcuts I learned after the redesign about a year ago.
> JIRA has a screen real estate problem. Have you seen the articles about SERP shrinkage, where a G results page in 2004 was mostly results and now it’s mostly ads? JIRA started out this way. 90% of the text on the screen isn’t your project’s information, it’s JIRA chrome.
Press "z" and "[" in JIRA Cloud to hide the top filter bar and sidebar, respectively, when viewing a project board. These were the first shortcuts I learned after the redesign about a year ago.
The "organisational memory" point is one of the driving factors behind the tool / startup I'm building.
https://getctx.io
tl;dr - It's basically all the good bits of Enterprise Search, but set up to pull in the data from the cloud based SaaS tools we all use in 2018, and designed for digital / product teams.
The rationale is, I think that there is no sensible, central place for a company to store all the types of info they have. Slack doesn't do it all, Confluence, JIRA or Trello aren't enough, Google Drive is good for some things...
In my experience (and from many people I've surveyed and spoken to) most companies end up with loads of these tools, and it's a nightmare to find specific pieces of content when you have 5+ options for where it could be.
The answer isn't one tool to rule 'em all - it has to be an abstraction - make the data available but store it (master it) in the various locations.
So, my product indexes Trello, Slack, Google Drive, GitHub and email (and, in beta, JIRA). It'd be great to get some HN-style feedback :-)
https://getctx.io
tl;dr - It's basically all the good bits of Enterprise Search, but set up to pull in the data from the cloud based SaaS tools we all use in 2018, and designed for digital / product teams.
The rationale is, I think that there is no sensible, central place for a company to store all the types of info they have. Slack doesn't do it all, Confluence, JIRA or Trello aren't enough, Google Drive is good for some things...
In my experience (and from many people I've surveyed and spoken to) most companies end up with loads of these tools, and it's a nightmare to find specific pieces of content when you have 5+ options for where it could be.
The answer isn't one tool to rule 'em all - it has to be an abstraction - make the data available but store it (master it) in the various locations.
So, my product indexes Trello, Slack, Google Drive, GitHub and email (and, in beta, JIRA). It'd be great to get some HN-style feedback :-)
Can anyone please explain why Slack is so popular?
Isn't it just another IM chat? I've tried it a couple of times and found nothing special about it.
Also, in all companies I worked at they either had Lync or Skype (because Enterprise, Windows, Office suite etc.).
Even if company decides to try some fancy IM, isn't it better to switch to Atlassian HipChat as it gives nice integration with JIRA, Confluence, Bamboo, BitBucket (assuming company uses Atlassian toolchain)?
Isn't it just another IM chat? I've tried it a couple of times and found nothing special about it.
Also, in all companies I worked at they either had Lync or Skype (because Enterprise, Windows, Office suite etc.).
Even if company decides to try some fancy IM, isn't it better to switch to Atlassian HipChat as it gives nice integration with JIRA, Confluence, Bamboo, BitBucket (assuming company uses Atlassian toolchain)?
It's viral business model, phone/desktop apps, and integrations have made it a leader in workplace messaging. Hooks you with free and hits the sweet spot of UX.
It's a high-quality product. My current employer uses Bitbucket for compliance reasons (I wrote the compliance tooling for my previous employer to use Slack) and while it works great, it's just worse in several small papercutty ways.
Having a pleasant product causes people to be more likely to use it during the initial migration phase, which increases network effects, which is important for a successful communication system.
Having a pleasant product causes people to be more likely to use it during the initial migration phase, which increases network effects, which is important for a successful communication system.
Same experience. Coupled with the pricing imo it defies logic why Slack is popular but good for them I guess.
In any team development context you need a way of interrupting people when blocked, so regardless of whether it is slack or skype or something else, you will need some chat-like tool, unless everyone sits in the same office every day. That doesn’t mean that pointless interruptions should be encouraged or even allowed. I’ve always made it a policy of telling people in chat to send me an email if their question was not blocking, but that only works if your manager allows it.
Another aspect here is to what degree these tools are introduced for the right reasons. I’ve seen from the inside (facility services industry) how open plan offices and flex desks are pushed for cost reasons (fewer sq. m. per employee) while being marketed as promoting team interaction (studies show it harms productivity more than helping). Cost is a bad reason, but at least it has an internal logic. But then you get people who see everyone is going to open plan and move to open plan also but with lots of empty space, nullifying the cost advantage and keeping only the downsides. Maybe with slack there’s also a degree of cargo culting going on.
Another aspect here is to what degree these tools are introduced for the right reasons. I’ve seen from the inside (facility services industry) how open plan offices and flex desks are pushed for cost reasons (fewer sq. m. per employee) while being marketed as promoting team interaction (studies show it harms productivity more than helping). Cost is a bad reason, but at least it has an internal logic. But then you get people who see everyone is going to open plan and move to open plan also but with lots of empty space, nullifying the cost advantage and keeping only the downsides. Maybe with slack there’s also a degree of cargo culting going on.
Mediums create expectations around availability, presence, and response times.
Phone (excluding VOIP): availability is not expected, but once call is picked up, response is immediate.
Email: availability is guaranteed (if you know their email), and a response times range from minutes to next day.
IM / Slack: Availability is known and a response expected in the seconds / minutes range if you are available.
It comes down to using the right tool for the job@ "hej Jeb, you in the office?" - use IM.
Then go over to Jeb's office to continue the discussion on whether to go with solution A or solution B. Its an indepth discussion that takes over an hour and Jeb closes his door so the two of you can discuss without interruption.
Back in your own office, you email Jeb with a summary of the discussion and the points agreed.
Jeb calls back saying "hey, i'm not sure about para X"... You discuss it over the phone, issue is resolved in a couple of minutes. You post the updated document to the internal wiki and email the team.
Feeling productive, you decide its time for a coffee, you slack the channel asking who would care to join you.
When a company normalises the expectation of getting a response to anything in seconds, interruptions happen all the time and productivity takes a hit.
Also, I hate open offices and thank heavens I only have had to work in one for a few months. The only true progress we ever made was going through the lunch menus of all the nearby restuarants.
On the other hand having say, a handful of people in a room (three or four) is a good balance between the chaos of open office (and real estate cost efficiencies) and giving everyone their own (potentially isolating) office.
Phone (excluding VOIP): availability is not expected, but once call is picked up, response is immediate.
Email: availability is guaranteed (if you know their email), and a response times range from minutes to next day.
IM / Slack: Availability is known and a response expected in the seconds / minutes range if you are available.
It comes down to using the right tool for the job@ "hej Jeb, you in the office?" - use IM.
Then go over to Jeb's office to continue the discussion on whether to go with solution A or solution B. Its an indepth discussion that takes over an hour and Jeb closes his door so the two of you can discuss without interruption.
Back in your own office, you email Jeb with a summary of the discussion and the points agreed.
Jeb calls back saying "hey, i'm not sure about para X"... You discuss it over the phone, issue is resolved in a couple of minutes. You post the updated document to the internal wiki and email the team.
Feeling productive, you decide its time for a coffee, you slack the channel asking who would care to join you.
When a company normalises the expectation of getting a response to anything in seconds, interruptions happen all the time and productivity takes a hit.
Also, I hate open offices and thank heavens I only have had to work in one for a few months. The only true progress we ever made was going through the lunch menus of all the nearby restuarants.
On the other hand having say, a handful of people in a room (three or four) is a good balance between the chaos of open office (and real estate cost efficiencies) and giving everyone their own (potentially isolating) office.
My approach to Slack is to treat it like email.
It lives in an open browser tab during work hours, tucked away in a corner of the screen where I can't see the "IMPORTANT! EMERGENCY!!! READ ME NOW!!!" warning that is permanently on in the icon. From time to time, when I'm at a natural stopping point, I'll check email then I'll check Slack.
Never allow it to send notifications or make noise. Certainly never install any form of native client. That means it's not on your phone or tablet (since the web version doesn't work on mobile devices anymore). That means it can't seek your attention when you're not in your office.
It'll send little digest mails if you forget about it for a whole day. For me, that's enough to remind me that it exists and that I should open a Slack window as part of my morning email spin.
I've worked with people who have alerts turned on for things, and they can't even hold a conversation for all the bongling going on on their devices. It seems unbearable.
It lives in an open browser tab during work hours, tucked away in a corner of the screen where I can't see the "IMPORTANT! EMERGENCY!!! READ ME NOW!!!" warning that is permanently on in the icon. From time to time, when I'm at a natural stopping point, I'll check email then I'll check Slack.
Never allow it to send notifications or make noise. Certainly never install any form of native client. That means it's not on your phone or tablet (since the web version doesn't work on mobile devices anymore). That means it can't seek your attention when you're not in your office.
It'll send little digest mails if you forget about it for a whole day. For me, that's enough to remind me that it exists and that I should open a Slack window as part of my morning email spin.
I've worked with people who have alerts turned on for things, and they can't even hold a conversation for all the bongling going on on their devices. It seems unbearable.
From my understanding Slack at large organizations (10+ employees) don't make organizations more productive at all. At the place that I work slack is relatively manageable for the most part. For me to make slack useful I just turned off all of the chatrooms and everything and make it so that I only check if it I get @ notified.
There are weird parts of slack by default that seem to be designed to make you less productive. Why does the #random channel exist at all? Sure it should cordon off off topic conversations and its designed by slack to increase engagement but is that what should be there by default?
For the most part though I see Slack as making me more productive. It is much easier to use than other alternatives. It has a great UI as long as you use the browser version (all of the native apps for linux are largely broken for me). If you are a large organization I think you would want to consider discord (yes I know its targeted for gamers) but it the react community uses it well in this regard.
There are weird parts of slack by default that seem to be designed to make you less productive. Why does the #random channel exist at all? Sure it should cordon off off topic conversations and its designed by slack to increase engagement but is that what should be there by default?
For the most part though I see Slack as making me more productive. It is much easier to use than other alternatives. It has a great UI as long as you use the browser version (all of the native apps for linux are largely broken for me). If you are a large organization I think you would want to consider discord (yes I know its targeted for gamers) but it the react community uses it well in this regard.
Slack is a tool, and it's all in how you use it. You and your team need to be disciplined and on the same page about how to use it.
As for handling organizational memory, we spin up channels as single discussion forums. It's easy enough to archive them when a conversation ends (usually lasting ~2 weeks from describing problem to everyone involved agreeing it was solved).
As for handling organizational memory, we spin up channels as single discussion forums. It's easy enough to archive them when a conversation ends (usually lasting ~2 weeks from describing problem to everyone involved agreeing it was solved).
I get the author’s frustration - especially with slack’s search features. But I think it’s possible to use slack as a tool for transient conversation and notifications. We routinely copy/paste slack chats in other tools (asana, docs, code comments) when we feel it’s something worth saving.
It does require discipline with tools usage though...
Well, this is why i disabled notification for Slack, so i did to everything else. I read emails when I want to read emails and so on. During meetings phones should be put on silent and this must be enforced. I think it is very simple to remain productive in a environment that has so many interruptions. You just need to follow basic principles.
This looks like a problem to be solved with something like a google search engine for all internal pages and wiki.
Perhaps we should start machine learning to start auto tagging discussions in Slack with the context they're being done in and then expose a search engine like interface to all of Slack conversations, wikis etc.
Perhaps we should start machine learning to start auto tagging discussions in Slack with the context they're being done in and then expose a search engine like interface to all of Slack conversations, wikis etc.
I think how to divide your rooms is key.
"development" or "engineering" is probably too vague. You may want more specific things: implementation, testing, release management, incidents and make sure people to stay on topic.
Then, have a channel for offtopic, informal things and let people ignore it.
"development" or "engineering" is probably too vague. You may want more specific things: implementation, testing, release management, incidents and make sure people to stay on topic.
Then, have a channel for offtopic, informal things and let people ignore it.
[deleted]
IMHO Slack should be used only as informal communication tool. Neither Slack nor Discord or others facilitate the most important part: long-term result from communication.
Why? People are used to WhatsApp, FB Messenger, etc. and chat these days is mostly without consequences. That also translates to Slack and others.
Effective communication producing results IMHO requires investment. Chat is the opposite of that.
Anecdotal part from various companies: Slack is mostly a place for slacking off, doing silly things or send "untraceable" reprimands (since free tier does not archive) long-term.
Organisation has to be company culture before using tools like Slack, or Slack will do you no good.
... feel free to replace Slack with any other messaging app.
Why? People are used to WhatsApp, FB Messenger, etc. and chat these days is mostly without consequences. That also translates to Slack and others.
Effective communication producing results IMHO requires investment. Chat is the opposite of that.
Anecdotal part from various companies: Slack is mostly a place for slacking off, doing silly things or send "untraceable" reprimands (since free tier does not archive) long-term.
Organisation has to be company culture before using tools like Slack, or Slack will do you no good.
... feel free to replace Slack with any other messaging app.
I miss not having team chat. People figured stuff out and felt it was important enough to document... failing that they got up and walked over. This was 2003ish.
Now I end up either being drained by lack-of-effort questions all day on chat, or being reprinanded for not being available on chat. I never progress in my career, and in my mind there's an obvious correlation. I am talented and have one point of focus, which is a good point of attack for aspiring colleagues (effectively competitors, sadly). I can get better at saying no, but it doesn't fly well as most senior member most of the time because I'm called a "blocker".
Now I end up either being drained by lack-of-effort questions all day on chat, or being reprinanded for not being available on chat. I never progress in my career, and in my mind there's an obvious correlation. I am talented and have one point of focus, which is a good point of attack for aspiring colleagues (effectively competitors, sadly). I can get better at saying no, but it doesn't fly well as most senior member most of the time because I'm called a "blocker".
my slack strategies lately:
* mute everything, except my team's chat;
* turn off the "is typing" feedback;
* use the web version in a standalone browser (eats 200mb ram only instead of 2+gb, in srware iron at least);
* mute colors with custom "theme";
* turn off emoji display (falls back to :foo: :bar:);
* remove the rest of the emojis with greasemonkey extension (and mute more colors);
* collapse documents by default (really helps with big animated gifs).
But I still am trying to cope with some of the problems mentioned in the article and sometimes I have this feeling that I'm part of the problem (expecting fast replies, whining at times, not being constructive enough etc).
* mute everything, except my team's chat;
* turn off the "is typing" feedback;
* use the web version in a standalone browser (eats 200mb ram only instead of 2+gb, in srware iron at least);
* mute colors with custom "theme";
* turn off emoji display (falls back to :foo: :bar:);
* remove the rest of the emojis with greasemonkey extension (and mute more colors);
* collapse documents by default (really helps with big animated gifs).
But I still am trying to cope with some of the problems mentioned in the article and sometimes I have this feeling that I'm part of the problem (expecting fast replies, whining at times, not being constructive enough etc).
Never used Slack but I've followed the cycle from little tool that could, to hip tech buzzword, to celebrity startup and now seemingly back down to...do we really need this?
I wonder what will come next.
I wonder what will come next.
OMG: this guy is 100% right about JIRA.
About SLACK; well, it can be used responsibly, if you set ground rules. Honestly, I've never used it within a team, but across teams. So I never had the problems he's describing. I can see how it would be abused that way. But you have the senior leaders set ground rules on usage. (doesn't solve the search problems).
Chat is a tool. It can be used responsibly to be helpful, or it can be misused to fuck shit up. Just like any tool.
About SLACK; well, it can be used responsibly, if you set ground rules. Honestly, I've never used it within a team, but across teams. So I never had the problems he's describing. I can see how it would be abused that way. But you have the senior leaders set ground rules on usage. (doesn't solve the search problems).
Chat is a tool. It can be used responsibly to be helpful, or it can be misused to fuck shit up. Just like any tool.
This assumes everybody's in the same office. Slack has tremendously improved my team's communication as we're spread across many university buildings.
Wow, this is the most dystopian take possible regarding Slack. Half the time I can't tell if they're arguing against real-time chat or for IRC.
In any case I think that you could easily argue that most of these things depend on your organization and what use cases you have for Slack. But wow, I'm having a hard time visualizing how it could be this bad.
Before Slack, my org had no centralized communication. That sucked way worse than having Slack.
In any case I think that you could easily argue that most of these things depend on your organization and what use cases you have for Slack. But wow, I'm having a hard time visualizing how it could be this bad.
Before Slack, my org had no centralized communication. That sucked way worse than having Slack.
Reading through this thread, it seems like Slack is really missing more fine-grained control over channel permissions.
There are largely four types of communication and they need four different permission designs:
* Important and immediate - stuff like production monitoring and incident resolution. These channels should typically be quiet but they should have the power to notify and interrupt people doing normal work when activity happens. If you have support channels, they should be staffed by dedicated support people whose primary job is to be interrupted by support requests, and not engineers trying to buckle down on their work.
* Important but not immediate - ordinary corporate alignment discussions. These channels should be globally administratively enforced as read-only except for predefined, enforced "meeting hours" which are blocked out organization-wide on everybody's calendar, which is when discussion on issues actually happens. If people have an issue they need to bring up on a particular topic, it can wait until tomorrow, and not interrupt engineers trying to get their work done. People no longer mute these channels because they're not interrupting them during get-work-done hours. If it's too difficult to follow the "meeting" in a dozen different channels then it's probably a sign that your organization has you in charge of too many responsibilities and you should stop looking at the tool as a means of fixing your organizational problems.
* Not important (and either immediate or not immediately): there's a time and place for watercooler channels, and it's not interrupting you in your cubicle. Notifications should be globally administratively disabled entirely for these channels, for everyone, including the people who care about following along in those channels, because nobody should be standing around the watercooler all day long.
Slack's product teams should be looking at mute as a sign of failure that says "either this tool or this tool's configuration is preventing me from doing my job" and the product team should respond accordingly (remember: tool misconfigurations are an admin UX failure that harms your product by damaging its reputation, and you should fix the UX failure that lead to the misconfiguration so as to protect your product's reputation). The only mute button in Slack should be a Slack-wide mute button for vacation etc.
There are largely four types of communication and they need four different permission designs:
* Important and immediate - stuff like production monitoring and incident resolution. These channels should typically be quiet but they should have the power to notify and interrupt people doing normal work when activity happens. If you have support channels, they should be staffed by dedicated support people whose primary job is to be interrupted by support requests, and not engineers trying to buckle down on their work.
* Important but not immediate - ordinary corporate alignment discussions. These channels should be globally administratively enforced as read-only except for predefined, enforced "meeting hours" which are blocked out organization-wide on everybody's calendar, which is when discussion on issues actually happens. If people have an issue they need to bring up on a particular topic, it can wait until tomorrow, and not interrupt engineers trying to get their work done. People no longer mute these channels because they're not interrupting them during get-work-done hours. If it's too difficult to follow the "meeting" in a dozen different channels then it's probably a sign that your organization has you in charge of too many responsibilities and you should stop looking at the tool as a means of fixing your organizational problems.
* Not important (and either immediate or not immediately): there's a time and place for watercooler channels, and it's not interrupting you in your cubicle. Notifications should be globally administratively disabled entirely for these channels, for everyone, including the people who care about following along in those channels, because nobody should be standing around the watercooler all day long.
Slack's product teams should be looking at mute as a sign of failure that says "either this tool or this tool's configuration is preventing me from doing my job" and the product team should respond accordingly (remember: tool misconfigurations are an admin UX failure that harms your product by damaging its reputation, and you should fix the UX failure that lead to the misconfiguration so as to protect your product's reputation). The only mute button in Slack should be a Slack-wide mute button for vacation etc.
I think something useful could be implemented using a distributed model. No server, no company, just a network of nodes communicating together using the Internet as it was originally intended to be used. No one makes money on email and no one should make money on chat.
The underlying implementation could use Git, which would preserve history and give everyone a complete copy of the repository.
The underlying implementation could use Git, which would preserve history and give everyone a complete copy of the repository.
Slack, like all tools with built-in notifications, works out much better for me when I disable the notifications.
I alt+tab to the window now and then to see if anyone's trying to get my attention and it tells me who, and how many unreads I have.
The key is to not have the notification sound/popup and I can just bury Slack under my editor, browser etc until I decide I'm available.
I alt+tab to the window now and then to see if anyone's trying to get my attention and it tells me who, and how many unreads I have.
The key is to not have the notification sound/popup and I can just bury Slack under my editor, browser etc until I decide I'm available.
Easy to say Slack, JIRA, Trello suck, but what are the alternatives? I used IRC at two 1000 person companies. It was useful, but didn't replace email like slack does now. Likely due to lack of persistence, absence on phones and hard to setup integrations.
Echoing a lot of the comments, you can blame tools for altering the culture. Phones disrupted memos, email ended vacuum tube delivery, computers killed the file cabinet. Slack is a reflection of our short attention spans. No one wants to read long emails. People need an easy way to message and get notified on all screens. People pass screen shots across their devices. It solves problems. I've seen people who abuse @mentions and @here, but ultimately you develop filters and need to take responsibility for one's own workflow.
I do hear how Slack isn't good at making organizational events searchable and good at archiving in corporate memory. Problem space is: need to search, recall, store and archive better. Maybe tools to record this into some record or doc, (i.e. readthedocs). You can argue Facebook/Yammer style status posts is a better way to broadcast and save announcements. Slack can innovate on UX, but they seeme focused on growth and quality of service. They're not looking to solve small issues at this time.
Echoing a lot of the comments, you can blame tools for altering the culture. Phones disrupted memos, email ended vacuum tube delivery, computers killed the file cabinet. Slack is a reflection of our short attention spans. No one wants to read long emails. People need an easy way to message and get notified on all screens. People pass screen shots across their devices. It solves problems. I've seen people who abuse @mentions and @here, but ultimately you develop filters and need to take responsibility for one's own workflow.
I do hear how Slack isn't good at making organizational events searchable and good at archiving in corporate memory. Problem space is: need to search, recall, store and archive better. Maybe tools to record this into some record or doc, (i.e. readthedocs). You can argue Facebook/Yammer style status posts is a better way to broadcast and save announcements. Slack can innovate on UX, but they seeme focused on growth and quality of service. They're not looking to solve small issues at this time.
This isn't really about Slack, it's about the whole paradigm. Maybe it's even OPs fault that he phrases it this way, but anyhow, if it really would be about Slack it would imply that something like Facebook Workplace is any better, but in reality it's infinitely worse on about every possible aspect and beyond. Even by OPs own metrics.
So it's more about how "emails would be better", and surely not about "how to replace them". Not sure if I agree or disagree though.
So it's more about how "emails would be better", and surely not about "how to replace them". Not sure if I agree or disagree though.
Had Workplace in my last job, just started a new one which uses Slack.
I do not in any shape or form miss Workplace. It was sucking my attention dry, blocking meant I'd lose out on things that actually matter.
With Slack it's super easy to set notifications to null except for eg mentions or important groups - and can even have different defaults for mobile vs desktop.
I do not in any shape or form miss Workplace. It was sucking my attention dry, blocking meant I'd lose out on things that actually matter.
With Slack it's super easy to set notifications to null except for eg mentions or important groups - and can even have different defaults for mobile vs desktop.
Yes, it's horrible. I actually do set all notifications off, which is borderline rude and arrogant of me, but otherwise my "working hours" would be pretty much pointless.
For me, actually, the worst part is the shittiest chat app I've ever seen bar none, especially on desktop. There's no decent app for Linux, browser app is slow, buggy and constantly leaks memory, the most basic features that, I'd think are mandatory for any modern chat-app are missing, UI just totally sucks. It's hard to imagine someone could make an IM-app so bad by chance.
For me, actually, the worst part is the shittiest chat app I've ever seen bar none, especially on desktop. There's no decent app for Linux, browser app is slow, buggy and constantly leaks memory, the most basic features that, I'd think are mandatory for any modern chat-app are missing, UI just totally sucks. It's hard to imagine someone could make an IM-app so bad by chance.
“If you can’t dance, don’t blame (it on) the (dance) floor”
There is communication bottleneck in any large team. The goal should be to maximize information sharing and minimize communication.
Communication is scare resource and the use should have budget to create incentives to save it. Maybe someone can use blockchain hype to create that monetizes messaging inside companies.
Communication is scare resource and the use should have budget to create incentives to save it. Maybe someone can use blockchain hype to create that monetizes messaging inside companies.
Like anything, this is a people problem. I have no issue with Slack because I have no issue with it personally, because there is no fanatic focus on this thing in my company.
If it is a problem, it's probably easy to start solving it: don't use it.
If it is a problem, it's probably easy to start solving it: don't use it.
What about the argument that since email is built atop an open standard, you can (theoretically) migrate to different email servers and clients, but with Slack, your "organizational memory" is owned by Slack?
The "ADD" that Slack creates might be the killer feature. I suspect that many middle managers may not know how to organize work, and this lets them get away from that.
The name Slack becomes even more ironic in this context.
The name Slack becomes even more ironic in this context.
[deleted]
Is anytime using Zulip and would care to comment about your experience?
We are at my org, but my only exposure is cross-team / cross-division chatter. I collaborate with my team across offices through an old Jabber client. This isn't ideal, but pulling it away from a browser window allows you to disconnect, set DND status, that sort of thing.
Zulip's focus on streams & discussion topics (over people-groups) is terrifically handy for tuning into large-scale group chatter, looking at things that are interesting to you and sharing conversations with others. Project/task management via Slack or any similar tools just seems bonkers to me.
Zulip's focus on streams & discussion topics (over people-groups) is terrifically handy for tuning into large-scale group chatter, looking at things that are interesting to you and sharing conversations with others. Project/task management via Slack or any similar tools just seems bonkers to me.
We tried Zulip for a week but the team decided to not continue the experiment. I personally really liked the UI and the keyboard-centric workflow, but the lack of polished UI and the suboptimal mobile experience was really difficult to defend.
Another problem is that we would often end up replying to the wrong thread because of the way the general view is organized.
We are now trying Twist (https://twistapp.com) and it is a very good compromise between the efficiency of Zulip and the polished UI of Slack. The main advantage over Zulip is that you only see one complete thread at a time in the main column, but you can see the last message of each thread you've subscribed to in your inbox (second column): when you hit reply, you are certain that you are replying to the right thread.
Another problem is that we would often end up replying to the wrong thread because of the way the general view is organized.
We are now trying Twist (https://twistapp.com) and it is a very good compromise between the efficiency of Zulip and the polished UI of Slack. The main advantage over Zulip is that you only see one complete thread at a time in the main column, but you can see the last message of each thread you've subscribed to in your inbox (second column): when you hit reply, you are certain that you are replying to the right thread.
I one time kept saying that one shouldn't have a General forum - but no one understood.
The only way to have the desired archive structures is to not have a dumping ground. Non of any kind.
The only way to have the desired archive structures is to not have a dumping ground. Non of any kind.
Yes— and that’s ok. Slack is more like organizational RAM.
“it’s like having an old man pee on your face one trickle at a time. I’d rather have it over with quickly and go wash up.”
I think we’ve all been there.
I think we’ve all been there.
Slack is a tool, just like kitchen knife is. Used correctly, it is valuable. Otherwise, I agree with all you said.
Great post. Hits exactly the sore point of working in today's environment.
Slack should be used as a CLI for your business. It not only a chat room.
If you want documentation, then add a command for `/doc "title"` and start a collaborative document.
If you want to add a task, `/task add "title"`
etc.
Its a shared command line, not only chat.
If you want documentation, then add a command for `/doc "title"` and start a collaborative document.
If you want to add a task, `/task add "title"`
etc.
Its a shared command line, not only chat.
/giphy amen
Relay is a Slack alternative: https://www.relay-chat.com
So far, a Relay organization is a hosted Mattermost instance. Slack isn't exactly revolutionary software and it seems silly that persistent IRC (that's all Slack is) should cost so much money or run on a proprietary, users-as-inventory, data-gobbling platform.
1. Why does Relay exist?
We built Relay for precisely this reason. Mattermost is pretty cool but we (nilenso.com) are not a military contractor or a bank. We didn't need Mattermost hidden deep in our datacenter; we just wanted hosted Mattermost so we could stop handing over every byte of our internal data to Slack, Inc.
If Relay existed a year ago, we would have paid for it. So we built it (for) ourselves.
2. What's the plan, Stan?
As long as we can, we want to stay in sync with the Mattermost mainline. All our code is open source (https://gitlab.com/nilenso/relay-backend and https://gitlab.com/nilenso/relay-ops so far) but we'd like it if our users could move to their own self-hosted Mattermost instance as easily as a self-hosted Relay instance.
We have some pretty specific near-term plans: First, Integrations are a pain with Mattermost and we'll be releasing a server to make that a one-click operation (like it is on Slack) soon. Second, a fully-automated (one-click) Matterbridge server so you can migrate from Slack slowly or keep or IRC users happy.
But beyond that? We're not sure. There are some UI/UX bugs that annoy us (especially on the Mattermost/Relay mobile clients). Some of the issues Abe mentions are low-hanging usability fruit, but from a lot of the replies on this thread, it sounds like not everyone feels the pain. It's not immediately obvious to use what we should prioritize; we don't have an issue people at nilenso sending us photos of their cats, for example. We're probably far from the norm, though.
If you want to shout at us about how we can fix Relay (née Slack) and, as a consequence, Mattermost, usability we'd really like to hear it. This is our 9-to-5.
Shout on Twitter: https://twitter.com/relay_chat/status/962936101919838208
Shout on Open Relay [1]: https://open.relay-chat.com/signup_email
Or shout on this thread, obviously.
Thanks HN.
-steven
[1] This is our open Relay server. Create channels, teams, whatever. Think Freenode or any other community IRC network. No 10k message limits or any of that garbage (it seems insane to me that language communities like Elixir and Clojure moved chat to Slack, given this restriction).
So far, a Relay organization is a hosted Mattermost instance. Slack isn't exactly revolutionary software and it seems silly that persistent IRC (that's all Slack is) should cost so much money or run on a proprietary, users-as-inventory, data-gobbling platform.
1. Why does Relay exist?
We built Relay for precisely this reason. Mattermost is pretty cool but we (nilenso.com) are not a military contractor or a bank. We didn't need Mattermost hidden deep in our datacenter; we just wanted hosted Mattermost so we could stop handing over every byte of our internal data to Slack, Inc.
If Relay existed a year ago, we would have paid for it. So we built it (for) ourselves.
2. What's the plan, Stan?
As long as we can, we want to stay in sync with the Mattermost mainline. All our code is open source (https://gitlab.com/nilenso/relay-backend and https://gitlab.com/nilenso/relay-ops so far) but we'd like it if our users could move to their own self-hosted Mattermost instance as easily as a self-hosted Relay instance.
We have some pretty specific near-term plans: First, Integrations are a pain with Mattermost and we'll be releasing a server to make that a one-click operation (like it is on Slack) soon. Second, a fully-automated (one-click) Matterbridge server so you can migrate from Slack slowly or keep or IRC users happy.
But beyond that? We're not sure. There are some UI/UX bugs that annoy us (especially on the Mattermost/Relay mobile clients). Some of the issues Abe mentions are low-hanging usability fruit, but from a lot of the replies on this thread, it sounds like not everyone feels the pain. It's not immediately obvious to use what we should prioritize; we don't have an issue people at nilenso sending us photos of their cats, for example. We're probably far from the norm, though.
If you want to shout at us about how we can fix Relay (née Slack) and, as a consequence, Mattermost, usability we'd really like to hear it. This is our 9-to-5.
Shout on Twitter: https://twitter.com/relay_chat/status/962936101919838208
Shout on Open Relay [1]: https://open.relay-chat.com/signup_email
Or shout on this thread, obviously.
Thanks HN.
-steven
[1] This is our open Relay server. Create channels, teams, whatever. Think Freenode or any other community IRC network. No 10k message limits or any of that garbage (it seems insane to me that language communities like Elixir and Clojure moved chat to Slack, given this restriction).
philwelch(2)
I think people forget what it was like before Slack. Sitting down to 30+ emails by 9:00AM and over 200 in a single day. It was death by email threads and following them was a horrible time suck. Worse off, email was treated like a real time conversation so you were expected to tracking it all the time through the day.
Slack solves a lot of this. The channels are opt in. If you don't want to follow something, just leave. Email is now just for async messages and is less of a distraction during core hours.
If your team or Co uses one channel for all your discussions, then I suggest that you find a way to split out the primary topics in a way that lets everyone filter the wheat from the chaff.
Like others are saying, don't blame the tools for being misused. Ultimately you have to learn how to efficiently communicate with your team and be disciplined enough to know what tool to use for each type of task.
Slack solves a lot of this. The channels are opt in. If you don't want to follow something, just leave. Email is now just for async messages and is less of a distraction during core hours.
If your team or Co uses one channel for all your discussions, then I suggest that you find a way to split out the primary topics in a way that lets everyone filter the wheat from the chaff.
Like others are saying, don't blame the tools for being misused. Ultimately you have to learn how to efficiently communicate with your team and be disciplined enough to know what tool to use for each type of task.
Agree 100% on the last para.
My issue with Slack in our organisation (a University), is that people spawn off new teams for everything, and nobody has a paid group, because it's too expensive with our budgets, so you lose the conversations by age at 20000 messages.
This has led to the situation where I'm in (a) My research group's group (b) One for people who program within the University (c) One for a side project I'm involved in (d) Slack channels for some software I use as dependency in my own project (e) One for a language specific group (f) One which is a group we share with collaborators at other Universities (g) About 5 more that have now been abandoned.
And because of that, I end up just turning off Slack all day and checking it in the evening, because I don't find it conducive to research work where I mostly work independently anyway.
This has led to the situation where I'm in (a) My research group's group (b) One for people who program within the University (c) One for a side project I'm involved in (d) Slack channels for some software I use as dependency in my own project (e) One for a language specific group (f) One which is a group we share with collaborators at other Universities (g) About 5 more that have now been abandoned.
And because of that, I end up just turning off Slack all day and checking it in the evening, because I don't find it conducive to research work where I mostly work independently anyway.
Slack is a tool for productivity. (Go on––I'll give you a minute to laugh.)
Slack does make it easier to talk to people, particularly so in a group setting. Any company can make use of that; if you are a remote company, you need that. JIRA and Trello are also mentioned as "hates", but these are also tools that make it easier to work (notably, to make it easier to organize and catalog work). If you aren't using them, you've probably written a hack that does something like them, only worse.