
Why we’re betting against real-time team messaging - farslan
https://blog.doist.com/why-were-betting-against-real-time-team-messaging-521804a3da09
======
TheRealmccoy
The biggest drawback of a real time communication tool like Slack is the React
v/s Respond conundrum.

Productive communication and teamwork requires that we respond, rather than
react.

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.

I have personally seen this "fastest finger first" played, almost always.

There has been tons of literature written on reacting v/s responding and I
need not dwell into it.

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.

Rest of the drawbacks is documented in the article.

~~~
mediocrejoker
I have never heard of react vs respond. I wonder if you could explain a bit of
what it means?

~~~
TheRealmccoy
Event: Your boss shares an article on @channel at Slack.

Reaction:: Since our boss has posted it and you don't want to be seemed a
second rung player and the one who is NOT on her/his toes, you jump on the
keyboard and first "Like/Thumbs Up" that post and then comment for the heck of
it, something like "Wow", Amazing", "Insightful".

Then you look over your back ie, to see how many others have commented before
you, and if you hardly see any, then you pat yourself on the back and consider
the day to have been well spent.

Response:: You read the article once and decide whether it concerns you or to
be discarded. If it concerns you, you read it once more, may be twice and take
relevant notes. Then you decide, whether you should discuss this over an email
to your boss, or a personal meeting would be more appropriate.

And thus, you draft an email or ask for 10 mins of private time with your
boss.

~~~
linkregister
This seems like the hallmark of a pre-dysfunctional workplace. None of the
engineering managers I've worked with wouldn't expect their engineers to drop
what they're doing and look at an article. All but one were too busy
themselves to be doing that sort of thing. None would want to jeopardize their
schedules by distracting their engineers. Most managers aren't trying to be
friends with their engineers; they have their own friends.

Maybe this is common in startups or in teams where the manager expects to be
friends with their engineers. I suppose I've been fortunate to never be put in
the situation where chatting with the boss overrode doing solid work.

~~~
brandon272
I cannot relate to the parent post at all. My boss shares content all the time
on Slack. People rarely respond, nor is it expected, nor is the lack of
expectation communicated, it's just implicit based on the culture. (i.e.
"Check this out if you have time")

If my boss was sharing content and then my coworkers were "looking over their
backs" to see who liked something first or liked something with enough
enthusiasm, I feel like a lot of other things would also be wrong with that
work environment to make people behave that way.

~~~
majewsky
> "Check this out if you have time"

Our boss actually uses e-mail for this purpose, which I find much more
appropriate because it matches the "if you have time" bit better than Slack.

------
onion2k
_A small, but impactful design choice we made in creating Twist was to leave
out the online presence indicator._

I imagine you could address this in Slack by just having everyone set
themselves to 'Away' by default.

One of the things that I've found useful in Slack is turning off the "Someone
is typing" 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've muted almost all the channels I'm in so
now I only _need_ to check if someone notifies me.

The point I'm making is that Slack doesn'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 _why_ 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.

~~~
hfauq
The online presence indicator is _one of the_ problems created by Slack. Using
real-time chat is the actual problem, whether it's Slack or Hipchat, or
anything alike. Real-time is great sometime, but I don't think you should use
it all the time: \- Real-time chat happens quickly — one line at a time —
discouraging full, thoughtful conversations. \- Topics are all jumbled
together in a channel so it’s nearly impossible to piece together the full
conversation. \- Important team knowledge — like what decision did we make and
why? — gets buried and lost within hours (even with powerful search). \- The
real-time nature of communication excludes anyone who’s not there in the
moment it takes place. \- Constant notifications eat into your time and
attention. \- Even if you’ve turned off notifications, the fear of missing out
on something important keeps pulling you back into the app. \- It slowly
creates a culture that prioritizes being available over doing good work.

~~~
onion2k
_Real-time chat happens quickly — one line at a time — discouraging full,
thoughtful conversations._

Slack supports shift+CRLF for line breaks, so users can write epic poems
broken up in to hundreds of stanzas if they want to. Using Slack as a one-
line-at-a-time chat service is a choice that a user makes. Slack itself
doesn't enforce it.

 _Topics are all jumbled together in a channel so it’s nearly impossible to
piece together the full conversation._

Only if users interrupt the current conversation with something else. Again,
this is a cultural choice that users make. It's not a Slack thing, or even a
chat thing. Also, Slack does support threaded conversations (albeit with a
pretty horrible UI).

 _Important team knowledge — like what decision did we make and why? — gets
buried and lost within hours (even with powerful search)._

I totally agree. Slack is not the right place for documenting important stuff.
Nor is a different chat app, or email. Important knowledge should be put in a
knowledge management app (eg a repo wiki for code, or a Word doc for business
related things).

~~~
dood
It is true that Slack _allows_ multi-line posts and discrete conversations,
but both go totally against the grain of the system design.

Expecting people to use Slack in a way it wasn't designed for can only result
in failure or constant friction.

~~~
Stratoscope
Not just the system design, but also the culture. I know a few people who post
coherent, properly punctuated and capitalized sentences and paragraphs here on
HN, but they write on Slack like this:

one line at a time

no caps or periods

stream of thought

enter each time

I posted a parody of this style a while back:

[https://news.ycombinator.com/item?id=11239614](https://news.ycombinator.com/item?id=11239614)

~~~
linkregister
Guilty at charged

^ as

~~~
Stratoscope
its funny i found out something

i never new

* knew

^ is something else

* is to correct

and never use the edit button!

~~~
linkregister
oops,

I meant *

thanks

------
jasonkester
I worked at a Slack shop for several years, and share the author's opinion.

I can't think of any five minute period during my entire tenure where the
Slack tab didn'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
"Everything", so that little bubble would go up every time anybody in the
company pressed a key. And heaven forbid somebody typed "Good morning,
@channel" (which happened 20 times per morning per timezone), because then
you'd get the dreaded Red Exclamation Mark in the tab.

I can'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.

~~~
VLM
We've left the "social" era and have entered the era of interruptions. All the
innovation this decade is in interruptions no longer human-interconnections.

My smart watch for example post dates the social era so it has only minimal
social features, but its deep in the interruption zone and spams me
mercilessly until I block apps and if I block enough apps I may as well have a
cheap dumb watch.

Another way to look at it is we no longer have 100 people shallowly liking us,
we now focus on 100 apps shallowly claiming our attention is vital because we
are important and we must be interrupted now.

Some of this is probably cultural backlash against automation and bureaucracy
and general economic decline. If more people than ever are in fact not useful
or important at all, then a communication style focused primarily around
telling people they're important, is going to be very popular.

Under that analysis Slack is a post-social communications media, and it
constantly rewarding you with endless micro doses of "your attention is
valuable" is not a bug, its the whole philosophy of its existence as an app.
You can see why curmudgeons see Slack as something negative, like the
intrusion of participation trophy culture, because thats pretty much what it
is.

The purpose of Slack is to constantly interrupt you with a narrative that
you're important. There are incidental side effects that make it semi-useful.
Companies spend a lot of money on "make employees feel special" and Slack is
merely a modern example of the genre.

This philosophical analysis of Slack is probably extendible past Slack into
startups. Don't try to market something as interconnectedness, not in 2017.
Try to sell something that symbolically, or whatever, tells people they're
important.

~~~
SyneRyder
> _My smart watch ... spams me mercilessly until I block apps and if I block
> enough apps I may as well have a cheap dumb watch._

Definitely block the spammy apps. It makes a huge different to the smartwatch
experience if it's only buzzing for things that really _are_ urgent. Once you
tune the notifications, it's actually calming - not only because you're not
being interrupted as often, but also because you're not constantly thinking
"is there something that needs my attention". If there is, the watch will let
you know.

~~~
icebraining
To me, that doesn't make much sense; the whole point of a smartwatch seems to
be making the reading of notifications more efficient and unobtrusive. If you
disable all except the rare urgent ones, what's the point of the smartwatch?

~~~
Jtsummers
Notifications are inherently intrusive. You have to pare it down to the set of
notifications you care about most so that you aren't constantly interrupted. I
made the mistake, recently, of letting the News app on iOS notify me, no sound
but near constant visual noise when some big news item comes up. All _I_ care
about is: chats and calls from girlfriend, family, friends (in that order), a
couple chess games, calendar/todo notifications to keep me on schedule
(particularly on busy days). Everything else, I can check at my leisure. If I
had a smartwatch, it'd be convenient to have those on my wrist. But I
certainly wouldn't want all those news notifications there, though I may still
want them on my iPhone or iPad.

------
mkohlmyr
I like it. I'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.

In my opinion the chat model is simply bad for effectively distributing useful
information because it disappears in the noise.

Perhaps what'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't have
to be always-on (and constantly interrupted). It should be safe to turn off
when you need to focus.

~~~
davidw
> old-school forums

Most open source projects still use mailing lists, which are even better than
forums in that everyone can read and write emails in whatever client they
prefer.

And yes, it's far better than chat for serious discussions, with a global
group of people. You don't want to exclude the Americans from important
decisions when everyone in Europe is awake and on the chat in the morning, and
vice versa.

I think both systems have their places - if I have a quick question, chat is
usually better. For longer more serious discussions, perhaps with code
included, email wins.

~~~
bahjoite
Mailing lists are close to perfect; one missing feature from mailing list
software is the ability to easily reach back in time to discover threads from
before one joined a project.

For quick questions and discussions, irc is hard to beat.

~~~
beat
Mailing lists are kind of terrible beyond a certain point of complexity.
First, they lead to a lot of self-spamming, with internal conversations.
Second, if you're not on the thread, you'll never see it. Email depends on
enormous duplication of data.

And in practice, at large companies, forced expiration is used to control
email storage space, in part because of the duplication.

So at very minimum, you want something threaded like email, but stored in a
single location, so storage/duplication/deletion aren't problems, and indexed
searching is available. This also allows things like tagging someone into a
thread after it already started.

~~~
bahjoite
> Mailing lists are kind of terrible beyond a certain point of complexity.
> First, they lead to a lot of self-spamming, with internal conversations.

This isn't a clear argument. What do you mean?

> So at very minimum, you want something threaded like email, but stored in a
> single location, so storage/duplication/deletion aren't problems

Certainly, the distributed nature of email may pose problems for an
organisation which stores emails for a number of its employees. Storage is
cheap and backup processes de-duplicate data so using mailing lists shouldn't
pose too much difficulty.

~~~
beat
It means you'll be getting notifications in your inbox all day while the
thread is running, whether you're interested or not. Which gets us in the
habit of ignoring them.

The whole point of Doist is to get us away from the interrupt-driven behavior
of constant notifications, and the instant gratification of response. Email
lists do not solve this problem, unless you turn off your email client
entirely.

------
lewisjoe
Curious question: Isn't this an already solved problem? I've been using plain
old emails and quiet free of all the problems of real-time messaging.

"Thread-first communication" \- We have it. Email threads. I've been using
Zoho Mail. It's one step ahead and has modern concepts like streams/commenting
and sharing built around emails. Very useful.

"Truly transparent conversations" \- 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 _not_ broadcast
everything company-wide, isn't it? More importantly, emails are easily
searchable. Once received, I'm confident that it's going to sit there in my
inbox forever, without worrying if it's going to be deleted later by someone
who has authority.

"Leaving out the online presence indicator" \- Exactly. Emails.

Maybe there's some more important key aspects that the product's covering up
for me. As for me, I guess emails are simply good enough!

~~~
hfauq
Emails are messy, siloed, opaque. Nobody in a team shares the same version of
an email chain. No central source of truth means a high chance of not being on
the same page. Emails have so many problems. Feel free to read through our
comparison Twist vs Emails: [https://medium.com/@hfauq/email-or-twist-why-
twist-is-better...](https://medium.com/@hfauq/email-or-twist-why-twist-is-
better-dad08f39c646)

~~~
ngrilly
I just read your link on Medium. It presents good arguments in favor of Twist
versus email. What about comparing Twist to something like Discourse or Usenet
forums?

------
_lex
Congrats on finding a real problem and building something to solve it. You're
about to fight an uphill battle.

Here's my feedback (from someone who currently leads the leads of 7 remote
engineering teams):

• 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.

• 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'll eventually
get fed up.

• 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.

• As a result you will never be their default communication channel - at most
you'll be the place they discuss bigger problems. But because you're not the
default, you'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 & helps them easily experience value from your product without you having
to win the default spot.

• 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.

------
jhallenworld
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.

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.

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.

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.

My new job is giving me a new experience- video conferences using Google
Hangouts. Many times with googlers on the Google bus.

~~~
k__
The last company I worked for had an IBM fanboy as CEO who wanted to do all
internal communication with IBM tools. Domino, Notes, Sametime.

I think these were the worst tools I ever had to use in my whole career. Even
after they rewrote the UI with Eclipse later.

~~~
jhallenworld
Yeah, Notes is basically written in the Lotus 123 spreadsheet scripting
language :-) Eclipse just made it worse. Obligatory
[http://www.ihatelotusnotes.com/](http://www.ihatelotusnotes.com/)

The one positive comment I can make is that you did end up with a unified
enterprise-wide set of collaboration tools.

Oh there was a new tool I hated before IBM decided to get on the git
bandwagon: Rational Team Concert- project management and source control tied
into one. Imagine having to start a giant 500 MB Java application to "git
checkout". (In fact the project management part was OK, just using it for
source control was horrible).

~~~
compuguy
ClearCase I think (I have not used rational team concert) infinitely worse
than RTC.

------
the_bear
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's not important) and temporary. They rarely have long-
lasting high-level conversations.

Now we're starting to hire more developers and I'm realizing how disruptive it
is for them to be pulled into Slack conversations all the time. So I've
started using email more for communicating with the devs, and that seems to
work reasonably well.

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's
obvious that only using Slack isn't a viable option.

~~~
tmail21
I don't believe that one should try to create a single tool that covers both
synchronous and asynchronous. Their UX is too different.

It seems to me a better idea to create an asynchronous deep collaboration tool
and integrate it with synchronous tools like Slack.

The bigger question to me is what should an asynchronous deep collaboration
tool do (if anything) beyond first-class threads.

In my mind the opportunity lies on three dimensions

1) Bringing updatable content and structure to threads. This makes threads
vastly more useful for real collaboration (not just communication).

2) Making "catchup" much more efficient as this is the main problem with
email.

If you think of one of the most successful asynchronous collaboration
approaches, it's source control like git. The key thing that these tools to is
make changes "diffable". That allows users to work at completely different
points in time and still easily "catchup" with what's changed.

3) Allow regular users to easily convert unstructured one-off threads to semi-
structured template threads. This naturally and gently moves teams to greater
process-orientation.

------
ryanackley
How is Twist (the product they announce in this post) much different from
email? Besides not using open protocols? Don'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?

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/Hipchat there was XMPP/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.

~~~
frogpelt
It keeps the idea of channels from Slack.

These channel designations are shared by everyone who uses Twist.

Email organization is different for each person.

~~~
xapata
Channels, like an email mailing list with a searchable archive?

------
tzs
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.

~~~
nougatine
How are fictional characters and entities even remotely relevant to the
article?

~~~
milesvp
I think he's trying to imply that the stereotype exists for a reason, that
deep thinking requires isolation from distraction.

For a more concrete example, you can look to what Richard Hamming had to say
about the topic. He noticed a similar phenomenon at bell labs, where there was
a difference big difference between people who worked with their doors open,
and those who worked with them closed.

The door closed people were much more productive than the closed door people.
Of course, he noticed there was a tradeoff there, and saw that the closed door
people tended to not be as relevant years later as the open door people.

[https://en.wikiquote.org/wiki/Richard_Hamming](https://en.wikiquote.org/wiki/Richard_Hamming)

------
dkhenry
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.

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.

~~~
AdieuToLogic

      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.
    

The people in the D language community[0] came up with just such a thing. The
source is on GitHub here[1].

0 - [http://forum.dlang.org/](http://forum.dlang.org/)

1 -
[https://github.com/CyberShadow/DFeed](https://github.com/CyberShadow/DFeed)

------
skMed
So basically a forum? Knowledge Management is a broad topic and it's hilarious
seeing the same solutions brought up again and again.

I have all this persistent information! New people need to get up to speed
fast - where do I put it? Cue the Wiki fad.

I have to get things done and elicit quick feedback ASAP! Cue the Chat fad.

I want async communication so I'm not bogged down all the time! Email and
Forums.

There's a time and place for all of these.

~~~
alexkavon
Yes this will forever be the case and engineers should get over the fact that
solutions will forever rotate and be reintroduced. This is due to several
possibilities: software ages, becomes unmaintained, company goes out of
business, becomes too bloated, etc.

There are also trends and fads to consider, such as social media.

There is also human habits to consider. Not everyone knows about or is signed
up for slack and uses it. They may eventually find out or not.

------
hamandcheese
> But in reality, even I couldn’t keep track of all the conversations that
> were happening at the company.

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.

You can also use highlight words to ensure you don't miss any discussion on
topics you're particularly interested in. We have a guy who worked a lot with
our billing, and he is magically always present whenever anyone says "refund".

------
unabst
The problem with Slack and the like is that it's communication based, not work
based.

The problem with Todoist and Wunderlist and the like is that it's work based,
not communication based.

Slack is awesome at communicating. But it has no checklist, no todo, no
collaboration tools that fulfill most needs. They're all half baked.

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's nowhere close to being a main
communications channel.

So most end up using a combination of apps.

But this is also one of the greatest detriments to productivity. Having to
juggle apps.

~~~
ferentchak
I was building an app that worked like this on top of Flowdock when I used to
work for Rally. Fully integrated work management communication application. If
you have a small collaborative team it was awesomely powerful we had used it
on the team that built it for about 6 months before the project got cut.

If someone wants a tester or feedback on something they are building I'd love
to help. I badly miss that thing :(

------
mrisoli
Slack reminds me of my school years, I grew up as cell phones became
commonplace.

We've always had chat software, but mostly we talked to each other during
breaks or after school using our desktop computers.

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.

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.

Honestly, I can't even imagine what hell school must be now that everyone has
social media and ephemeral messaging everywhere.

And I believe Slack did a little bit of this to the workplace, we'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.

In some workplaces, I felt like it was school all over again.

~~~
milesvp
Yeah, I cry for my young children. I have no idea how to prepare them for the
hell that is the always connected life. I have no idea how to teach them, that
most of it is noise, and that being purposely unavailable is essential for
mental health, let alone productivity, even if it feels like you've missed
vital social interactions while away.

Maybe it'll work itself out, and they'll naturally adapt. I just suspect it's
totally antithetical to the human condition to constantly be available to
respond to people, and psychologically we're not adapted to fight the urge.

------
georgeecollins
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'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.

------
gedrap
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.

If you want to discuss some large changes, sure, IM is a bad place.
Conversation will probably get interrupted, derailed, etc. That's where, in my
opinion, things like Google Docs or plain simple GH Issues shine. The format
forces into better thought out, longer messages.

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 <10 people each
might work out well. Even having multiple rooms with the same people can be
good to separate different topics of conversation.

"Always on", 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't go crazy.

So, IM has it's place and provides value if you are willing to make it work.
It's just not a 'it just works' solution, which is hardly surprising.

------
robbiemitchell
We have seen many of these challenges over the years and set out to build
something to help manage your team's incoming requests — directly in Slack. We
find it's most used for internal assistance (one team supporting many) or as a
way for B2B companies to provide support to their top customers.

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 "feed" channel. The notifications ping specific people on
rotation or on a sequence (according to rules) until claimed, the
conversations are explicitly resolved with a "closed" 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.

If you're struggling to manage the chaos, give it a shot and see whether it
helps.

[http://frame.ai/beta/](http://frame.ai/beta/)

------
nottorp
All you need is a little self discipline, not a special app. Turn off
notifications, check your messages when you're taking a break, do not attempt
to chat real time.

The only actually useful feature of this app seems to be that it's thread
oriented, but you can mitigate that with enough irc (okay, Slack these days)
channels as well.

~~~
majewsky
Depends on how the team uses it. When I'm @-mentioned in Slack, it's usually
because a system that I maintain is failing or doing weird things, and that's
something that I should react to quickly. It's therefore not really an option
to turn off notifications (not for @-mentions, at least).

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

~~~
akhilcacharya
I mean, isn't Dropbox just prettier rsync?

~~~
josephg
And Slack is a modern version of IRC :)

It keep being surprised by how much a fresh coat of CSS and a mobile app can
reinvigorate these old ideas. Who knew how important adding gifs and emoticons
would be?

~~~
tvaughan
[https://grove.io/](https://grove.io/)

~~~
detaro
Oh interesting, wasn't aware that was a thing. Sad they didn't make it.

------
rovek
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.

It's easy to see how you could design a "process" around using something like
Slack to achieve the same experience and if you don't design a "process" 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.

------
RandomOpinion
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.

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.

~~~
kitd
FTA:

> Threaded conversations have been at Twist’s core from the beginning.

Maybe depending on the precise job at hand, but I believe everything else
should be handled by a usenet server, or equivalent. Usenet revolves around
the topics, not the messages.

I was using a local usenet server 19 years ago for holding online design
discussions. I haven't found a better mechanism since.

------
sergiosgc
I don'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.

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.

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.

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.

If the unstructured->structured bridge is solved, you don'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)

------
bambax
Just went through Startup School that uses Mattermost, which seems to be a
Slack clone (not sure since I never used Slack).

It didn'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.

And since there are no threads or topics or anything, it's almost impossible
to go back to something that was said a while ago.

I think a subreddit would have worked _much_ better.

~~~
it33
Hi @bambax, Mattermost team here,

Appreciate your feedback. The Mattermost instance at Startup School does offer
threads, if you either click the "Reply" arrow when you hover over a message
or go to the "[...]" menu and select "Reply".

If it wasn't easy to discover, that's 100% our fault and we'll see what we can
to do make it more prominent in the tutorial and in other ways.

Definitely agree threads are crucial to go back to topics in early
discussions. We've had them since 2015 and for people using them, they become
kind of indispensable.

Maybe give it a try? Would love to hear your thoughts in the Mattermost
feedback channel.

~~~
bambax
Hi, thanks for reaching out.

Maybe I misspoke. Maybe I meant "tree view" and not "thread".

I was aware of the reply feature, and yes, if you read a reply and you click
on the original title, you get to see all messages attached to this original
message, in a window to the right, that you can navigate (more or less).

But AFAIK you can't reply to a reply (if you do, it's a reply to the original
message); it's probably a feature (back in the days, the Joel on Software
forums worked like that, and Joel Spolsky was actively defending this option
in various posts).

But it makes it difficult or impossible to actively monitor different threads
or topics. Threads are not collapsible. The UI actively favors the more recent
messages, you have to actually click on "load more messages" to see earlier
messages (and if you change channels and come back, the earlier messages are
gone, you have to click again to see them).

Anyway, I don't mean to be negative on the product which is very well polished
and works perfectly; it's just that the choices that it makes seem ill suited
for a very international and asynchronous crowd.

------
pcarolan
Apple took a step in the right direction with the do not disturb feature in
the Notifications bar. When I don'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's
set. Then, I want a timer so I can get blasted with updates every 25 minutes
like Pomodoro timer.

------
kodablah
I have often considered setting up a local Reddit instance for my company for
these very reasons. Has anyone done this with success?

I also considered creating some biz comm software myself, but only jotted down
some ideas[0]

0 - [https://bitbucket.org/snippets/cretz/Xopoj/retzle-
conceptual](https://bitbucket.org/snippets/cretz/Xopoj/retzle-conceptual)

------
dwheeler
Their "new" approach sounds suspiciously like a mailing list: asynchronous
communication for a group that supports threads of communication.

~~~
dkhenry
I would liken it to a newsgroup more then a mailing list, but they are very
similar.

------
keybits
Where I work we've started using private categories on a Discourse instance
for conversations that are 'too big for Slack'. 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 'liking' posts. Bonus points for being open source.

~~~
lylo
I would agree. I tried Twist and it's a really usable app, lovely UI design as
you'd expect from the Doist team. But for our 60+ product and engineering
team, Discourse does a great job of handling asynchronous threaded discussion
– and we can host it on AWS for $20/mo for unlimited users. I'm struggling to
see the advantage (UI aside) of Twist at this stage.

------
d0m
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's hard to follow. I guess slack could copy them and
have a "text mode" and a "thread mode", easily being able to switch between
both, and then the threads will be much more useful.

------
amix
I am the poster of this (and as you can see, I am an old HN user -- almost ten
years here!)

I'll be answering your questions. Thanks for the support!

~~~
amix
Please also note that Twist will have a full and open API. You can see a draft
here: [https://doist.github.io/Twist-API/](https://doist.github.io/Twist-API/)

------
dmartinez
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.

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.

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.

------
yiiii
Google Wave?

~~~
tehlike
Came here to say this. Google wave was a pretty good attempt at fixing this.
Maybe it was ahead of its time.

~~~
mrisoli
Maybe Google Wave was targeted at the wrong segment? I believe it was used as
a general communications tool, not specifically for business.

~~~
tehlike
hard to say - i was mostly using it to communicate with opensource developers
on nhibernate (iirc, long time ago). I think you are right though, most of the
features are things you'd use more for business. Also considering how widely
google docs is used, it makes sense.

PS: I am a google employee.

------
elipollak
Really nice post. We've suffered similar challenges using slack with our
remote team and switched to Basecamp, which has been much better.

What's your sense of how Twist and Basecamp compare?

~~~
amix
Twist is just about communication. Basecamp has a bit of everything, but it
isn't particularly good at any of the things.

We wanted to create a product that just does one thing really well (and that's
team communication).

------
wazoox
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.

------
nchammas
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.

[https://m.signalvnoise.com/is-group-chat-making-you-
sweat-74...](https://m.signalvnoise.com/is-group-chat-making-you-
sweat-744659addf7d)

> Group chat is like being in an all-day meeting with random participants and
> no agenda.

------
joneholland
So you built Basecamp?

------
pesto88
I would say the amount / frequency of interaction depends on the team you work
on.

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.

------
seanhandley
Here's how I prefer to use Slack:

1) Turn off notifications (except @mentions or DMs). 2) Code uninterrupted. 3)
Check in when I'm taking a break. 4) Profit.

Our company culture is such that Slack is mostly for notifications from our
toolset, so that probably helps. Also, we're small (< 20).

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

------
tckr
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.

------
misterbowfinger
> 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.

This sounds really creepy

------
sleepychu
> Unlimited file storage for the team For 3.90/mo charged per annum? How do
> you offer that?

------
dmccunney
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 "The nice thing about
Dennis is that if he's at his desk, he answers the phone on the first ring. If
he's not at his desk, you won't get hin in IM, either!" Bless him. He _got_
it.)

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't blow
up in someone's face.

The underlying problem is that computers are good at multi-tasking, and humans
_aren 't_. When a computer is handling multiple concurrent tasks, and an
interrupt comes in, it must save its place in what it's doing at the moment,
handle the interrupt, then go back to the saved place and continue where it
left off. It'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's working on. The overhead isn't apparent.

Humans _aren 't_ good at stack processing. I'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.

And humans aren'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're doing, handle the interruption, and resume
where you left off. There is _significant_ 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 "death
by thrashing", where the mainframe was spending more time context switching
than actually doing work.

Some of us are better at multi-tasking than others, but I think _all_ of us
over-estimate how good we actually are. I've advised folks elsewhere to try an
experiment - work on _one_ task at a time, and _continue till it 's
completed_, instead of juggling multiple concurrent tasks. I'm willing to bet
the amount of work you actually get _done_ will jump.

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.

>Dennis

------
flavor8
I'd like to see:

a) Built in reminders (I don't want to sign up to todoist also)

b) Post formatting

c) Ability to mute threads

d) Polls?

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

------
SonicSoul
so how is the end solution different/better than email?

~~~
rvschuilenburg
Easier to give / remove participants and automatically give them access to
previous messages in the thread, without having to quote all previous messages
just to give some context.

~~~
djklanac
I need to give this another look, but isn't that what a Google Group provides?

------
computerex
Reminds me of Gitter.

~~~
phaed
How so? Gitter is just like Slack.

------
tzakrajs
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.

~~~
ryanbrunner
I think in practice Slack becomes a far less effective tool the more
asynchronous it becomes. If a room is even halfway active, a post from a few
days ago is more or less lost to history and a conversation that takes place
over a few days is almost impossible to follow.

------
fiatjaf
This is correct.

