
Slack is the opposite of organizational memory - awinter-py
https://abe-winter.github.io/plea%27s/help/2018/02/11/slack.html
======
peterevans
My worry is that if Slack is replacing your documentation, then it may be that
your organization did not have good (or any!) documentation that predated its
use of Slack. As such, I'm not sure if that's a fair thing to criticize of
Slack.

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.

~~~
bambax
> _if you are a remote company, you need [to make it easier to talk to
> people]_

From the article:

> _Remote work culture is a defense mechanism against the distracting open
> office, and slack is the end run around that defense mechanism._

Slack kills off any benefit there is of being remote, because it is immediate:
you need to be online all the time, and you need to answer / participate /
chat instantly.

A good alternative to Slack would be a Reddit-like interface with threads and
an asynchronous model. That's also the superiority of email over any chat
solution. I don't understand why people and organizations get so excited about
real-time conversations.

We always had real time. Cavemen had real time. Writing was invented to free
us from real time, to transfer information in non-real time and to future
generations.

But now it seems the cavemen are back, with a vengeance.

~~~
SnootyMonkey
This is an important original post, and I wish the Slack community were having
these conversations more often and openly.

The original post nails some important issues: companies really need topic
focused discussions, intentional, thoughtful writing, not just chat, more
asynch so there is time for deep work and time for more thoughtful discussion
and replies, and much better, topic-based search.

I believe in the impact of this problem so deeply that a team of us have been
working on an open source solution to it for a couple years now.
[https://github.com/open-company](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/](https://carrot.io/)

~~~
smoyer
I don't see how you can ever get something named carrot out of beta
(carotene). Your product looks a lot like Yammer (which we have in addition to
slack, XMPP and email) in that there are threads. Threads make Yammer better
than Slack but there are still two things that I hate (and that Google/Apache
Wave got/gets right): 1) Comment threads are hierarchical so side
conversations can happen in-line but also be out of the way. 2) Blips that
I've read or that I'm not interested in can be collapsed.

The best conversations in Slack should really be a conversation in an issue
tracker. Unfortunately, nobody will see those comments when they look at the
issue. One issue I see with the carrot UI is that there's not really enough
room to have a real conversation in the comments side-panel.

------
kator
I'm very comfortable typing /mute in noisy channels and coming back later. I'm
also happy to close slack when I need to be in the zone.

IMHO Don't blame the tools, it's about discipline, you need to own your time,
calendar time for yourself and get stuff done. If management doesn't
understand this then time to find a new team.

~~~
smt88
> _it 's about discipline_

I've moved my teams away from "discipline" as a solution. How many times has
someone said "I'll stop doing this" or "it won't happen again" and then it
does?

Discipline might work for one person (usually the one making the rules), but
I've found that it's impossible to get a team to be uniformly disciplined.
Even if you can do it, it's extremely time/labor-intensive.

There are many tools demonstrating that discipline doesn't work, such as
Chrome add-ons that block Facebook. Even when someone understands they need to
be disciplined and want to be, sometimes they just can't.

Some examples of replacing discipline with hard boundaries:

\- using only languages with static typing

\- rejecting commits with messages less than 3 words long

\- rejecting commits without tagged issue(s)

\- formatters (similar to gofmt) instead of a style guide

~~~
rdiddly
\- not having a bag of goddamned Oreos in the house when you're on a diet.

"Aww, all it takes is a little discipline." Yeah or I can set myself up to
_succeed_.

~~~
NLips
This seems to me like an incredibly good example, and I've no idea why people
would be downvoting it. The GP programming / technical examples are
potentially easier for the reader to think "well sometimes I'd want to break
that rule because X", whereas this example makes it obvious, and brings up
"setting yourself up to succeed".

Good contribution, rdiddly.

~~~
rdiddly
Thanks, yeah the point is to use discipline further upstream. Use discipline
once at the outset to permanently avoid influences that require discipline
over and over again.

------
ebiester
It's an interesting argument. When I hear it, I interpret it as "I'm too busy
doing stuff to help anyone else do stuff."

The people who do this, from my experience, are also the people least likely
to write tests, documentation, comments, or self-explanatory code. Then, when
someone makes a mistake based on misreading this member's code, they are
labeled as "incompetent."

I agree that Slack has created an interruptible culture, and I'm not a fan of
that, but we have yet to make a tool that transfers knowledge without either
human contact or extensive documentation. Structured distraction is the
alternative - we call them meetings.

Nobody likes meetings either.

~~~
philwelch
I like how you gloss over documentation as if it’s not even a viable solution.

Documentation isn’t hard to generate. Set up a wiki so you can document things
there, move your internal “how do I do X” chatter from Slack to email lists
and maybe a StackExchange installation, and you end up with multiple
indexable, searchable sources of long-form documentation.

Sometimes, documentation is work. So do the work. People and organizations who
avoid that kind of work and say “just use Slack” end up trading 1,000 hours of
interruption over 1 hour of work.

~~~
llimllib
Everywhere I've ever worked, "set up a wiki" has meant "create something once
that nobody ever remembers the existence of"

~~~
ebiester
Or, it accumulates so much cruft that it's hard to find the valuable
information. I think there's room for documentation librarians, whether by
role or job title, but it's hard to justify the expense in smaller
organizations.

~~~
protomyth
I found that a bit of scripting will make a wiki a bit more maintainable.
Replace pages that are out of date with a tag of some sort (e.g. #outdated).
Have a script spider the wiki from the home page and send out an email with
all the reachable pages with tags. Either fix the page or make sure it’s no
longer reachable.

~~~
ghthor
Pro librarian work right here, Nice work!

------
breeny592
>Another JIRA flaw: highly formalized process is usually a hindrance,
especially considering who in your organization invents, applies and benefits
from process. Hint: middle managers.

This just reads as someone who hasn't had to actually think about what is
being built, and who is paying for it. Effective teams are more than just
"developers write and push code" \- it's about being able to predictably say
we are implementing this feature (or fixing this bug), therefore it will be
available to customers at X time. As organisations grow, it becomes more and
more critical to be able to predictably forecast the work that teams will
complete, so that the right work can be planned out and roadmapped.

I had plenty of problems with this article, but this one stood out the most.

~~~
jiaweihli
Your interpretation of the quote is that middle managers don't provide value,
but I think that may be too broad. I understood it as "highly formalized
process often rewards middle managers", which I do think is true.

The best manager I was lucky enough to report to personalized his approach to
his direct reports. He recognized that some people are more creative, others
prefer more structure, etc. He still had his responsibilities, e.g. report
progress on project X and estimate completion, but this was abstracted away
from the team. For all we knew, we each had an area of the system we were
responsible for, and we had longer-term collaborative projects that would take
on the order of months. I didn't realize how great of a manager he was until I
had other managers who firmly believed in the One True Way™ of managing
projects, and also pretty much required everyone to be heavily involved in it.
(Give estimations for things you haven't worked on, and move tasks as you get
to each stage of development.)

Getting back to my original point - highly formalized process often rewards
middle managers because it simplifies work for them. Everything is already
tracked in the system, it's a matter of moving around and allocating
resources. But why does everyone need to be involved in this? Why isn't
heavily formalized process compartmentalized to just managers and the people
they report to (and maybe their reports that enjoy that process)?

I recognize the value that managers bring - otherwise every individual
contributor becomes a mini-PM - but I also believe that the best managers put
in the work. They build good personalized relationships with each member of
the team, and are able to compile estimates based on their interactions. It's
not always a cold science in the vein of "since Alice has 13 points out of a
maximum of 18 points per sprint, I should try to allocate 5 more points - the
biggest task that fits into that is 4 points, so let's assign that to her."

~~~
breeny592
>Your interpretation of the quote is that middle managers don't provide value,
but I think that may be too broad. I understood it as "highly formalized
process often rewards middle managers", which I do think is true.

I agree, but I don't think that's a bad thing - I think something that rewards
management, rewards the team as a whole. If the PO/PM overcommits, it's the
team as a whole who suffers. Likewise, if targets are smashed, the team gets
recognition.

As such my interpretation wasn't that middle management is bad, but that
formalised development processes are bad, which is what I fundamentally
disagree with.

Businesses as they grow end up having abstractions on abstractions.
Formalising development processes allows for the business to actually be aware
of what it's doing, how effectively it's being done, and where opportunities
lay for improvements.

Don't get me wrong - too much management creates warrantless red tape and
frustrations, however standardising the development process through things
like Jira (which the author was complaining about) doesn't fall into that
bucket (in my opinion), especially when the author compares that the same can
be done with a blank sheet of paper - if senior management want a rough
understanding of the roadmap for the next 12 months, why would you "forecast"
with some guessing on paper, over actual proven data of this is roughly how
this team performs, this is the rough estimates on these initiatives, ergo, we
can commit to these X projects.

------
rowyourboat
Thing is, I have always used IM in one form or other for work. Slack is
finally one that can handle code snippets well.

It's not worse at interruption than any other IM (and you can tell it to shut
up, so), it does not replace documentation, and it does not solve any
organisational problems (it's a technical solution, how could it).

What it is, however, is a chat client that can handle code snippets well. So
yay for that.

------
hamandcheese
If not Slack, then what? Nothing?

I work as part of a fully remote team and I can't really imagine not using
Slack.

Generally we discuss in Slack, immortalize in GitHub issues (using ZenHub,
thank god), and do ad-hoc video calls for screen sharing and whatnot.
Announcements and such usually go out as an email blast.

I'm really curious what life would be like using email/issue comments only.
Obviously this must be possible since so many open source projects operate
this way, right? But they also have a totally different organizational
structure.

Any insights, HN?

~~~
geofft
Remove asynchronous interruptions and go back to old-fashioned synchronous
interruptions (scheduled meetings, either in person or calls/video chats) for
the stuff that requires high-bandwidth communication and asynchronous non-
interrupting queues (emails, or other similarly-shaped things like tickets or
wiki page edits / comments) for the stuff that requires low-bandwidth
communication and more intensive thought / work.

If you need asynchronous interruptions, pre-Slack and even pre-email culture
had ways to do this - phone calls, pages, knocking on people's doors - but
they were viewed as rare and exceptional, and the coworker who would knock on
your door all the time to ask if you saw the message they just sent was viewed
as rude and distracting.

~~~
rowyourboat
I'ld much rather be IM'ed or emailed than called or paged. If I am called, the
phone rings or the pager beeps, and I have little choice but to interrupt my
work. My slack client, on the other hand sits in the system tray, silently
displaying a little blue or red dot. I can open chat when I feel like it, or
ignore it until such a time when I am not concentrating on something else.

Asynchronous communication is empowering: You can choose when you communicate
and when you want to concentrate. Synchronous communication does not afford
you that luxury.

~~~
geofft
Why is using Slack in this workflow superior to using email? I also know if I
have unread emails via the tray icon or mobile app badge, same as with Slack.

Is it just that short frequent messages in email feel weird?

~~~
rowyourboat
That, the superior handling of short-message group conversations and the fact
that the number of people who could email me is vastly greater than my team
members on slack. As such, I tend to check slack relatively frequently, while
I check my emails only twice a day - I do not have push notifications enabled
for email. Basically, slack means a usually-within-2-hours response time,
while email means same-or-next-workday response time.

------
pkrumins
You should try Twist ([https://twistapp.com/](https://twistapp.com/)). I
switched to Twist with my team and haven't looked back at Slack. Twist
organizes discussions around tasks. When the task is finished, that
conversation is pretty much over.

Read this post by Amir, the founder of TwistApp - Why We're Betting Against
Real Time Messaging - [https://blog.doist.com/why-were-betting-against-real-
time-te...](https://blog.doist.com/why-were-betting-against-real-time-team-
messaging-521804a3da09)

~~~
dingo_bat
I saw the twist video. And it seems just like slack. Slack, but guys please
observe discipline. The UI, design, philosophy everything is identical to
slack.

You feel forced to respond to slack chats, so just chill and respond only when
you want to. This is literally in the video.

The thread loses track of the topic, so we have exactly the same hierarchy and
groupings like slack, but guys please just use the thread for the topic only.
This is literally in the video.

Chats are annoying and people keep disturbing you in slack. We have
"messages", perfect for small groups and individual conversations. Again,
exactly like slack, but let's all promise to be not annoying.

The UI and app look great, I can see that folks really worked hard on this
thing. But there is zero differentiation from slack. It looks like somebody
took slack, re-colored it, and put "calmer and more organized" on the website.

~~~
TotempaaltJ
> The UI, design, philosophy everything is identical to slack.

This isn't quite right. The way Twist shows threads and information is a lot
closer to email, and there's a big difference in how it organizes information:
on top of channels, which are based on groups or projects, it has threads as a
base organizational unit.

UX does influence behaviour, afaik. The Twist UX facilitates and encourages
long-form, on-topic discussion a LOT more than Slack. See also email: have you
ever used email like Slack?

imo the main issue is actually that email + some mailing lists still has major
advantages over Twist.

------
jordanpg
In my organization, github PR threads and JIRA comment threads tend to be
ignored or forgotten after their inception, and chat gets results right now.
We also use Trello, Confluence, google docs, and of course email for some
things. I think this sort of thing is common.

They all have their strengths and weaknesses, but it strikes me that a bigger
barrier to productivity and strong organizational memory than interruptions is
the overall dilution of information.

Sometimes I think that the narrowing of the available tools (channels for
information), whatever the weaknesses of the chosen tools might be, would be
wise.

------
cyberferret
We've found this to be partially true in our very small startup. The
unstructured nature of Slack conversation do make it hard to go back and
reference something that was said only a few days ago, however we have found
that the search tool has been very useful in locating a decision or rule that
was made a while back in casual conversation.

By and large, the biggest problem we have, even with a handful of users, is
the fact that everyone tends to just use Slack as an ideas repository, and bug
tracking/feature request tool, rather than log it in our actual Phabricator
development tracking tool.

Also, we have (I believe) gone a little overboard with integrating our other
tools into Slack (including Phabricator, AWS, Stripe etc.), so we are almost
at a 1:1 ration of bot generated messages to user created messages at the
moment - leading to a lot of inadvertent mental filtering of channels,
resulting in missed (human) messages.

------
zippie
As time has wore on our organization has relied on slack less for team
collaboration and more for monitoring.

Admittedly, the slack client is great at cross platform notifications and we
leverage those in our monitoring processes, where alerts are sent via zabbix
to pagerduty and slack simultaneously via webhooks.

In a real sense the responders have “any activity creates a notification”
which enables them to react and others to view a record of what happened. This
eliminates the casual “what happened?” conversations.

We’ve yet to have an oncall event fall through the cracks.

------
overgard
Before Slack it seemed like everywhere I worked had chat and IM anyway -- it
was just a thinner experience. As a programmer I have mixed feelings about
making a point about "distractions". On one hand I'm sympathetic and think
people need to be more conscientious... but I also think managing distractions
is an important skill as a programmer, and there are a lot of people that seem
to relish in acting professionally flustered all the time. At the end of the
day sometimes answering questions and coordinating with people is the
important work -- even if it might be frustrating.

Also, I mean, you can just turn it off or mute the notifications. I see people
do that all the time and nobody cares.

~~~
sundvor
Love your last point; I'd respect someone who'd mute notifications and treat
it mainly as an asynchronous communications tool.

Combine it with an Urgent channel if need be, where notifications are On, and
tell people off for posting crap there..

------
brongondwana
[shameless plug]

This is exactly why we at FastMail made Topicbox! Email is your personal
memory, and it made sense to extend that to organizational memory by making
mailing lists not suck.

And we switched from IRC to Slack for our internal comms a while back, so we
know the pros and cons :) Chat's great for real time, but not for long-term
memory.

[https://www.topicbox.com/](https://www.topicbox.com/)

[/shameless plug]

------
kaycebasques
As a technical writer I have a big problem with Slack. It seems like a black
hole of unfindable knowledge. I stick to Stack Overflow and mailing lists when
I interact in my product’s communities because they are streamlined
repositories of linear knowledge.

A moment of gratitude to Stack Overflow and mailing lists!

------
jtl999
The problem I have with large group chats like Slack, Riot, IRC is that it's
hard to get information from them when you've been "out of the loop" for a
while. Much better to read a bunch of forum threads or tickets, then trying to
make sense of a long scrollback.

~~~
Anderkent
You shouldn't be trying to. Slack is a tool used for raid iteration, not an
event / decision log. Unless you establish some strict conventions, like
having an announce / decision channel with very restricted traffic, you should
still record important decisions somewhere else, and give that to people when
they need to 'catch up'.

~~~
white-flame
That doubles the authoring workload, though.

If you're talking on something like a forum, with individualized contextual
threads, then those are already auto-categorized for reference later.

I guess the equivalent would be to start new chat channels per topic, and
index them somehow? But realtime chat tends to have more organic topic drift
than post-based discussion.

~~~
jtl999
> 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.

~~~
isostatic
Classic forums software was pretty much a web based NNTP gateway -- some even
supported nntp integration directly. Posts were threaded.

Then along came unthreaded forums in late 90s/early 00s. Things like phpBB are
not my cup of tea when compared to the layout of usenet or slashcode.

~~~
jtl999
> Classic forums software was pretty much a web based NNTP gateway -- some
> even supported nntp integration directly. Posts were threaded.

Ah. We have a different view of "classic forum software". NNTP was before my
time.

------
aorloff
There are 3 primary types of documentation that a growing organization needs :

1\. Onboarding 2\. Runbook / Troubleshooting 3\. Notes and ongoing developer
wisdom

Slack helps with #3, but is not what #1 and #2 require.

New hires should not be digging through slack to get up to speed, and ops or
engs trying to deal with catastrophe in the wee hours should have playbooks,
not try to dig up what worked last time in slack.

~~~
awinter-py
do you have any recommendations for good runbook tools? I'm on the market for
one of these.

~~~
softawre
a wiki?

~~~
aorloff
Yeah a wiki should suffice. Having a good runbook is a process that needs to
be tended to every time devs and ops deploy, troubleshoot, and configure
services. More of a process than a tool, because it should integrate with all
the tools already in use for deployment, logging, debugging, etc.

------
Waterluvian
I wonder if disabling search and restricting chat rooms to a limited buffer
would help encourage people to see Slack as a lossy chat service and not an
appropriate data store. You would be forced to decide what's important to keep
and keep it somewhere.

I especially don't like when Slack is used as an official record.

~~~
Anderkent
Why?

It is a great advantage of slack over email / in person that you can later
find two people you've never met discussing something similar to your problem,
follow their historical discussion, and possibly find a solution.

Or even your own previous conversations for issues deemed too minor to record
in a more 'official' record (like a jira ticket, or project documentation).

~~~
philwelch
If you have an internal wiki, email list archives, and maybe an internal
StackExchange and set up an ElasticSearch cluster over the whole works, you
can answer pretty much any question in a one stop shop.

~~~
Anderkent
None of those do interactive collaboration like debugging very well. You could
copy the result of the collaboration into something like that, but actually
getting people to do that is not trivial. If the collaboration happens on
slack, you get at least some searchability.

------
opportune
For large organizations, a forum/ticket model is a much better way to leverage
organizational memory and knowledge.

For small teams, and teams within organizations, I actually think the Slack
model does fine _if_ people mute it. I'm one of those people that loves to
help people with technical challenges and this was a big hurdle for me. Almost
all of the problems in the article can be solved by muting and only checking
during breaks.

I don't think anyone rational would conflate productivity with availability on
slack unless their job is to answer questions on slack. It's also just such an
obviously bad idea to forgo documentation in favor of Slack that I'd say no
rational developer would do that either. Those aren't problems with Slack,
those are problems with lazy people who want to blame Slack for poor software
development.

------
dimal
For all the hate Slack gets, it works great for me. Yes, you can be
interrupted, but you can also ignore it very easily. Without Slack, I’d have
people coming up to my desk and asking me questions, which would _really_ be
distracting. Maybe I work in a company with a good culture, but the middle
managers don’t use Slack in the way he describes. Sure, managers can act that
way, but they don’t have to. And in my experience, they don’t.

I don’t understand his comparisons to Trello and JIRA. Those are project
management tools. Slack is a chat tool. Completely different things. And his
complaint that it’s a bad tool for documentation also rings hollow. It’s a
_chat_ app. Is he also going to complain that his hammer it a terrible tool
for tightening screws?

~~~
labster
Yeah, maybe Slack is bad in OP's workplace. But in mine, it's been great for
increasing communication in an all-remote developer company. JIRA is used for
task management, docs are stored in the same repo as the code, and Slack is
used just to talk to people or solicit opinions. No one ever uses @here
because none of us want to be bothered either.

I feel like most of the complaints on Slack are either because people use it
as something other than logged IRC, or because it's getting misblamed for
other company culture problems.

------
lillesvin
I've often thought about using good old NNTP as a replacement for Slack. It
does everything I want from Slack in terms of structured conversation and
preservation of information. At the same time it doesn't have the same real-
timey feeling (that the OP refers to as urgency).

------
mmanfrin
There are two types of memory: long term memory and short term memory. Slack
is short term memory. Both kinds are important -- short term memory without
long term memory is amnesia.

~~~
awinter-py
I like this metaphor. Thanks for posting.

------
whistlerbrk
Ai yai yai. People need to stop adopting tools thinking it'll be the panacea
of communication and organization. Insofar as the author says that I agree.

But I think it is equally short sited to blame the tool.

Whatever tool you choose, you have to FULLY adopt. Everyone has to be bought
in, learning the features (like do not disturb), setting ground rules which
make sense for your company and how people within it like to get things done.

Seriously, I never felt more productive than when I used Trac, I don't think
issue tracking has really evolved much more than that save useful social
features and code review (essentially what killed Trac because the Git
integration was never very good).

When I look back as to why that was, I realize it was because the WHOLE
COMPANY was bought in. We all used it, we all used it well and respectfully.

This is the madness of the agile world. Viewing the tool as the solution
rather than just that, an implement, a ways to a means that starts before its
usage and and ends after its usage.

> Remote work culture is a defense mechanism against the distracting open
> office

Disagree as to the reason remote work has become a thing, but I _do_ think
it's largely because video conferencing works better every year, tools like
Slack exist, and code review tools can be done line-for-line remotely.

But, has anyone seen the Slack diagram for whether or not to send a message?
It is extremely well thought out, but settings can't be useful if you don't
set them.

> Chat, at least on slack, isn’t grouped or threaded.

Yes they are, now.

> ...non-trivial to know what the current topics of conversation are in a
> slack channel or to assign one of those topics to any given message.

Then speak up and tell people to stick to the topic, change it, or open a new
room.

> ctrl-f, the one constant of web interaction, is broken in channels if you’re
> searching more than one page up.

Use the Slack client

> Middle managers will make deliverables....

And here is where I stop reading. This is an organizational problem you see
manifesting on the tool and you are incorrectly assigning blame to the tool.

\--

You have to be committed to using whatever tool is chosen. Just choose one and
actually use it.

These tools are a discipline _not_ a freedom from discipline.

~~~
q3k
>Use the Slack client

I know it's technicalities, but sadly this isn't possible for everyone.
Closest thing is using the IRC gateway, but at that point your company might
as well be just using IRC...

~~~
hamandcheese
Why is this not possible for everyone?

~~~
geofft
The internet suggests that the official desktop/web client is not particularly
usable with a screen reader:

[https://www.marcozehe.de/2016/01/16/status-of-the-
accessibil...](https://www.marcozehe.de/2016/01/16/status-of-the-
accessibility-of-slack/)

[https://slackhq.com/designing-slack-for-
everyone-456002920bf...](https://slackhq.com/designing-slack-for-
everyone-456002920bf2) (talks mostly about the mobile clients, which were
designed later)

Maybe this has changed recently?

------
rishirishi
Positioned as a tool for collaboration and productivity, how can Slack
legitimately be that when it is designed for online, synchronous
communication?

Is it really collaboration when members in a channel do not have a chance to
prepare or struggle to participate at that pace?

What is productive about Slack? Perhaps you get questions answered through the
tool, but you do not produce through Slack. I think of meetings as productive
when progress is made on a problem or a decision is arrived at. How does Slack
facilitate that better than scheduled meetings?

I have generally stopped using Slack. If a conversation takes longer than
three minutes to conduct on Slack, in real/video/phone life please. There is
an illusion that work is getting done faster on Slack; the opposite is true,
work is slower and of poorer quality.

~~~
quacker
> How does Slack facilitate that better than scheduled meetings?

Slack is not a replacement for scheduled meetings though.

> If a conversation takes longer than three minutes to conduct on Slack, in
> real/video/phone life please. There is an illusion that work is getting done
> faster on Slack; the opposite is true, work is slower and of poorer quality.

People say meetings are high-bandwidth, but getting a bunch of engineers in a
room is very expensive (literally - hundreds of dollars an hour) and you get
synchronous, blocking discussion (one person speaks at a time - else, chaos).
I am much, much less distracted participating in a "long" slack discussion
(which I can check in on every few minutes or so) than I am with all my
attention paid to listening to a meeting.

Personally, I find few people on any given team are able to communicate well
on the fly in a meeting and I see people (including myself) frequently asking
for clarification due to misunderstandings, which contributes to a meeting
dragging. Meetings are also _notorious_ for encouraging unfocused and
unstructured discussion, unless you have a good moderator or some structured
approach to a meeting (like a lean coffee style). A lot of this is improved in
a Slack conversation because people are forced to distill their thoughts into
text, they are able to reread messages for clarification, and we've had good
success using Slack threads for focused discussion of particular topics.

Meetings are also not archived by default, which isolates the people unable to
attend the meeting - especially when you have in person meetings that are not
remote friendly. Slack discussions are at least discoverable through search.
One team I was on started recording meetings and rewatching hour long meeting
minutes to get information is actually terrible. Searching through Slack is
not perfect, but it's infinitely quicker and I frequently do find what I want.

~~~
rishirishi
You are right in that meetings are prone to being wasteful and unarchived. A
few considerations that I find necessary for meetings: \- Schedule in advance
(if possible) \- Set an agenda and provide reading material (if available)
such that attendees can prepare \- Be selective in who attends; those with
relevant knowledge, interest or stakeholders \- Record meeting notes (key
decisions, unsettled conversations, differing opinions) \- Appoint a chair to
keep the meeting on track, as per the agenda. They can also help shut people
up and give others a chance to speak. \- Share the meeting notes with the team
at large

------
DoubleGlazing
The author nails my thoughts on Slack (and its OS clone Mattermost). It is
less a communications tool, more of a productivity tracker.

I've worked in places where it was unofficially compulsory to have Slack
always open. If you didn't respond to a message is a timely fashion then you'd
be asked why. It became the case that Activity on Slack = Productivity.

This wouldn't be so bad if it weren't for the fact that I think Slack is a
pretty poor way to do workplace communication. It's the textual equivalent of
shouting out a question to the whole office. Everything seems to mush together
in to one big conversation about everything that is hard to track and search.

~~~
scottishfiction
My thoughts on your comments are the same as my thoughts on the article. These
are cultural problems that Slack is simply exposing. If there was no Slack,
something else would fill the need for your middle management to track
everyone's 'productivity'.

------
tabeth
In regards to "organizational memory", has anyone had any luck not allowing
for "private messages?" The idea being that the vast majority of conversations
between any two people will be about a work item, if it's about work, and
therefore all conversations should be organized around work items, rather than
people.

Gitlab seems to do this[0] and I'm curious if it's better than ad-hoc
conversations. Too bad their UX is too cluttered. I hear Basecamp has similar
functionality.

[0] [https://gitlab.com/gitlab-org/gitlab-
ce/issues](https://gitlab.com/gitlab-org/gitlab-ce/issues)

~~~
overgard
I can't imagine that being a good idea -- people form friendships in the
office, or they just need to have a private conversation -- it seems like it
would be weird and draconian to forbid that kind of thing because something
important might be in a private chat.

~~~
tabeth
Ah, I meant forbidding them in the sense that the culture of the organization
would discourage people from talking about work related things in a "work
context" via ad-hoc messages, not that people literally or practically
wouldn't be allowed to message each other. I agree, that would be draconian.

------
clintonb
I realize that I am nitpicking the nitpicking here...

> JIRA has a screen real estate problem. Have you seen the articles about SERP
> shrinkage, where a G results page in 2004 was mostly results and now it’s
> mostly ads? JIRA started out this way. 90% of the text on the screen isn’t
> your project’s information, it’s JIRA chrome.

Press "z" and "[" in JIRA Cloud to hide the top filter bar and sidebar,
respectively, when viewing a project board. These were the first shortcuts I
learned after the redesign about a year ago.

------
rorygibson
The "organisational memory" point is one of the driving factors behind the
tool / startup I'm building.

[https://getctx.io](https://getctx.io)

tl;dr - It's basically all the good bits of Enterprise Search, but set up to
pull in the data from the cloud based SaaS tools we all use in 2018, and
designed for digital / product teams.

The rationale is, I think that there is no sensible, central place for a
company to store all the types of info they have. Slack doesn't do it all,
Confluence, JIRA or Trello aren't enough, Google Drive is good for some
things...

In my experience (and from many people I've surveyed and spoken to) most
companies end up with loads of these tools, and it's a nightmare to find
specific pieces of content when you have 5+ options for where it could be.

The answer isn't one tool to rule 'em all - it has to be an abstraction - make
the data available but store it (master it) in the various locations.

So, my product indexes Trello, Slack, Google Drive, GitHub and email (and, in
beta, JIRA). It'd be great to get some HN-style feedback :-)

------
kovrik
Can anyone please explain why Slack is so popular?

Isn't it just another IM chat? I've tried it a couple of times and found
nothing special about it.

Also, in all companies I worked at they either had Lync or Skype (because
Enterprise, Windows, Office suite etc.).

Even if company decides to try some fancy IM, isn't it better to switch to
Atlassian HipChat as it gives nice integration with JIRA, Confluence, Bamboo,
BitBucket (assuming company uses Atlassian toolchain)?

~~~
edwong
It's viral business model, phone/desktop apps, and integrations have made it a
leader in workplace messaging. Hooks you with free and hits the sweet spot of
UX.

------
Joeri
In any team development context you need a way of interrupting people when
blocked, so regardless of whether it is slack or skype or something else, you
will need some chat-like tool, unless everyone sits in the same office every
day. That doesn’t mean that pointless interruptions should be encouraged or
even allowed. I’ve always made it a policy of telling people in chat to send
me an email if their question was not blocking, but that only works if your
manager allows it.

Another aspect here is to what degree these tools are introduced for the right
reasons. I’ve seen from the inside (facility services industry) how open plan
offices and flex desks are pushed for cost reasons (fewer sq. m. per employee)
while being marketed as promoting team interaction (studies show it harms
productivity more than helping). Cost is a bad reason, but at least it has an
internal logic. But then you get people who see everyone is going to open plan
and move to open plan also but with lots of empty space, nullifying the cost
advantage and keeping only the downsides. Maybe with slack there’s also a
degree of cargo culting going on.

------
noir-york
Mediums create expectations around availability, presence, and response times.

Phone (excluding VOIP): availability is not expected, but once call is picked
up, response is immediate.

Email: availability is guaranteed (if you know their email), and a response
times range from minutes to next day.

IM / Slack: Availability is known and a response expected in the seconds /
minutes range if you are available.

It comes down to using the right tool for the job@ "hej Jeb, you in the
office?" \- use IM.

Then go over to Jeb's office to continue the discussion on whether to go with
solution A or solution B. Its an indepth discussion that takes over an hour
and Jeb closes his door so the two of you can discuss without interruption.

Back in your own office, you email Jeb with a summary of the discussion and
the points agreed.

Jeb calls back saying "hey, i'm not sure about para X"... You discuss it over
the phone, issue is resolved in a couple of minutes. You post the updated
document to the internal wiki and email the team.

Feeling productive, you decide its time for a coffee, you slack the channel
asking who would care to join you.

When a company normalises the expectation of getting a response to anything in
seconds, interruptions happen all the time and productivity takes a hit.

Also, I hate open offices and thank heavens I only have had to work in one for
a few months. The only true progress we ever made was going through the lunch
menus of all the nearby restuarants.

On the other hand having say, a handful of people in a room (three or four) is
a good balance between the chaos of open office (and real estate cost
efficiencies) and giving everyone their own (potentially isolating) office.

------
jasonkester
My approach to Slack is to treat it like email.

It lives in an open browser tab during work hours, tucked away in a corner of
the screen where I can't see the "IMPORTANT! EMERGENCY!!! READ ME NOW!!!"
warning that is permanently on in the icon. From time to time, when I'm at a
natural stopping point, I'll check email then I'll check Slack.

Never allow it to send notifications or make noise. Certainly never install
any form of native client. That means it's not on your phone or tablet (since
the web version doesn't work on mobile devices anymore). That means it can't
seek your attention when you're not in your office.

It'll send little digest mails if you forget about it for a whole day. For me,
that's enough to remind me that it exists and that I should open a Slack
window as part of my morning email spin.

I've worked with people who have alerts turned on for things, and they can't
even hold a conversation for all the bongling going on on their devices. It
seems unbearable.

------
zitterbewegung
From my understanding Slack at large organizations (10+ employees) don't make
organizations more productive at all. At the place that I work slack is
relatively manageable for the most part. For me to make slack useful I just
turned off all of the chatrooms and everything and make it so that I only
check if it I get @ notified.

There are weird parts of slack by default that seem to be designed to make you
less productive. Why does the #random channel exist at all? Sure it should
cordon off off topic conversations and its designed by slack to increase
engagement but is that what should be there by default?

For the most part though I see Slack as making me more productive. It is much
easier to use than other alternatives. It has a great UI as long as you use
the browser version (all of the native apps for linux are largely broken for
me). If you are a large organization I think you would want to consider
discord (yes I know its targeted for gamers) but it the react community uses
it well in this regard.

------
noobiemcfoob
Slack is a tool, and it's all in how you use it. You and your team need to be
disciplined and on the same page about how to use it.

As for handling organizational memory, we spin up channels as single
discussion forums. It's easy enough to archive them when a conversation ends
(usually lasting ~2 weeks from describing problem to everyone involved
agreeing it was solved).

------
motdiem
I get the author’s frustration - especially with slack’s search features. But
I think it’s possible to use slack as a tool for transient conversation and
notifications. We routinely copy/paste slack chats in other tools (asana,
docs, code comments) when we feel it’s something worth saving. It does require
discipline with tools usage though...

------
StreamBright
Well, this is why i disabled notification for Slack, so i did to everything
else. I read emails when I want to read emails and so on. During meetings
phones should be put on silent and this must be enforced. I think it is very
simple to remain productive in a environment that has so many interruptions.
You just need to follow basic principles.

------
bluecat22
This looks like a problem to be solved with something like a google search
engine for all internal pages and wiki.

Perhaps we should start machine learning to start auto tagging discussions in
Slack with the context they're being done in and then expose a search engine
like interface to all of Slack conversations, wikis etc.

------
partycoder
I think how to divide your rooms is key.

"development" or "engineering" is probably too vague. You may want more
specific things: implementation, testing, release management, incidents and
make sure people to stay on topic.

Then, have a channel for offtopic, informal things and let people ignore it.

------
marenkay
IMHO Slack should be used only as informal communication tool. Neither Slack
nor Discord or others facilitate the most important part: long-term result
from communication.

Why? People are used to WhatsApp, FB Messenger, etc. and chat these days is
mostly without consequences. That also translates to Slack and others.

Effective communication producing results IMHO requires investment. Chat is
the opposite of that.

Anecdotal part from various companies: Slack is mostly a place for slacking
off, doing silly things or send "untraceable" reprimands (since free tier does
not archive) long-term.

Organisation has to be company culture before using tools like Slack, or Slack
will do you no good.

... feel free to replace Slack with any other messaging app.

------
harlanji
I miss not having team chat. People figured stuff out and felt it was
important enough to document... failing that they got up and walked over. This
was 2003ish.

Now I end up either being drained by lack-of-effort questions all day on chat,
or being reprinanded for not being available on chat. I never progress in my
career, and in my mind there's an obvious correlation. I am talented and have
one point of focus, which is a good point of attack for aspiring colleagues
(effectively competitors, sadly). I can get better at saying no, but it
doesn't fly well as most senior member most of the time because I'm called a
"blocker".

------
xab9
my slack strategies lately:

* mute everything, except my team's chat;

* turn off the "is typing" feedback;

* use the web version in a standalone browser (eats 200mb ram only instead of 2+gb, in srware iron at least);

* mute colors with custom "theme";

* turn off emoji display (falls back to :foo: :bar:);

* remove the rest of the emojis with greasemonkey extension (and mute more colors);

* collapse documents by default (really helps with big animated gifs).

But I still am trying to cope with some of the problems mentioned in the
article and sometimes I have this feeling that I'm part of the problem
(expecting fast replies, whining at times, not being constructive enough etc).

------
skc
Never used Slack but I've followed the cycle from little tool that could, to
hip tech buzzword, to celebrity startup and now seemingly back down to...do we
really need this?

I wonder what will come next.

------
Pokepokalypse
OMG: this guy is 100% right about JIRA.

About SLACK; well, it can be used responsibly, if you set ground rules.
Honestly, I've never used it within a team, but across teams. So I never had
the problems he's describing. I can see how it would be abused that way. But
you have the senior leaders set ground rules on usage. (doesn't solve the
search problems).

Chat is a tool. It can be used responsibly to be helpful, or it can be misused
to fuck shit up. Just like any tool.

------
tammer
This assumes everybody's in the same office. Slack has tremendously improved
my team's communication as we're spread across many university buildings.

------
jchw
Wow, this is the most dystopian take possible regarding Slack. Half the time I
can't tell if they're arguing against real-time chat or for IRC.

In any case I think that you could easily argue that most of these things
depend on your organization and what use cases you have for Slack. But wow,
I'm having a hard time visualizing how it could be this bad.

Before Slack, my org had no centralized communication. That sucked way worse
than having Slack.

------
solatic
Reading through this thread, it seems like Slack is really missing more fine-
grained control over channel permissions.

There are largely four types of communication and they need four different
permission designs:

* Important and immediate - stuff like production monitoring and incident resolution. These channels should typically be quiet but they should have the power to notify and interrupt people doing normal work when activity happens. If you have support channels, they should be staffed by dedicated support people whose primary job is to be interrupted by support requests, and not engineers trying to buckle down on their work.

* Important but not immediate - ordinary corporate alignment discussions. These channels should be globally administratively enforced as read-only except for predefined, enforced "meeting hours" which are blocked out organization-wide on everybody's calendar, which is when discussion on issues actually happens. If people have an issue they need to bring up on a particular topic, it can wait until tomorrow, and not interrupt engineers trying to get their work done. People no longer mute these channels because they're not interrupting them during get-work-done hours. If it's too difficult to follow the "meeting" in a dozen different channels then it's probably a sign that your organization has you in charge of too many responsibilities and you should stop looking at the tool as a means of fixing your organizational problems.

* Not important (and either immediate or not immediately): there's a time and place for watercooler channels, and it's not interrupting you in your cubicle. Notifications should be globally administratively disabled entirely for these channels, for everyone, including the people who care about following along in those channels, because nobody should be standing around the watercooler all day long.

Slack's product teams should be looking at mute as a sign of failure that says
"either this tool or this tool's configuration is preventing me from doing my
job" and the product team should respond accordingly (remember: tool
misconfigurations are an admin UX failure that harms your product by damaging
its reputation, and you should fix the UX failure that lead to the
misconfiguration so as to protect your product's reputation). The only mute
button in Slack should be a Slack-wide mute button for vacation etc.

------
chmaynard
I think something useful could be implemented using a distributed model. No
server, no company, just a network of nodes communicating together using the
Internet as it was originally intended to be used. No one makes money on email
and no one should make money on chat.

The underlying implementation could use Git, which would preserve history and
give everyone a complete copy of the repository.

------
seanhandley
Slack, like all tools with built-in notifications, works out much better for
me when I disable the notifications.

I alt+tab to the window now and then to see if anyone's trying to get my
attention and it tells me who, and how many unreads I have.

The key is to not have the notification sound/popup and I can just bury Slack
under my editor, browser etc until I decide I'm available.

------
edwong
Easy to say Slack, JIRA, Trello suck, but what are the alternatives? I used
IRC at two 1000 person companies. It was useful, but didn't replace email like
slack does now. Likely due to lack of persistence, absence on phones and hard
to setup integrations.

Echoing a lot of the comments, you can blame tools for altering the culture.
Phones disrupted memos, email ended vacuum tube delivery, computers killed the
file cabinet. Slack is a reflection of our short attention spans. No one wants
to read long emails. People need an easy way to message and get notified on
all screens. People pass screen shots across their devices. It solves
problems. I've seen people who abuse @mentions and @here, but ultimately you
develop filters and need to take responsibility for one's own workflow.

I do hear how Slack isn't good at making organizational events searchable and
good at archiving in corporate memory. Problem space is: need to search,
recall, store and archive better. Maybe tools to record this into some record
or doc, (i.e. readthedocs). You can argue Facebook/Yammer style status posts
is a better way to broadcast and save announcements. Slack can innovate on UX,
but they seeme focused on growth and quality of service. They're not looking
to solve small issues at this time.

~~~
krick
This isn't really about Slack, it's about the whole paradigm. Maybe it's even
OPs fault that he phrases it this way, but anyhow, if it really would be about
Slack it would imply that something like Facebook Workplace is any better, but
in reality it's infinitely worse on about every possible aspect and beyond.
Even by OPs own metrics.

So it's more about how "emails would be better", and surely not about "how to
replace them". Not sure if I agree or disagree though.

~~~
sundvor
Had Workplace in my last job, just started a new one which uses Slack.

I do _not_ in any shape or form miss Workplace. It was sucking my attention
dry, blocking meant I'd lose out on things that actually matter.

With Slack it's super easy to set notifications to null except for eg mentions
or important groups - and can even have different defaults for mobile vs
desktop.

~~~
krick
Yes, it's horrible. I actually _do_ set all notifications off, which is
borderline rude and arrogant of me, but otherwise my "working hours" would be
pretty much pointless.

For me, actually, the worst part is the shittiest chat app I've ever seen bar
none, especially on desktop. There's no decent app for Linux, browser app is
slow, buggy and constantly leaks memory, the most basic features that, I'd
think are mandatory for any modern chat-app are missing, UI just totally
sucks. It's hard to imagine someone could make an IM-app so bad by chance.

------
nabla9
There is communication bottleneck in any large team. The goal should be to
maximize information sharing and minimize communication.

Communication is scare resource and the use should have budget to create
incentives to save it. Maybe someone can use blockchain hype to create that
monetizes messaging inside companies.

------
bigpeopleareold
Like anything, this is a people problem. I have no issue with Slack because I
have no issue with it personally, because there is no fanatic focus on this
thing in my company.

If it is a problem, it's probably easy to start solving it: don't use it.

------
krausejj
What about the argument that since email is built atop an open standard, you
can (theoretically) migrate to different email servers and clients, but with
Slack, your "organizational memory" is owned by Slack?

------
maxsavin
The "ADD" that Slack creates might be the killer feature. I suspect that many
middle managers may not know how to organize work, and this lets them get away
from that.

The name Slack becomes even more ironic in this context.

------
Dowwie
Is anytime using Zulip and would care to comment about your experience?

~~~
neuracnu
We are at my org, but my only exposure is cross-team / cross-division chatter.
I collaborate with my team across offices through an old Jabber client. This
isn't ideal, but pulling it away from a browser window allows you to
disconnect, set DND status, that sort of thing.

Zulip's focus on streams & discussion topics (over people-groups) is
terrifically handy for tuning into large-scale group chatter, looking at
things that are interesting to you and sharing conversations with others.
Project/task management via Slack or any similar tools just seems bonkers to
me.

------
hokus
I one time kept saying that one shouldn't have a General forum - but no one
understood.

The only way to have the desired archive structures is to _not_ have a dumping
ground. Non of any kind.

------
pcmaffey
Yes— and that’s ok. Slack is more like organizational RAM.

------
loorinm
“it’s like having an old man pee on your face one trickle at a time. I’d
rather have it over with quickly and go wash up.”

I think we’ve all been there.

------
hohenheim
Slack is a tool, just like kitchen knife is. Used correctly, it is valuable.
Otherwise, I agree with all you said.

------
shishironline
Great post. Hits exactly the sore point of working in today's environment.

------
douglaswlance
Slack should be used as a CLI for your business. It not _only_ a chat room.

If you want documentation, then add a command for `/doc "title"` and start a
collaborative document.

If you want to add a task, `/task add "title"`

etc.

Its a shared command line, not only chat.

------
matchagaucho
/giphy amen

------
deobald
Relay is a Slack alternative: [https://www.relay-chat.com](https://www.relay-
chat.com)

So far, a Relay organization is a hosted Mattermost instance. Slack isn't
exactly revolutionary software and it seems silly that persistent IRC (that's
all Slack is) should cost so much money or run on a proprietary, users-as-
inventory, data-gobbling platform.

1\. Why does Relay exist?

We built Relay for precisely this reason. Mattermost is pretty cool but we
(nilenso.com) are not a military contractor or a bank. We didn't need
Mattermost hidden deep in our datacenter; we just wanted hosted Mattermost so
we could stop handing over every byte of our internal data to Slack, Inc.

If Relay existed a year ago, we would have paid for it. So we built it (for)
ourselves.

2\. What's the plan, Stan?

As long as we can, we want to stay in sync with the Mattermost mainline. All
our code is open source ([https://gitlab.com/nilenso/relay-
backend](https://gitlab.com/nilenso/relay-backend) and
[https://gitlab.com/nilenso/relay-ops](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](https://twitter.com/relay_chat/status/962936101919838208)

Shout on Open Relay [1]: [https://open.relay-
chat.com/signup_email](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).

------
cmcginty
I think people forget what it was like before Slack. Sitting down to 30+
emails by 9:00AM and over 200 in a single day. It was death by email threads
and following them was a horrible time suck. Worse off, email was treated like
a real time conversation so you were expected to tracking it all the time
through the day.

Slack solves a lot of this. The channels are opt in. If you don't want to
follow something, just leave. Email is now just for async messages and is less
of a distraction during core hours.

If your team or Co uses one channel for all your discussions, then I suggest
that you find a way to split out the primary topics in a way that lets
everyone filter the wheat from the chaff.

Like others are saying, don't blame the tools for being misused. Ultimately
you have to learn how to efficiently communicate with your team and be
disciplined enough to know what tool to use for each type of task.

~~~
i_shankar
Agree 100% on the last para.

------
physicsguy
My issue with Slack in our organisation (a University), is that people spawn
off new teams for everything, and nobody has a paid group, because it's too
expensive with our budgets, so you lose the conversations by age at 20000
messages.

This has led to the situation where I'm in (a) My research group's group (b)
One for people who program within the University (c) One for a side project
I'm involved in (d) Slack channels for some software I use as dependency in my
own project (e) One for a language specific group (f) One which is a group we
share with collaborators at other Universities (g) About 5 more that have now
been abandoned.

And because of that, I end up just turning off Slack all day and checking it
in the evening, because I don't find it conducive to research work where I
mostly work independently anyway.

