Why we’re betting against real-time team messaging

The biggest drawback of a real time communication tool like Slack is the React v&#x2F;s Respond conundrum.<p>Productive communication and teamwork requires that we respond, rather than react.<p>What happens specifically with tools like Slack which start off as demi-official tool and then transcend to official is that, one gets into the habit of reacting, instead of responding.<p>I have personally seen this &quot;fastest finger first&quot; played, almost always.<p>There has been tons of literature written on reacting v&#x2F;s responding and I need not dwell into it.<p>Another aspect is that there is no exit, once Slack is the primary communication tool. One is forced to use it, otherwise you are like an outcast and people more often tend to take it as a signal that the person is on its way out and hence moved away from Slack.<p>Rest of the drawbacks is documented in the article.

<i>A small, but impactful design choice we made in creating Twist was to leave out the online presence indicator.</i><p>I imagine you could address this in Slack by just having everyone set themselves to &#x27;Away&#x27; by default.<p>One of the things that I&#x27;ve found useful in Slack is turning off the &quot;Someone is typing&quot; message (the option is in the Display Options). I used to wait for someone to post if I knew a message was coming. Now I can drop in and out of a channel more easily. Similarly, I&#x27;ve muted almost all the channels I&#x27;m in so now I only <i>need</i> to check if someone notifies me.<p>The point I&#x27;m making is that Slack doesn&#x27;t necessarily work the way you want right away, and that you might need address a few cultural problems with the way your team uses it. You need to think about how your team communicates, consider <i>why</i> people do annoying things in it, and come up with solutions that work. At the most extreme that might be writing a competitor product but for most companies there just needs to be a little more tolerance of people not answering immediately and a little consideration that gifs can be unhelpful.

I worked at a Slack shop for several years, and share the author&#x27;s opinion.<p>I can&#x27;t think of any five minute period during my entire tenure where the Slack tab didn&#x27;t have a little red circle telling me that I absolutely needed to check it right this second. There was no way to filter notifications beyond &quot;Everything&quot;, so that little bubble would go up every time anybody in the company pressed a key. And heaven forbid somebody typed &quot;Good morning, @channel&quot; (which happened 20 times per morning per timezone), because then you&#x27;d get the dreaded Red Exclamation Mark in the tab.<p>I can&#x27;t fathom how anybody would have been able to work if they had gone as far as allowing notifications to be turned on and make noises at them every time Slack thought something Important Enough To Interrupt You had happened.

I like it. I&#x27;ve been thinking for a while that old-school forums are actually fundamentally superior to chatrooms for sharing important information and having in depth discussions.<p>In my opinion the chat model is simply bad for effectively distributing useful information because it disappears in the noise.<p>Perhaps what&#x27;s needed is a combination of the forum-style threaded conversation model for information sharing and work conversations and a chat room which is explicitly for the water-cooler stuff, so that people don&#x27;t have to be always-on (and constantly interrupted). It should be safe to turn off when you need to focus.

Curious question: Isn&#x27;t this an already solved problem? I&#x27;ve been using plain old emails and quiet free of all the problems of real-time messaging.<p>&quot;Thread-first communication&quot; - We have it. Email threads. I&#x27;ve been using Zoho Mail. It&#x27;s one step ahead and has modern concepts like streams&#x2F;commenting and sharing built around emails. Very useful.<p>&quot;Truly transparent conversations&quot; - What this means is, the knowledge has to be highly searchable. Also, not all threads have to be public. With emails, you can either broadcast an email company wide or you can opt to pull in relevant users into a conversation. Makes a lot of sense to <i>not</i> broadcast everything company-wide, isn&#x27;t it? More importantly, emails are easily searchable. Once received, I&#x27;m confident that it&#x27;s going to sit there in my inbox forever, without worrying if it&#x27;s going to be deleted later by someone who has authority.<p>&quot;Leaving out the online presence indicator&quot; - Exactly. Emails.<p>Maybe there&#x27;s some more important key aspects that the product&#x27;s covering up for me. As for me, I guess emails are simply good enough!

Congrats on finding a real problem and building something to solve it. You&#x27;re about to fight an uphill battle.<p>Here&#x27;s my feedback (from someone who currently leads the leads of 7 remote engineering teams):<p>• Not knowing if someone is available and if they will get back to you soon is very very bad for many conversations. For example, when you have a C-level asking for rapid turn around on something that needs to be done by someone multiple levels away from you.<p>• In remote teams, sometimes people disappear (e.g. car accident or civil unrest in a random country), and if you have no way to know, you&#x27;ll eventually get fed up.<p>• The feeling of cohesiveness that comes from having realtime conversations, brainstorms and other collaboration is very important to managers (especially in remote teams) and convincing them that realtime talk is not a good default is going to be quite hard.<p>• As a result you will never be their default communication channel - at most you&#x27;ll be the place they discuss bigger problems. But because you&#x27;re not the default, you&#x27;ll get destroyed by slack, who is the default. Most times people use the tool at hand that they are most familiar with, not the best tool for the job. I would encourage you to write a slack bot that reminds people to use you &amp; helps them easily experience value from your product without you having to win the default spot.<p>• Finally, most people will have serious difficulty seeing the difference between your product and other product management tools that allow commenting in detail on issues being discussed.

As an ex-IBMer with 10 years of dealing with Sametime, I find this discussion amusing. Just think of Slack but with 300,000+ in your team.<p>Sametime was a big part of IBM culture. IBMs work from home policy was tied up with it. At work means you are online and responsive to Sametime. A typical meeting involves people sitting in a conference room Sametiming comments to each other about the speaker.<p>One nice thing about Sametime is that you chat history is in XML files on your computer. This allows you to use grep to find past information.<p>IBM started to use Slack when I left. On the one hand this allows you to collaborate with people outside IBM, but downside is you need both tools running. Slack for the cool kids, Sametime for the old guys.<p>My new job is giving me a new experience- video conferences using Google Hangouts. Many times with googlers on the Google bus.

One interesting challenge with this real-time vs. async communication challenge is that different job roles have different needs. At my company, most of our employees have been on the customer service side until recently, and Slack is great for them. Almost everything they need to talk about is urgent (even if it&#x27;s not important) and temporary. They rarely have long-lasting high-level conversations.<p>Now we&#x27;re starting to hire more developers and I&#x27;m realizing how disruptive it is for them to be pulled into Slack conversations all the time. So I&#x27;ve started using email more for communicating with the devs, and that seems to work reasonably well.<p>The questions I have are: (a) is it possible to have a single communication tool that handles both real-time and async properly and (b) does that even matter? Maybe email+Slack is a perfectly fine solution. Either way, it&#x27;s obvious that only using Slack isn&#x27;t a viable option.

How is Twist (the product they announce in this post) much different from email? Besides not using open protocols? Don&#x27;t get me wrong, it looks like a beautifully designed email client. There are some interesting features here but it seems like you could do this all using existing email features. Am I wrong?<p>The choice of asynchronhous vs. synchronous is a false dichotomy. Development teams I have been on use a combination of both since forever. Before Slack&#x2F;Hipchat there was XMPP&#x2F;Jabber before that was IRC. It must be business people binging on the glory of synchronous communication then having a hangover. In my experience this has never been an issue.

There is a reason Jedi masters, powerful witches and wizards, ancient wise men and women, and so on tend to be found on isolated mountains, in remote caves, wandering in far away forests, and the like instead of living in the middle of the village with their doors open.

I cant help but draw parallels between this and NNTP. This is essentially a really nice skin over newgroups, and thats not a bad thing at all. We have seen just how successful a modern UX can be on a old protocol with slack providing a UX to IRC. It is funny that we are slowly reworking the tools of the early computing community in slick modern ways.<p>It is also interesting that we as a community have completely sold out federated independent operators with a common standards defined protocol for soloed tooling.

So basically a forum? Knowledge Management is a broad topic and it&#x27;s hilarious seeing the same solutions brought up again and again.<p>I have all this persistent information! New people need to get up to speed fast - where do I put it? Cue the Wiki fad.<p>I have to get things done and elicit quick feedback ASAP! Cue the Chat fad.<p>I want async communication so I&#x27;m not bogged down all the time! Email and Forums.<p>There&#x27;s a time and place for all of these.

&gt; But in reality, even I couldn’t keep track of all the conversations that were happening at the company.<p>Nor should you, really. Imagine trying to do that in an office-based organization! Slack, to me, is a bit like our digital office space.<p>You can also use highlight words to ensure you don&#x27;t miss any discussion on topics you&#x27;re particularly interested in. We have a guy who worked a lot with our billing, and he is magically always present whenever anyone says &quot;refund&quot;.

The problem with Slack and the like is that it&#x27;s communication based, not work based.<p>The problem with Todoist and Wunderlist and the like is that it&#x27;s work based, not communication based.<p>Slack is awesome at communicating. But it has no checklist, no todo, no collaboration tools that fulfill most needs. They&#x27;re all half baked.<p>Wunderlist has checklists and todos and can be used to track collaboration efforts by linking Google Docs or Sheets to a task for example, but communication is still horrible. It&#x27;s nowhere close to being a main communications channel.<p>So most end up using a combination of apps.<p>But this is also one of the greatest detriments to productivity. Having to juggle apps.

Slack reminds me of my school years, I grew up as cell phones became commonplace.<p>We&#x27;ve always had chat software, but mostly we talked to each other during breaks or after school using our desktop computers.<p>Then cell phones became normal, and SMS was normal, later on, it was chat apps, social media. Things sped up by a factor of a billion.<p>All of the sudden we have entire conversations happening as the teacher is lecturing, people are making weekend plans, gossiping, bullying, relationships are forming and falling apart in minutes time.<p>Honestly, I can&#x27;t even imagine what hell school must be now that everyone has social media and ephemeral messaging everywhere.<p>And I believe Slack did a little bit of this to the workplace, we&#x27;ve always had chat apps, but it was always a little bit to the side, but Slack integrated it with our work tools, now we have all these notifications from services bundled in the same software that offers you public channels, private channels, private groups and direct messaging, there is a whole new level of communication going on both on and off the record.<p>In some workplaces, I felt like it was school all over again.

This makes a good point that Slack can sometimes just be a better hamster wheel for time wasting. I have seen it work well as an emergency channel, where dev&#x27;s could quickly share info if a live app was having a problem. But at the same place, the most lively channel was an exchange of GIFs.

I think that Slack (or any other IM client for work, really) is just a tool, not a solution. Meaning that it requires some organization and thought, rather than installing and hoping for the best. At least to some extent (i.e. have no idea about companies with hundreds of engineers online), it works. Equally important it is to acknowledge what is suitable for doing on IM and what is not.<p>If you want to discuss some large changes, sure, IM is a bad place. Conversation will probably get interrupted, derailed, etc. That&#x27;s where, in my opinion, things like Google Docs or plain simple GH Issues shine. The format forces into better thought out, longer messages.<p>For other things, you need to organize the chat rooms. If you have 10+ people and 2 chat rooms (I think slack defaults to #general and #random) then yes, sounds bad. But instead having quite a few chat rooms with &lt;10 people each might work out well. Even having multiple rooms with the same people can be good to separate different topics of conversation.<p>&quot;Always on&quot;, I believe, comes not from the IM itself but from the culture of the company. I know places where everything is e-mail only and people constantly refresh it. Equally, IM is mostly ghost town outside working hours at other places. And Slack has decent notification settings to make sure that you don&#x27;t go crazy.<p>So, IM has it&#x27;s place and provides value if you are willing to make it work. It&#x27;s just not a &#x27;it just works&#x27; solution, which is hardly surprising.

We have seen many of these challenges over the years and set out to build something to help manage your team&#x27;s incoming requests — directly in Slack. We find it&#x27;s most used for internal assistance (one team supporting many) or as a way for B2B companies to provide support to their top customers.<p>The goal is to help your team be available and responsive without compromising productivity. To achieve this, incoming requests to a particular team are collected in a &quot;feed&quot; channel. The notifications ping specific people on rotation or on a sequence (according to rules) until claimed, the conversations are explicitly resolved with a &quot;closed&quot; action. We provide assistance for things like inserting knowledge base and template responses, and tagging the conversation. Integrations via Zapier mean a conversation can easily turn into an Asana task, Github issue, etc.<p>If you&#x27;re struggling to manage the chaos, give it a shot and see whether it helps.<p><a href="http:&#x2F;&#x2F;frame.ai&#x2F;beta&#x2F;" rel="nofollow">http:&#x2F;&#x2F;frame.ai&#x2F;beta&#x2F;</a>

All you need is a little self discipline, not a special app. Turn off notifications, check your messages when you&#x27;re taking a break, do not attempt to chat real time.<p>The only actually useful feature of this app seems to be that it&#x27;s thread oriented, but you can mitigate that with enough irc (okay, Slack these days) channels as well.

TL;DR they made a modernised version of an nntp client and server ;-)

This looks like a great tool, particularly the ground-up focus on threading and giving teams more options. As with its competitors, it can still easily become just another distraction when people use it wrong.<p>It&#x27;s easy to see how you could design a &quot;process&quot; around using something like Slack to achieve the same experience and if you don&#x27;t design a &quot;process&quot; for using Twist then it will suck just as much. We tried to heavily use channels in HipChat as a threading and noise-avoidance mechanism, it worked well but we often ended up with a lot of channels with the same people in; at which point discipline becomes stressed.

Yup, this guy gets it. Slack and other real-time messaging apps should be treated as a phone call or a knock on the door; an intentional interruption for something important enough to warrant a real time conversation.<p>Everything else should be handled through email, to allow people to consider and tailor their responses, to allow others to be added to the conversation through a CC: of a single focused thread, and to provide a directly searchable historical record of conversations.

I don&#x27;t think the fundamental problem is one of sync vs async communication. Of course synchronous communication is a flow killer, and of course having it as a team-wide or company-wide means of communication aggravates its problems. The async nature just makes it worse, as it has more bandwidth, and consumes more brain bandwidth as a result of more content than email and wider distribution than email.<p>The problem lies between unstructured and structured information. The problem is one of process vs flying by the seat of your pants. Ideally, you want processes for every repeatable action, and more flexible means of communication for new events that need to be handled quickly by those empowered to solve them.<p>However, every repeatable process starts as an one-off event: Customer requests for the same actions pile up until the moment you realize your app needs a new feature; Faults occur and get solved up until you realize you need to engineer a solution that prevents or automatically fixes them; Internal processes get lost and hang until you decide to redefine the internal workflow.<p>What is missing is a simple way of moving unstructured communication (sync and async), onto structured communication. Chats should end up as feature requests, bug reports, documentation or some other permanent medium that fits into the process.<p>If the unstructured-&gt;structured bridge is solved, you don&#x27;t have to monitor chats (or mailing lists, or forums). If they result in something meaningful, they will appear in the structured, process-oriented flow. Monitor that, and get involved in chats where you are directly mentioned. (and skip all gif chats, really)

Just went through Startup School that uses Mattermost, which seems to be a Slack clone (not sure since I never used Slack).<p>It didn&#x27;t seem to work well. Since all members of all groups were from all over the world and rarely shared a timezone, no conversation could really take place in real time.<p>And since there are no threads or topics or anything, it&#x27;s almost impossible to go back to something that was said a while ago.<p>I think a subreddit would have worked <i>much</i> better.

Apple took a step in the right direction with the do not disturb feature in the Notifications bar. When I don&#x27;t want to be bothered, I turn it on, when I want to be chatty I turn it off. The next step should be apps that are aware of your do not disturb state and update your presence (as an option) when it&#x27;s set. Then, I want a timer so I can get blasted with updates every 25 minutes like Pomodoro timer.

I have often considered setting up a local Reddit instance for my company for these very reasons. Has anyone done this with success?<p>I also considered creating some biz comm software myself, but only jotted down some ideas[0]<p>0 - <a href="https:&#x2F;&#x2F;bitbucket.org&#x2F;snippets&#x2F;cretz&#x2F;Xopoj&#x2F;retzle-conceptual" rel="nofollow">https:&#x2F;&#x2F;bitbucket.org&#x2F;snippets&#x2F;cretz&#x2F;Xopoj&#x2F;retzle-conceptual</a>

Their &quot;new&quot; approach sounds suspiciously like a mailing list: asynchronous communication for a group that supports threads of communication.

Where I work we&#x27;ve started using private categories on a Discourse instance for conversations that are &#x27;too big for Slack&#x27;. This works really well since Discourse has a selection of notification options (RSS feeds, email, Slack etc), keeps track of discussions well, has great search and has social features such as &#x27;liking&#x27; posts. Bonus points for being open source.

I like it. Basically the design choice was to focus on threads within channels, instead of simply channels. Slack has that thread feature but I never use it because it&#x27;s hard to follow. I guess slack could copy them and have a &quot;text mode&quot; and a &quot;thread mode&quot;, easily being able to switch between both, and then the threads will be much more useful.

I am the poster of this (and as you can see, I am an old HN user -- almost ten years here!)<p>I&#x27;ll be answering your questions. Thanks for the support!

From reading the top comments, an interesting conclusion is that messaging apps like Slack do not have drawbacks due to technical problems, but due to cultural problems.<p>These problems can be mitigated in a work environment where you can enforce cultural mores, but in a social environment (like within a group of friends or some other non-work related community) this becomes more challenging.<p>There is probably room in the market for a messaging app that prioritizes reaction communication and suggests that more thoughtful communication take place in a more permanent project management tool.

Google Wave?

Really nice post. We&#x27;ve suffered similar challenges using slack with our remote team and switched to Basecamp, which has been much better.<p>What&#x27;s your sense of how Twist and Basecamp compare?

In the early naughties, my company used an ultra-powerful tool that allows real-time discussion, archives conversation, allows search, sharing gifs.... An NNTP server.

This post reminds me of a similar one by the CEO of Basecamp giving his take on the problems with group chat and their solution to those problems.<p><a href="https:&#x2F;&#x2F;m.signalvnoise.com&#x2F;is-group-chat-making-you-sweat-744659addf7d" rel="nofollow">https:&#x2F;&#x2F;m.signalvnoise.com&#x2F;is-group-chat-making-you-sweat-74...</a><p>&gt; Group chat is like being in an all-day meeting with random participants and no agenda.

So you built Basecamp?

I would say the amount &#x2F; frequency of interaction depends on the team you work on.<p>If you work on larger features that require quiet time, then a real-time chatting app can be quite annoying. My team tends to release lots of small features very often, so fast communication is important.

Here&#x27;s how I prefer to use Slack:<p>1) Turn off notifications (except @mentions or DMs). 2) Code uninterrupted. 3) Check in when I&#x27;m taking a break. 4) Profit.<p>Our company culture is such that Slack is mostly for notifications from our toolset, so that probably helps. Also, we&#x27;re small (&lt; 20).

pretty much our whole company uses irc for real-time communication, and I don&#x27;t see that going away any time soon. it&#x27;s lightweight and does what you need it to

This reminds me very much of a classical forum. I wonder what the key differences to Discourse is and why they chose to built an entirely new project.

&gt; In theory, everyone on the team had access to all the communication that happened in public channels. But in reality, even I couldn’t keep track of all the conversations that were happening at the company. Whoever happened to be connected at the time could follow along and be involved in the decision-making. Everyone else might not even be aware that the conversation happened at all.<p>This sounds really creepy

&gt; Unlimited file storage for the team For 3.90&#x2F;mo charged per annum? How do you offer that?

This is an example of why I flatly refused to install an IM client at a former employer who wanted IT staff connected and instantly available. (The issue was laid to rest in a conference call when a co-worker said &quot;The nice thing about Dennis is that if he&#x27;s at his desk, he answers the phone on the first ring. If he&#x27;s not at his desk, you won&#x27;t get hin in IM, either!&quot; Bless him. He <i>got</i> it.)<p>The sort of stuff I did was mostly not user facing, since I was admin for the nix boxes, and not usually supporting Windows on the desktop. The things I did tended to require peace, quiet, and extended concentration to make sure I understood the problem and had created a working solution that wouldn&#x27;t blow up in someone&#x27;s face.<p>The underlying problem is that computers are good at multi-tasking, and humans <i>aren&#x27;t</i>. When a computer is handling multiple concurrent tasks, and an interrupt comes in, it must save its place in what it&#x27;s doing at the moment, handle the interrupt, then go back to the saved place and continue where it left off. It&#x27;s stack processing, computers are designed to do it well, and are generally fast enough that the user thinks the computer is only doing the task she&#x27;s working on. The overhead isn&#x27;t apparent.<p>Humans <i>aren&#x27;t</i> good at stack processing. I&#x27;ve seen papers from years back indicating the average developer can handle 5-7 parallel tracks at a time, and beyond that, things get lost. Stuff getting lost because the developer was trying to keep track of too many things were highly fertile sources of bugs.<p>And humans aren&#x27;t anywhere near as fast as computers. Conceptually, you do the same thing as a computer - you are working on a task and get interrupted. You must save your place in what you&#x27;re doing, handle the interruption, and resume where you left off. There is <i>significant</i> overhead there, and if you get interrupted enough, you spend most of your time stack processing instead of actually working on tasks. You get the equivalent of old time mainframe &quot;death by thrashing&quot;, where the mainframe was spending more time context switching than actually doing work.<p>Some of us are better at multi-tasking than others, but I think <i>all</i> of us over-estimate how good we actually are. I&#x27;ve advised folks elsewhere to try an experiment - work on <i>one</i> task at a time, and <i>continue till it&#x27;s completed</i>, instead of juggling multiple concurrent tasks. I&#x27;m willing to bet the amount of work you actually get <i>done</i> will jump.<p>What confuses me is why the shop in the article thought that sort of real time communication was a good idea in the first place.<p>&gt;Dennis

I&#x27;d like to see:<p>a) Built in reminders (I don&#x27;t want to sign up to todoist also)<p>b) Post formatting<p>c) Ability to mute threads<p>d) Polls?

I like the service, but having a self-hosted option would be a big plus.

so how is the end solution different&#x2F;better than email?

Reminds me of Gitter.

I see Slack as being real time and asynchronous because the contents of your conversation remain resident in the chat and there is no expectation that you respond immediately.

This is correct.