Slack is the opposite of organizational memory
abe-winter.github.io
abe-winter.github.io
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.
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.
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.)
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 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.
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.
No, you don't.
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.
I'm fairly sure you can set do-not-disturb times as well.
/dnd, per-channel notif muting, and "away" status combine for reasonably fine-grained control
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
> A good alternative to Slack would be a Reddit-like interface with threads and an asynchronous model.
You're describing Twist -- twistapp.com.
It's an awesome chat application, of course. Not as much of a fan of it as a document store.
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?)
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.
Right, wasn’t it originally Single Log of All Chat Knowledge or some acronym like that?
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.
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.
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.
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
"Aww, all it takes is a little discipline." Yeah or I can set myself up to succeed.
Good contribution, rdiddly.
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.
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.
Not if you hire veterans.
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?
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.
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.
I don't know what kind of place you work at, but being a team player isn't measured by always being on Slack.
> > But as for Slack, you DO have to be a team player.
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.
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.
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.
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!
Coming back later really doesn't help (at least for me). Because chats are interspersed throughout, you can't really follow/search anything.
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.
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
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.
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.
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.
> 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.
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.
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!
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.
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.
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?"
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.
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.
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 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.
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.
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.
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 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.
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.
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.
(Life circumstances have me away from the startup life at the moment.)
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.
Disclaimer: Purely conjecture on my part. No particular knowledge of patent law, and only a high level understanding of the pagerant algorithm.
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.
Unfortunately, not documenting seems to be part of culture.
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.
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.
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.
As I get older I dislike meetings less, especially 1:1s. One-on-ones are usually the high point of my day.
The fact that this guy repeatedly refers to middle management kind of hints to me that he doesn't understand that culture aspect.
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.
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.
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."
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.
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.
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.
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?
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.
Asynchronous communication is empowering: You can choose when you communicate and when you want to concentrate. Synchronous communication does not afford you that luxury.
Is it just that short frequent messages in email feel weird?
If you can make your Slack non-interrupting, fantastic, but probably the advantages over email are slim.
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.
This is a feature. Slower back and forth means people put more thought into it and communicate better.
I've not used it before, but I can see the potential benefits of a tool like Huddle:
At the very least, tools like Huddle mean that discussions can be focused on the documents that a team are working on.
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...
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?
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.
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.
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.
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.
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.
Also, I mean, you can just turn it off or mute the notifications. I see people do that all the time and nobody cares.
Combine it with an Urgent channel if need be, where notifications are On, and tell people off for posting crap there..
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.
[/shameless plug]
A moment of gratitude to Stack Overflow and mailing lists!
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.
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.
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.
Ah. We have a different view of "classic forum software". NNTP was before my time.
Traditional meetings have secretaries and a procedure for approving minutes for this very reason.
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.
I especially don't like when Slack is used as an official record.
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).
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.
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 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.
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.
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.
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...
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?
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.
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.
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.
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.
> 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.
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 :-)
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)?
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.
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.
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.
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.
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.
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).
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.
"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.
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.
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".
* 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).
I wonder what will come next.
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.
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.
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.
The underlying implementation could use Git, which would preserve history and give everyone a complete copy of the repository.
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.
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.
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.
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.
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.
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.
If it is a problem, it's probably easy to start solving it: don't use it.
The name Slack becomes even more ironic in this context.
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.
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.
The only way to have the desired archive structures is to not have a dumping ground. Non of any kind.
I think we’ve all been there.
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.
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).
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.
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.