Curing Our Slack Addiction | Hacker News Reader

Curing Our Slack Addiction

blog.agilebits.com

358 pointsingve182 comments

Slack does a good job overall, but I'm glad to see articles like this one challenging the enthusiasm that they've seen of late. I'm starting to share the article's opinion that Slack encourages unthoughtful communication. I do wish the author had spent a little time pointing out some specific product decisions that lead to the kinds of problematic communication they were seeing.

For example, basic product choices like "every message highlights a room for attention" creates, for me, a feeling of "farmville for corporate communications." There's always another channel to click, another few sentences to read. This makes Slack very engaging at first, and makes it highly successful at lodging itself into organizations. And that's great, because Slack's a far sight better than email. But this rapid-fire feel encourages synchronous communications, and everyone quickly learns that @-mentions and DMs get quicker responses. That in turn leads to communicating with individuals instead of teams (or instead of searching issues, or Jira, or a wiki, or whatever). I don't think chat has to be this way; product decisions can encourage a more thoughtful question and answer flow.

I think that Chat may be like product management: the product opinions matter quite a bit, and teams have varying styles, so there's room in the market for several different products. Slack does a great job for a certain communication style, but it's not the only style out there. I hope some competing products with different opinions gain enough traction to keep them honest.

I agree. What I'd like to see is to batch room highlights when you're not mentioned. For example, allow me to batch highlights every 30 mins, and then the temptation to read everything goes away.

Better copy/paste (like most IM apps) would also make it easier to copy/paste some discussion into your bug tracker of choice.

I have a hard time agreeing that "Slack's a far sight better than email."

The lack of threading and context (mentioned in AB's writeup) means you have to maintain a lot of state (and keep up to date) in order to get any value. That defeats the point of having automation!

For good or ill, the 40+ year history of mail means there are various tools and conventions that allow your computer to do part of the work for you.

I recently disabled threading in my email as I have an unfortunate number of people who regularly : send mail using identical subject lines, reply to whatever my previous email to them was rather than come up with a new subject line or send multiple versions of important documents under the same subject/RE the same message over the course of months. This results in a hideous nightmare of thread spaghetti where I can't find stuff, or worse, I'm looking at the wrong iteration of something. Oh, and did I mention all the people who have MIME attachment email footers so that figuring out which email contains the document they sent means looking through every single mail? [0]

So I flattened it back down to chronological order and it feels like that restored a lot of sanity.

[0] Obviously a lot of this chaos can be tamed with a more aggressive process for inbox management, but that kind of plays into my point, that's all out of process manual work that a better communication tool should help me with.

I have seen this among all my friends that aren't that computer knowledgeable.

They just search for an email with the same set of people that they want to sent an email to, choose reply all and change the content.

This is a symptom of bad address books in the email software.

If you use a quality mail client (such as Thunderbird) it doesn't rely on subject for threading and fixes these problems. As well as displaying the replies in a proper tree rather then as a giant list.

Also, email is an open standard, with plenty of choices in both client and server software. Slack is a proprietary system. Why are we actively axing solid, widely distributed, open ecosystems for proprietary ones? It'd be like if everyone woke up one day and decide "eh, Linux is just not animated-giphy enough, let's all switch to this startup OS with a crippled free version."

I don't think any of these corporations that use Slack are axing email. They still need to communicate with people outside of the organisation, right?

In fact, Slack users have reported an average of 50% reduction of internal email (source: https://slack.com/results). But you're right, Slack is a closed system, and thus it cannot really replace email when used for external communications.

This is where Fleep comes in - a messenger that works with email, too. You can include anyone in a conversation with their email address, and if they're not a Fleep user yet, they can participate in the conversation via email. Fleep: https://fleep.io/

(Disclaimer: I do work at Fleep, and I love it :) )

Hadn't heard of Fleep before, but thought immediately that it might solve one use case for me.

After checking the pricing (good), if there was a self-hosted version (no, but maybe not a deal breaker) I looked for the Android app installer. Only available from Google Play Store. Unfortunately, that kills Fleep for me.

Please consider making your app directly downloadable and not reliant on Google Play Services.

Why is this a requirement?

I don't have Goggle Play Services installed on my phone and am not going to do so.

I understand why companies want their apps in the "Store" for discovery purposes. However, I don't understand why they won't provide an alternative direct download.

I do have F-Droid installed, but I appreciate companies may not want to open source their app. No problem, but I also won't be forced to install Google Play just to obtain it.

The Google Play store is also not accessible in China, an no doubt a few other countries, so it's just sensible to provide an alternative download anyway...

As I'm sure you know, .apk files can be downloaded using a computer without Google Play Services being on the phone.

https://www.androidpit.com/how-to-download-apk-file-from-goo...

Because Slack doesn't have to write up an RFC and wait months/years for feedback before getting features implemented. People care about features, not interoperability (until they want out, at which point they feel the lock-in burn).

I disagree with this. Other than the place-keeping, search, and notifications, I (and my team) don't want other features from Slack. In fact, the constant additions of features is aggravating as hell. The addition of an enabled-by-default DND feature was a real PITA for our team to try and work around.

Slack's pinning UX baffles me.

My previous team used Slack to coordinate releases (deploys). (Automation? What's that?)

The devops lead would post the release notes, whatifs and whatnots, then pin them, hoping for easy recall when the chat activity scrolls them offscreen. Great idea. I never got the hang of Slack's implementation.

Here's my best practices list:

1. The best use of slack is the free edition which has limited history. Once this lack of history is made clear, people use it simply for online pings. Since notes, files and everything will disappear, people will automatically put the effort to put those things in the right tools (wiki, bug tracker etc).

2. Don't expect people to be online. It's the same as irc. If people are there, they are expecting to be interrupted / they are feeling helpful at that moment.

3. Integrations.. are a gimmick. There is really no value in knowing someone commented on some github issue instantly. Or someone committed something. Use integrations only for firefighting. But because of 2) use this carefull because you shouldn't expect anyone to be around. Paging/sms/email is best for this. After all, these are already used and it's not slack makes these obsolete.

The integrations are indeed a gimmick. They consume so much space that they end up being shoved into their own channel, where nobody ever looks... so what was the point of them again?

Completely disagree. There's a tons and tons of ways to use them.

Sure it can be gimmick or it can be an extremely valuable tool and usually they are somewhere in-between.

In my own experience I've found they are a great replacement for many different types of email notifications such are exceptions from an application. Things you want to glance at and maybe take action on. When these are an email I have to "manage" them, choose where to put them or to delete them or whatever. And I eventually end up just filtering them into an inbox I rarely look at.

As a channel though it's just the right amount of attention and time to them. Took some time adjusting settings to get the right level of exceptions to show up and we still have them all in the exception tracker itself.

The other thing is I only check my email a couple times a day. because most of what goes into my inbox is not time sensitive. Whereas Slack is always on if I'm working so I will instantly see if there's a major issue on the site.

Of course every company is different and has different needs. But writing off all integrations as a gimmick is narrow minded.

It's a gimmick based on why you came to use the tool. My understanding is that it's goal is for team communication and all these alerts are simply distracting.

But maybe slack should position itself as an advanced alert management tool (which is what many seem to use it for).

I agree that some integrations are a gimmick, but having content relevant integrations has helped out our team immensely. We'll have channels specific to a project, so notifications that JIRA stories have been resolved, knowing if a build fails, exception logs from production, are all intertwined with us discussing the project throughout the day so they get exposure.

One thing that we've loved is being able to log information into other tools when it is top of mind. Discussing a recent bug that you noticed "/jirio create bug Username can contain spaces" and it's logged in JIRA to be dealt with accordingly.

The potential for custom integrations is incredible but obviously keeping the noise level down is key.

So, in best case, the integrations are equivalent to the whole ecosystem of IRC integrations in existence?

That's interesting. And still leads to the question "why slack, not IRC"?

I've asked that question myself - particularly considering how expensive slack is. Some differences include:

1. Secure usernames integrated properly into the protocol, instead of relying on nickserv and configuring your client to send a dm when you connect which is far from a simple/intuitive system. This includes options for google/corporate single-sign-on and 2-factor auth.

2. Infinite searchable scrollback which keeps position properly across multiple devices. As an experienced IRC user I can achieve something similar using ssh+screen+irssi - but it's hard to use even for advanced users, and I can't imagine trying to use it from my phone.

3. Offline messaging that doesn't rely on the user knowing the right magic commands to activate the bot. Bob is offline - do I need to !tell bob whatever or !ask bob whatever? Can I DM it to the bot to avoid spamming the channel? What's the help command? Can I use that over DM? Is there even a bot in this channel?

4. Integrations are exceptionally easy to write. You can post to a channel with a single curl command. Obviously writing IRC bots is possible, but it's a lot more complicated.

For me personally, even these differences taken together don't seem worth the expense of slack. But I would understand if other people see it differently, especially if they're not that experienced with IRC.

For the first, IRC has a solution for that, too.

1. SASL auth – some servers even support Oauth via SASL, or certificate login.

2. That’s what Quassel and IRCCloud provide as a one-click solution.

3. With everyone using Quassel or IRCCloud, this also becomes easy.

4. There are many services that provide webhook -> IRC services ;)

As someone who has been using Quassel, where everyone else uses Quassel, and who uses SASL auth, all the issues you mentioned stopped existing long ago.

Add the expense of Slack, and one seriously wonders if it’s just discoverability.

And packaging. Just picking on one of the ones you've suggested: Quassel is an app, so I can't easily try it out. I certainly can't invite everyone in my company to use it by clicking a single link in an e-mail. It doesn't have an iPhone app, I think those are quite popular. And so on.

Seriously, all these things are pretty easy, as evidenced by the fact they've been working since the 80's in the form of IRC.

The value appears to be in packaging them up as a modern web app (and having a lot of success in tech-industry PR which is where Slack has excelled beyond e.g. HipChat. But even that is partly down to the good packaging of the onboarding process).

Interestingly, that's exactly what I personally am working on: mobile clients for Quassel, easy deployment (single docket container for everything), quassel-as-a-service for people to just invite others, etc.

A web app also exists, but the discoveravility is an issue.

Packing the things up properly, marketing them well, etc is easier, as we also have the advantage of being open source, which helps in open source communities.

I disagree. Twitter integration is great because it gives us a way to have tweets about our brand appear and we can discuss each one if needed.

Munin integration via our bot just alerted us to the Linode DDoS today.

We've created our own bot which recognizes bug ID's and expands the bug with title, description and status and a link. Same with support tickets.

Also our bot can draw cows on demand. Very important that.

Twitter-wise, even better is to respond from Slack to tweets in real time with this integration — https://sameroom.io/integrations/respond-to-twitter-from-sla... [0]

[0] shameless

Thanks for sharing. A channel for every tweet would create a lot of channels for us. We've had a few hundred tweets today. https://twitter.com/search?f=tweets&vertical=default&q=wordf...

In general our workflow is to have 2 people in the org able to reply to tweets. And the rest of us are the peanut gallery just expressing what we think in the channel. So it works better to have it read-only in a single channel - at least for our purposes.

Right now we just see name, username, link and tweet. So it might be useful to unfurl that a little and show number of followers/following and give permissions to specific usernames to reply in-channel. Also create @channel or @username alerts when a twitter user has more than X followers - although I really hate that idea because I've seen people who (I'm pretty sure) buy followers bullying companies on twitter to get VIP treatment - but I guess that could be useful too.

It's a channel for every "conversation", not tweet. The benefit here is that you can keep talking to someone without asking them to email support@company.com.

There is usually a window of open channels -- 15 or 40, say, that remain active in parallel. Oldest channels outside the window get auto-archived. You can also favorite directly from Slack with "-sameroom <3".

Only those people who are "on call" will actually see the channels (for details, see https://docs.google.com/document/d/1Cg7LQOVZbkm8tmUyc_yJsp8e...)

This seems terrible. If much rather people used proper support software like desk for support

That is one way of thinking about the world. Another way is to consider all software as support software. The machines are supposed to be there to help us.

There are countless players offering transactional support systems, and just like every other Big Software Vertical, the industry is still re-aligning around "Web 2.0". Desk's primary market distinction is that Salesforce owns them. (That's a huge selling point in the enterprise, but not necessarily interesting to the HN crowd.)

The grandparent post is describing a workflow for more conversational customer interactions. The industry term-of-art for this is something like multi-channel support, but Slack's Big Philosophy is to just be more playful. The "proper software" to use is the software that gets stuff done.

If you get more than two people defining what "proper support software" is, you end up with something like this: https://en.wikipedia.org/wiki/BMC_Remedy_Action_Request_Syst...

People just have different workflows. ¯\_(ツ)_/¯

3. Integrations are mostly gimmicks. FTFY

Sharing files is another convenience which is also in the free edition.

> 2. Don't expect people to be online. It's the same as irc. If people are there, they are expecting to be interrupted / they are feeling helpful at that moment.

One of the reasons I don't like Slack is that people contact me when I'm off shift. I support APAC and so work different hours from most of my company. If I have a problem, I have to either email someone, or DM someone who isn't online. Either way, my voice goes into the black hole. Likewise, they return my DM in the morning, and their reply goes into the void if Slack doesn't wake me.

But with our corporate culture buying into the "always online" concept of Slack, I can't easily communicate how email-like it can be.

Slack isn't necessarily the problem in many situations. The problem is often how the tool highlights personal and culture problems instead of helping to smooth them over, by making them less evident. Email and other asynchronous communication can hide gaps in an organization by removing the pressure to respond immediately.

Can't you just set your status to away and not respond? People can email you when you aren't working as well. It's no different.

This really seems to be a culture problem.

We have long time established custom, that if you want to communicate with somebody via chat, you send him a 'ping' first, and wait if he responds.

We have long time established custom, that if you want to communicate with somebody via chat, you send him a 'ping' first, and wait if he responds.

On my list of pet peeves, this one is near the top. Nothing annoys me more than getting a chat message as follows: "Hey..." Because it's apparently not enough to bother me with a DM, one must first make sure that the "ping" is a complete waste of electrons, apparently. Once my train of thought is completely broken, then and only then are conditions right so as to allow the individual to fully absorb the weight of what you are about to type.

Here's an idea: how about typing WTF it is that you want, and if I respond you'll know I'm online. Typing "got a minute?" w/o any context is a sure-fired way to get me to ignore you.

With that screed out of the way, I am open to arguments on the value of sending a "ping" first. Better make it convincing. :-)

Was thinking about it, and I don't think I have arguments that would convince you :P But if we happened to work together and you were ignoring my pings long enough but was responsive to i.e. well written detailed emails, I think I would adjust.

But for me, ping signifies "I think I need to talk to you, but the details are kinda sketchy, so get back to me at your confinience.".

Integrations are useful to avoid an extra step, especially when the person you want is exactly the person who is "expecting to be interrupted / they are feeling helpful at that moment". E.g. when someone submits a PR - email would fill up everyone's inbox, paging/sms would be far too noisy. What you want is whoever's available at the moment to go review it - so Slack is the best channel to be notified.

Having build statuses posted in a channel for each commit is a great for forcing CI and CD.

"Integrations.. are a gimmick"

I disagree, some are. Giphy, though a pleasure to have on the team is a gimmick. Hubot is an essential member of the team. Our company is deploying pretty much all day, and the integration of our deployment system with the bot scripts make things so much easier.

Agreed. We have custom integrations with Sensu and Kapacitor to alert us about HTTP 500 errors, services with high resource usage, scheduled tasks that didn't succeed, etc.

> Giphy, though a pleasure to have on the team

I couldn't disagree more. I hate giphy integrations, and I disable them in any room I have any control in.

It becomes abused far too easily, and the results are so rarely relevant. "/giphy high five" will return a gif of someone high-fiving 30% of the time, and will return nonsense garbage the rest of the time, prompting people to try, try again, flooding the room with animated images of celebrities, minions, or whatever other garbage someone has uploaded and tagged poorly.

And that's not counting the one jackass who just gets bored and starts flooding the room with random gifs. (That happens much more rarely in work-dedicated channels, but it makes off-topic rooms a chore.)

100% gimmick, 0% pleasure.

> "/giphy high five" will return a gif of someone high-fiving 30% of the time, and will return nonsense garbage the rest of the time

Try https://rightgif.com/. Although it's one of those products that make you think tech startups have finally jumped the shark, it works surprisingly well.

> control

This is the heart of the issue. If you are in a room that you don't like being in, then leave the room.

Communicating with other humans is difficult. If your team can't come to an understanding about how you have fun together, then you have much bigger problems.

> If you are in a room that you don't like being in, then leave the room.

... unless it's actually a work room that just happens to have lax rules about what is and isn't appropriate.

... unless you're a remote employee, and it's one of the only ways to build team cohesion outside of 100%-work conversations.

A room that you want to leave, but can't, is usually called a Prison. Escape the room, already!

Off-topic, but: AgileBits is one of my favorite companies ever.

- Fantastic product

- … which genuinely helps people

- … which has evolved and matured in an impeccable manner

- … which has, as far as I’m aware, never failed critically (no data loss or security breaches – hell, they are so proactive that 1Password saves multiple DB backups for you just in case they eventually mess up)

- … which sports good and native apps for all major platforms, including icky ones I’m sure the founders don’t prefer. (They have this in common with WhatsApp!)

- Helpful, knowledgeable, and quick support

- Didn’t shut the company down after 2, 3, 4, or 10 years just because they weren’t on track to be a billion dollar company in the next few quarters

Whatever culture these guys have? Copy that.

> Didn’t shut the company down after 2, 3, 4, or 10 years just because they weren’t on track to be a billion dollar company in the next few quarters

Who has ever shut down a company for that reason? Typically startups die when they run out of money.

Other than that I agree with you: they seem admirably humble and impressively reliable.

I don't think it is as common as many people think, but I've experienced it in a few forms in the past. At one place we were making enough money to pay the bills and were growing slowly. The founder wanted an exit with multiples on his investment. He went shopping around to sell the company, but break even with slow growth is a hard sell. He eventually made the decision to discontinue the revenue making side of the company and focus 100% on building something that he thought could sell the company. He failed in that attempt.

One thing to keep in mind is that for an entrepreneur it may not be a good business decision to keep working on a project that isn't going to have an exit. If you have no way to hand it off to someone else, then sometimes it is better to redirect your funds into something that is more likely to get you a better return. So in the case I mentioned above, he felt he couldn't get the return he wanted, so he redirected the resources of the company to try to get that return.

Even though you can burn through a lot of companies that way, if you are eventually successful you can make a lot of money for yourself and your investors. Many of the people I've worked with in the past I call "serial entrepreneurs" and they know how to eventually win. It's not much fun if you are interested in building a product, though.

On the other hand they've been moving to a subscription model, starting a slow deprecation of the standalone product. Towards this end they've introduced the $5 / month family plan and killed the Mac-only option, while raising the price of the Mac+Windows option. At this point it's worth noting that the Windows client is old and buggy. They did this, as I said, to raise attractiveness of the $5 / month family plan, being the oldest trick in the book: setting an anchor for comparisons.

First of all I find $5 / month to be expensive. Yes, that may be the price of 2 coffees, but if you pay that kind of money for any service/app used, pretty soon you're talking about real money. I also like to own things and I hate renting things, being a terrible tenant. I cannot justify a rent of $60 per year for services/apps unless they are investments producing money. Something like 1Password keeps me safe, but it doesn't make me more productive when programming and it's not helping me with sales either. I can justify subscriptions for Dropbox or IntelliJ IDEA or for keeping my domain active, but not for password storage.

I guess what really bothers me is that 1Password is moving away from the things that made me pick it in the first place: standalone app, Dropbox/Wifi sync, Everywhere interface. I expected them to build the Everywhere interface for opvault, to introduce GDrive/OneDrive sync as an option, to fix their Windows client and maybe to introduce a Linux client. Their new Windows client that's the successor to the old one is a "modern Windows" app distributed through the Windows store, which means I won't even be able to keep running 1Password through Wine.

But there's another reason I prefer standalone apps. With the family/business plans they promise a web interface and they promise that after you are dead your wife or children will be able to access your vault. Of course, if I'm dead, the subscription would end because nobody would realize that they need to renew it in time, so that's an odd point to make. But skipping over that, this means that the vault is now stored on their servers and they have access to it and to your one password whenever you login. If you thought the Dropbox sync was insecure, think again.

So unfortunately they took the bait and decided to spend resources on a subscription model, which is exactly what makes me run away. In the grand scheme of things I guess it makes sense and I hope it works out for them. But along with DRM, trusted computing and the overall trend of bait and switch, I find it to be quite treacherous.

> I expected them to build the Everywhere interface for opvault

I realize this may only partially help you, but onepasswordpy (https://github.com/Roguelazer/onepasswordpy) has support for both Agilekeychain and the OpVault, if you find yourself on a system that isn't Mac or Windows, or otherwise is a PitA to get to your keychain/vault.

In fairness(?) to Agilebits, the 1Password Anywhere really was just the most bare-bones possible, as it didn't support any of the encrypted items except Login; so no Passwords, Secure Notes, no attachments on anything. Maybe they just figured it wasn't worth the hassle to flesh it out, and then with opvault it became a lower priority than it was before.

Hi there!

I work for AgileBits, the people behind the linked blog post and 1Password :) Just fair warning at the start.

You're right, we did combine our Mac and Windows options together. The primary reason for this was to make it easier. It's far easier to have a single purchase option on our store page than to have multiple. We went from 3 (Mac, Windows, Mac+Windows) to 1 (Mac+Windows).

An important note though, the price went down for this combo not up, it was previously $70 USD and is now $65 USD.

The $5/mo we advertise for Families is if you pay monthly. There's an option to pay yearly and that saves you money, which comes out to $48/year instead of $60, so $4/mo instead of $5/mo. Users who signed up early during our special launch special also got $10 in credit, making the first year a total of $38 if paid yearly.

I wouldn't say we're moving away from what made you like us in the beginning. We still offer our standalone apps, we still offer Dropbox, iCloud and wifi sync (and we're continually improving them). In fact, we just added OPVault support to our Android application, which should further confirm that these options aren't disappearing. OPVault is not used for our Teams or Family options. Teams and Families are in addition to what we already offered and it gives us some new options for making 1Password better that we couldn't do with the standalone option.

One of our most common customer support inquiries is why they are asked for a license on their desktop after downloading the iOS app. We can better solve this by having a subscription option since it includes everything and reduces the user's cost to try it out. Once you change all of your passwords to passwords you don't know, the need to have those passwords on all devices becomes even more important. Making those apps available on all devices as easily as possible is a big deal. Users on hacker news are unlikely to struggle with this but average users still do. I have to explain these things to my parents regularly.

The problem with doing an "Everywhere" interface for OPVault is that it was only ever going to be Read-Only. With the Teams and Family implementation we were able to make it capable of reading and writing. We're sad to not see an 1PasswordEverywhere for OPVault but the Teams/Families interface is significantly better than anything we could've done with 1PasswordAnywhere.

Another really important distinction is that if you stop paying for a Team or Family account that account simply goes into read-only state. This means if you were to die your wife or children will still be able to access your account if you haven't paid. We really tried to do the right thing here and not lock users out of their data.

For Windows, which I've saved for last here, is that we're well aware that you want more from our Windows app. We hear our users loud and clear and we're doing our best to help improve things there. It may take some time to get there but we have things happening behind the scenes here.

I can't comment on any Linux client but this is something I personally would like to see and we've had a lot of requests for it so I keep crossing my fingers that we'll get to this. Linux is one of the reasons I'm really excited that Swift is open source because it's possible that we might be able to share some of this across platforms. There are times I really want 1Password command line integration and while I primarily use a Mac I realize this type of thing could be shared.

I hope that helps answer some of your concerns. I'm just an iOS developer and customer support person here at AgileBits but we do listen and we try our best to help our users as best they can. If you have any questions, feel free to ask and I'll do my best to keep an eye on things here.

Kyle

> We all knew how great it would be to have a repository of knowledge for people to find their answers, but Slack was simply too good at providing the quick fix we all needed.

I'm seeing this across numerous open source project communities, and it's really infuriating. B/c these communities are not paying Slack, they don't have access to archives, and of course it's all invisible to Google. So a valuable Q&A that might help thousands of people over many years were in on a public forum winds up helping...the handful of people who were in the channel on the day it happened.

I couldn't agree more. Either ppl don't know or don't treat it of value to have history.

Information dropping into a black hole happens in IRC on Freenode all day, every day. The issue isn't just Slack.

actually, most channels have logging. I've frequently stumbled across solutions on public (and indexed!) IRC logs.

Many IRC channels are archived and the archives are searchable, so the information is not necessarily lost.

Archives are a start, but the problem is most channels are not indexed. There is no "google for irc" of sorts.

Even if the archives are searchable (the searches generally suck in the first place), who's going to know to go into this specific archive, for this specific channel, and search for this particular query?

As someone who was interested in this a few years ago: This is still an open problem for someone to solve. The solution isn't particularly hard, it's just nobody has really gotten to it yet.

(And yes, you may come across the odd irc conversation in your google searches once in a while - but it is not to scale with the immense amount of information that comes out of irc).

Every single open source project's IRC channel I've seen is logged and searchable, with a link in the topic.

Please re-read my post. Searchable doesn't mean indexed and mass-searchable.

Are you going to know that the problem you are encountering with your bluetooth connection was solved in freenode's #pulseaudio 3 years ago?

Here's a solution, e.g. for the #rust channel: https://botbot.me/mozilla/rust/

Botbot is nice but does not solve the issue of mass-searchability.

Oddly enough, I prefer the IRC channels I frequent to not be logged, just like the conversation I'm having at the corner coffee shop (probably) isn't logged beyond the ears of those who hear it.

To me it helps create more of a community feel. Often times you'll see active community members turn problems they deal with on IRC into blogs, articles or even books to spread that knowledge.

I have no idea why the answer to this problem is "using Basecamp!" - That doesn't make sense to me at all. For me the answer has been to turn off notifications and shut Slack when I need to go heads down, but review it multiple times a day and chime in where needed. It's still such a vast improvement over an email or email+issues based workflow.

The CEO of a flat company probably has a need to see everything, JIC. Not all use cases are equal.

Sure, but how does Basecamp fix the problem? Wait for part 2, I guess.

Asynchronous communication ... slows things down and encourages a bit more thoughtful communication.

The founder of Basecamp alluded to this in a post very similar to this one https://m.signalvnoise.com/is-group-chat-making-you-sweat-74...

> The CEO of a flat company probably has a need to see everything

And Slack does an excellent job at demonstrating why that is idealistic nonsense and simply bad management that doesn't work, simply by making it possible to actually see almost _everything_.

It's one of the great things about Slack, it's much like Scrum in that respect: it may not be the answer, but it sure as hell will confront you with what the actual questions are.

Unfortunately, people who don't want to face their problems will immediately turn around and blame the tool/method. So very typical.

This is exactly the issue. Slack will expose more issues than it will create. If people misuse a tool because of some underlying problems, switching tools will just hide the problems, not solve them.

Exactly. I have DND mode configured for between 5 PM and 8 AM. No notifications, unless it's absolutely urgent. Which hasn't happened yet (thankfully!).

Reading this article was honestly sickening. As I went on I got a growing sense of something horribly wrong with the author/culture of the company. And then these paragraphs all out confirmed my suspicions:

> Slack forced me to evaluate things very fast and respond quickly, otherwise I would miss my opportunity to join a conversation before it moved onto something else.

> Then there was the fact that we had so many channels and direct messages and group chats. It multiplexed my brain and left me in a constant state of anxiety, feeling that I needed to always be on guard.

> And I had to read everything. I felt that I had no choice as often decisions would be made in Slack that I needed to know. And in other ways it was simply an addiction that needed to be fed.

Blaming the tool for this kind of behavior would be comical but for the fact that it's actually scary scary to see someone with this little self awareness. At least he got the "addiction" part right.

Reality check. My company of ~80 people uses Slack (sparingly) as a slightly better alternative to gchat/Skype. We have jira for issues and a wiki for persistent knowledge. No one here likes being interrupted or always being on guard for the next chance to participate in a conversation. So we just don't do it and Slack has yet to force us to.

I dunno. The tool didn't work for the author.

Are they really to blame for this? It's an alternate view. One I don't agree with either: but that's fine. I don't have to agree with everything.

If it doesn't work for their team, they're saying "it didn't work for us: don't force it for you, too." I see nothing wrong with that.

You have a positive experience with Slack. I use Slack too.

One thing I an certain of, and this goes beyond Slack: people often spend a lot of time giving valuable input into a situation. That input should most definitely, absolutely, be read. If they didn't think it was important, they would not have spent the time on it.

Using chat applications like Slack, it's extremely easy to feel like others are skimming over that important information. Sometimes I get the feeling that I did not give an adequate response: it's only because I didn't have time.

I don't like coming across this way. Seems the author doesn't, either.

The author cares about their culture, and the business, in a very deep and obvious way. Maybe too much. Who's to judge?

I think I'll stick with email from now on.

Same here. It's very hard to get actual work done when one is constantly distracted by conversations that can't safely be ignored. Email is bad enough, in that regard.

An old-school analogy comes to mind. People used to BS in common space. But it was just BS. Decisions were made, or at least formalized, in meetings.

For what it's worth, last week I asked for help with user testing a couple new features on a startup in three different Slack groups I'm a member of, and also via around 150 cold emails. Response rates were 21x better to the same ask in a cold email versus a Slack message.

And this isn't just a one-off either, I've seen other people report the same thing consistently, where 'conversion' rates in response to even the most basic questions or asks are pretty much zero.

Like IRC vs email. #shocker

The difference is that with Slack you usually have some sort of common bond with the other people there, in terms of being either members of the same organization or else mutual alumni of some organization.

Because of that it's not immediately obvious that Slack should be no different than just asking a Linux question in some random FreeNode channel or whatever. That's actually a pretty big issue that doesn't bode well for the longterm viability of Slack, if (for example) it turns out that it leads to significantly worse organizational decision-making than email due to lower participation rates.

That's funny, since starting to use Slack I struggle to remember to check my email. Not much important happens there any more for me.

> Blaming the tool for this kind of behavior would be comical but for the fact that it's actually scary scary to see someone with this little self awareness.

It' not at all comical. I think the part you don't get is that this is the _main_ reason why most people started trying out slack to start with. People were using chat before slack as well. The reason they tried slack was because of the notifications, alerts, integrations and history. When you get these features, the tool becomes very different from irc and this is what the post is about.

First off, the author acknowledges that it's not the tool's fault. The author specifically indicates that they were aware it was a cultural problem and tried to fix it. The author specifically says that they were hoping to reintegrate slack once they figured out how to do it in a more healthy fashion.

Your comment, on the other hand, passes quick, merciless judgement on a culture you have exactly one blog post's worth of insight into… Unaided by the benefit of a careful reading of that post's content.

> Reading this article was honestly sickening.

Judge not lest ye be judged, I would say.

I agree. For me, the red flag was when the coworker asked him why he was so stressed. If things are working for other people, but not you, then something on your end probably needs to change. To me, it sounds like the author needs to trust his coworkers more. It's OK not to be involved in every decision. Sit back and let people own some things, and save your focus for the things you've decided to own. Everyone will be happier and more productive.

>Reading this article was honestly sickening

Really dude? Why you don't check your tolerance threshold?

Recently I've seen a lot of anti-Slack articles.

Not once have I heard a colleague criticising Slack. Every startup I know is using it and praising it.

When I work with some people who still use email to coordinate in situations where I usually use Slack, I find it to be maddeningly time-wasting. Email is terrible for group conversation.

It strikes me that there must be some more general for the Slack criticism. Perhaps the hype cycle effect? Or the inevitable fact that at least some companies will use a tool ineffectively, given enough adoption?

To anyone who hasn't already used Slack - I'd recommend a trial, especially if your organisation has a culture of group discussion via email. I've found it to be an excellent tool, particularly when coordinating remotely.

I think you don't get the article at all.

Slack is heroin (is the point), it is great to start, and seems great for a while, but for many people it gets worse and worse as time goes by.

You have not answered the point at all.

Obviously many people spend their lives enjoying heroin (with no bad affects)

But for many it's toxic, why are you not just an addict selling something you yet don't understand?

[Disclaimer: I work for AgileBits. I also started the #slack-murderer hashtag inside :slack: before we switched over. My opinions are my own. Just ask anyone at AG!]

"Slack is heroin" is pretty accurate. Instant communication (and video games, and Facebook, and Y-Combinator ...) feeds the gratification / pleasure parts of the brain. That's great if one is working on their own time and can enjoy the inevitable crash when everyone else has finally gone to sleep, but when you've got a company full of people flitting around like crazy, because their neurochemistry says they have to "keep up", because "keeping up" is what keeps the brain in a happy mood -- that's a bad thing.

Changing collaboration software won't do a damned thing until teams have a chance to attend Narcotics Anonymous meetings.

The ironic thing is that email fixes pretty much all of the problems that Slack creates.

Slack is still better for sending out random links and messages about lost car keys or whatever, rather than having those clog everyone's inboxes, but beyond that it quickly becomes an anti-pattern that enables a huge array of self-destructive behaviors.

The article inspired me, next time I'm on a product team, to pair Slack with the discipline of the Pomodoro technique. If a notification comes in and I need to take a "soft interruption" to check it in the midst of a pomodoro, I'll respond like I would IRL: ask "I'm in the middle of a pomodoro; can I get back to you in 12 minutes?" If yes, write down a task on my to do list and return to it at the end. If no, cancel the pomodoro and reflect on how to improve our process in the future to avoid such costly interruptions.

If enough Slack interruptions happen, it will hopefully become clear that I just need to close the app in the midst of the pomodoro, only opening it on breaks, and even then only to triage to do items for future pomodoros. If not, then simply continue down that path.

The trick would be to get everyone to buy in to protecting their own time to focus. That requires a very disciplined culture indeed. One that values balancing people's ability to create with clearing other people's obstacles and above all else encourages every person to participate fully in the governance of their team.

While I understand the motivation to move away from Slack, Basecamp, to me, seems like a worse alternative.

Most of my Basecamp interactions come from the emails that are sent on every thread change. It almost seems to be a proxy between conversation and email, which is counterproductive to its goal.

The key issue in this article is about the lacking of separation of concerns in Slack. I may be missing something, but it seems to be diametrically opposed to Slack's "always-on" structure. I would argue that Basecamp tends to devalue workplace communication through impersonal Basecamp-templated emails which often hide the original sender and thus any sense of urgency that would otherwise be generated. We have so many fantastic tools, but often email seems to be the unsung, yet essential, hopper for all of our notifications. For workplace communication and general project discussion, just email (under the right direction and guidelines - along with supplemental direct chat) strikes the perfect balance between urgency (or lack thereof), the ability to compartmentalize, and personal touch, without interfering directly with work by breaking concentration.

The new version of Basecamp is pretty smart about notifications. If you have the site open, it doesn't send you a ton of email. It also has something to disable notifications during certain times of the day and catch you up later (probably in one longer email.)

Sadly, some people need those emails to keep using the tool everyone else is using directly. I wish it wasn't like that.

Chat is toxic to productivity. Teams need to get questions answered 'eventually' (exactly when depends on the team) without interrupting each other.

Except sometimes you're blocked on something and need to know the answer now to finish a task. If you switch to something else while waiting for a 2 minute answer, you end up wasting a lot of your time.

Interruptions are sometimes time-savers for the interruptor but they're costly to the interuptee.

Some problems are important and merit an interruption, yes. But if you build a culture around instant communication, your worst people will drag down your best people.

The default should be digest mode (and god help me because my 50 year-old desk-neighbor said that to me 2 years ago and at the time I thought 'man this is an old human being').

It bothers me that "you can freely interrupt employees" is actually an implicit part of how Slack is marketed towards management. (https://news.ycombinator.com/item?id=11197449)

You have to think of slack channels as coworking place and meeting rooms.

You need to live mainly in one channel (the equivalent of the physical open office), and go to the other channels when called in, or when you have a bit of down time to check what's going on there. Like the buildings where we used to work, you do not need to visit every room.

I guess the hard part is the self policing the author mentioned.

At my employer we are having the same situation. Some ppl are at the point they check Slack 3 times a day, come in, lunch, before end of day.

I am guessing you are not in a distributed (remote staff) company?

Self policing doesn't help if other people are making decisions in Slack when you're not online.

I really do not get this hype around Slack.

Chat, group chat, video conferencing are nothing special. These applications are commodities and included with so many other apps. Eg. if you use Google Apps/Mail you get the fantastic Hangout for free, working on all devices.

Moreover, every time I login Slack it feels so crowded. If you want to change something you have to navigate through a forest of settings here and there.

Finally, chatting and being messaged is the best thing to get out of flow and to get ADD. Messaging is great, group messaging too but use it rather for important stuff.

Slack is IRC with history. That's it. If IRC had history built in, Slack would never exist.

The lack of threading is what really kills the usefulness of Slack. This is why we settled on Flowdock in our company.

If you don't have threading, you lose the one best feature of those new chat solutions, the single advantage they have over decades-old IRC: conversations at least slightly detached from time. On Slack, you have to be there all the time in order not to miss things or to participate in just about any conversation. If you aren't, soon it will be too late and no one will know what you're replying to.

As for other advantages, I noticed that one of the biggest uses is file exchange. If there was another simple way to just drag&drop a file somewhere and have people access it, those chat apps would see less use. But there isn't.

I haven't seen the bad effects in our company. Perhaps they occur at larger company sizes.

Am I the only one who regrest the demise of nntp and good news readers? Threading was great, and I found it very efficient to get through a lot of stuff.

With the switch to html based forums, my personal efficiency plummeted. But I went where the good conversations were.

Strikes me that the reported issues with Slack are just the next generation...

I can imagine this same article being written many years ago when email first became ubiquitous in the workplace.

I worked at a large company where seemingly every day we would get several "someone has left the lights on in their blue Honda" type emails sent to everyone in the company.

Thankfully now I work in a small one without a carpark.

I appreciate the idea of resolving a communication issue by removing a parking structure and, if that doesn't work, removing the rest of the company.

I agree with many of the problems, but quite a few are actually advantages! The biggest misconception I see here is that you try to change other's behaviour instead of your own.

E.g. if there are decisions made without you, let them. Offline there are also many conversations and decisions you are not a part of just because you were so unlucky that you haven't been there at the time. But in an offline or private-chat conversation you can't look up afterwards what each person said exactly, you have to rely on hear-say. So in fact if you accept that decisions are made without your participation (it's called "trust in your team") then using a good chat tool is an advantage.

E.g. 2: People don't use your QnA software or wiki and instead use chat. Maybe instead of convincing them to use the other tools you can learn and teach others how to use the search function of the chat efficiently. You may find that you don't need a QnA software when all the questions and answers are searchable in the chat software. Here you can safe the cost (money, admin, learning time for new guys) of one software.

E.g.3: You want tickets and tickets are really important to link activity like commits. I'm not sure but I would assume that it's possible to find a chatbot which creates tickets for you from your chattool, writes comments to them and gives you back the ticket-id to use it in your commits. Then you also have a kind of log for how a discussion and the creation of a ticket where interlinked with each other, because you see the 'hubot create ticket "debug problem"' in the middle of a conversation happening. More context for free.

To change others the first thing we need to do is change us, and that is admittedly even harder.

> And the notifications are to die for. They are simply amazing and fun to receive.

This is where the article lost me. How are Slack notifications different from those in other services? I'm just not getting it.

To me, this is an example of somebody wanting to love something.

In my experience comparing Slack vs HipChat (limited experience, but still), Slack's notifications were more reliable. As in, Slack was smarter about figuring out when I'd locked my laptop, or the screensaver had activated, and then it would re-route notifications to my phone. It does this pretty flawlessly, compared to HipChat that would mess it up sometimes (and so we were never quite sure whether to trust it).

OK, that clears things up a bit. I don't use Slack on mobile, only the desktop app on Mac.

It sounds like a signal to noise ratio problem. The problem is that there wasn't a sound way to filter noise (multiple channels failed) so they were forced to deal with all the noise to make sure they didn't miss anything relevant.

The constant policing they mention at the end was probably enough overhead for them to consider alternatives, though I don't understand what they mean with this quote: "Furthermore, Slack was not designed for the deep, meaningful conversations that are needed to move 1Password forward."

On the surface, it sounds like a people/culture problem, but I'm sure there were other factors at AgileBits that contributed.

I think the key takeaway is this:

And even if we had been successful in changing people’s behaviour, the lack of threading made it very difficult to have meaningful, deep conversations about complex subjects anyway. Before you could even fully understand the problem being discussed (let alone find a solution), someone would invariably start a new conversation or reply to a previous discussion that happened earlier in the channel.

Threaded, asynchronous discussions with notifications when someone actually replied to your message are much more useful.

And they can also be freaking decentralized and end-to-end encrypted! Woot!

I am building something like this. Anything like that exist?

Wasn't that Google Wave?

How so?

What you're describing is called email. Seriously - it is exactly this, right?

I've always wondered about the viability of an email client that behaves like a chat client. Instant send with the enter key, messages in bubbles, etc. You get all the fun of IM without additional infrastructure or services, and in a standard way too. No walled gardens of different apps.

Could be a pretty cool UI solution to have a chat client that uses PGP encrypted e-mail in the background, but Gmail SMTP has a send limit of 100 e-mails per day. You would run into that rather quickly with a chat UI.

I guess the chat client could do all the e-mail sending from some of their maintainer e-mail servers and not from under the chat participant e-mail. Then we would start losing comaptibility with other e-mail clients though. Although not completely, as we could set Reply-To headers and when another e-mail client replies to user1234@chat-client.com, we could just forward it to the correct e-mail.

An interesting concept indeed.

Kind of. Imagine more like Google Groups or HN but with notifications when someone replied.

I guess if you use mailing lists for topics you can subscribe to, and cc'ing people for @mentions inviting them to reply, then yeah! Email can do it all. So why is email considered such a time sink? Because people don't filter conversations coming from the outside. But if they just set up a filter, then literally email is a Slack killer, no?

Slack plans on introducing threads this year, according to their marketing folks.

Our private xmpp server logs everything into static HTML pages. This is useful for compliance with legal things, but also for turning q&a sessions into wiki documents -- cut, paste, a little editing and you're done.

It's also, you know, private.

Wow really surprised to hear they broke up with Slack. It seemed like a very good long explanation of the problem, basically no mention of any attempt to fix the problem, and then dropping the tool. We are deep into Slack and still liking it, but seeing some strain. This really rings true: "some of the most positive and uplifting individuals I know come off as curt and stressed and pissed off in Slack conversations."

tht makes no sense, every1 i kno is rlly good at xpressing their emotions in txt

For real though, it's amazing what core parts of human interaction people will try to replace with an app. People need to understand what they're really giving up with face-to-face or verbal communication.. thousands of years of highly developed body language, tone, etc.

We are 100% remote company so face-to-face is not an option. However we do use video (gotomeeting). And I've been using and enjoying Slack's new "/call" feature. I'm eager to see how they implement video and screen sharing.

It depends a lot on the person for me. Some people are very good at conveying (and understanding) nuanced emotion in text, especially if they're people you've conversed with a lot in text already. Others are better in person, in videochat, or even on the phone (though some, like me, are particularly bad at phone). A few people I know are significantly better to converse with in text chat than in person, because they're much more fluent, confident, and open in text, and comparatively not as good at expressing themselves in face-to-face chats, stumbling over words and being more stressed and self-conscious.

In personal life, I find the people I'm closest to are people I talk to quite a bit through both modalities. We have different types of conversation in text chat compared to irl chat, which end up being complementary in my opinion.

I think the solution is a mix. Slack + some video solution seems like it could work. The tools are there and it looks like Slack is quickly building a video tool. Right now, small teams can get by well with Slack and Hangouts.

I think for a team work effectively you need differentt tools - Slack for instant communication, Basecamp for tracking project status, Trello for organising work flow and etc. It is impossible to have a tool that fits all your needs.

I was previously working in a company that used Flowdock[0]. Current place uses Slack and I've noticed that there are multiple things bothering me.

Biggest complain for me is that the Slack UI gives too much weight on the fact that someone has talked on a channel. This makes me feel like I should be reading that, even though it might not have anything to do with me. This creates a whack-a-mole situation where I end up constantly jumping between all channels so that I wont miss anything.

Another thing that I really liked on Flowdock was that discussions had separate threads. Especially on channels that weren't your main focus but instead you were invited to in order to discuss some specific thing you could follow just the discussion about that thing and everything else can be filtered away. This also makes it easy to know what any comment is about, since you can easily read the whole discussion thread without having to skim through the whole channel. This works great even if the messages have days or weeks between them. (Instead of having just the direct mention as a point of interest you end up following the thread that you were mentioned on and you might keep following it for longer time, even after the highlight is weeks old)

There was a major annoyance with Flowdock as well. At least when I was using it there wasn't a search that covered all channels. You had to either know what channel the thing you were searching on had happened or you had to one by one go through all channels and do a search on each one of them separately.

Main point here is that Slack fails to keep my attention on the things that are relevant to me and instead seems to suggest that everything is critical to me. This makes it feel like addiction instead of a tool that would be useful all the time.

[0] https://www.flowdock.com/

I also like that Flowdock splits into two panes, with one pane for notifications about things like Pivotal Tracker, Github commits, etc. It was a better way to separate noisy but occasionally useful notifications from the more important conversations than having separate channels. I wish Slack would implement something like this (separate pane for "Bot" users).

> For many months myself and a few others have been trying to make Slack work for us. We would be the bad cops and point out people’s bad behaviour and suggest alternatives.

> When someone would report an issue in Slack, we’d point out the appropriate JIRA or GitHub project where that should be reported.

This got me thinking: Part of the problem is that the attention of others is a commons -- a vast wealth that we each have an interest in extracting from, but which takes a toll collectively.

Perhaps there's a way to internalize for a "consumer of attention" their attention-cost externality. So if certain people are extracting too much from the commons in the form of "@person" and "@everyone/@channel" messages, perhaps a bot could randomly ping them with noise messages in proportion to their attention-grabbing actions, to make them feel some of that pain and adjust accordingly without policing :)

I'm wondering if Slack will ever implement something like Sococo or teamspeak's always-on voice chat. If you have not seen these it's quite a weird idea. If you are in the channel your speakers are always-on. Someone can speak to you without dialing and without you answering. They can simply say "Hey Fred..." and start talking.

I have not worked with these, but did try Sococo briefly. The way this would work in slack is you could opt-in to voice on a certain channel for collaboration intensive work. Might be a horrible idea I'm not sure.

I guess you could use /call this way? Hmmm... didn't think of that.

I've used TeamSpeak for that at an old job. We used it for pairing and team meetings. We couldn't all fit in the office at the same time (10 people, 100 square feet w/desks wasn't happening), so we had team meetings over TS. Was great. Would definitely do it again.

What prevented multiple people starting to talk at the same time during team meetings?

Discord is a bit like Slack but focused on voice chat for the gaming community. It has voice rooms that work as you describe. https://discordapp.com/

> a bit like Slack

The UX and general usage is so similar (in my eyes), I actually assumed it was a spinoff from the same company for a good while.

If you have not seen these it's quite a weird idea. If you are in the channel your speakers are always-on.

Like every voice-chat enabled computer game since the 90s; IRC style open channels, but audio.

Mumble is one free, encrypted (I think), cross platform one.

My last 2 companies used slack. I thought it was amazing. After being at a company that doesn't use slack, I realized how terrible it was for productivity and also gossip.

I love electronic communication and Slack in particular. For a distributed team, it's an absolute must that every important chat happen on Slack. Stuff spoken in person is imprecise, secretive and easily forgotten. Slack is clear, persistent, and public. Everyone is on the same page. I too feel the need to read every conversation, but compare that to having those conversations just happening without my knowledge.

The solution to this guy's problems are to chill out.

>Stuff spoken in person is imprecise, secretive and easily forgotten. Slack is clear, persistent, and public.

I don't get how verbal stuff is imprecise but slack is clear. I find it to be the opposite. It's much better to have a face-to-face chat or a voice chat than converse in writing. It's more clear and you can get more feedback from the other person. Also, if you need to be more precise, you can just write stuff on a board/notepad/chat while talking.

When you talk to people, they're more likely to support their assertions by citing sources with precision than when they write? Really? When I talk to people, I get a lot of "I read somewhere that X is true" and "I heard from someone that Y is true". And when I request sources, they say they'll get back to me, but they rarely do.

Anything that is is written down tends to have less hand-waviness and bullshit than the random spew that comes out of people's mouths when they are making up their ideas as they go along.

I mean literally more clear as in not mumbling. Also, your focus can wax and wane in a meeting while text is like having built-in rewind and playback.

I'm confused, I never used basecamp. Are slack and basecamp direct competitors? Isn't basecamp primarily a project management software like Jira/Redmine?!

Basecamp includes chat, plus message boards for conversations on a specific topic and pings for 1 on 1 private communications.

"Slack as the new email" is spot on. And the article identifies it too.

The problem isn't the tool. The problem is people. Giving people more and better ways to communicate creates more noise, not necessarily more signal.

Constraining communication to channels that only allow signal feels bureaucratic (complete form 31/b to request new business cards and send to purchasing no later than the second week of the month).

There's a happy medium (pun intended) somewhere between the two.

Slack is the new telephone but it's treated like email. Conversations are ephemeral, synchronous and the worst of all they can easily interrupt you.

Good point.

Slack is planning to release threaded conversations later this year [1], so maybe this will answer some of the criticism on this post.

[1] http://www.theverge.com/2016/4/13/11418594/slack-threaded-me...

Email communication, slow, initiator feels ignored.

Slack/chat communication, instant, receiver feels overwhelmed.

The problem is not email or slack, it's the method in which we communicate. We need to make sure we use the right tools, as the author mentioned, knowledge bases, email, chat etc at the appropriate times.

The problem is not Slack per say, it's using Slack for all communications.

Yep, a lot of these issues the OP reports can be resolved by, as a team, discussing how you communicate and what is a priority. That team seems to be lacking clear expectations. Oddly enough, that is a failure to communicate.

If someone does an @here or @channel or even an @person notify for a simple question that is not urgent, that is rude. Non-urgent issues should go in the channels and the person can respond when they get time, or e-mail it to indicate it's not a priority.

I really like Slack, but I do agree that it's easy to get carried away with notifications and integrations and it becomes a lot of noise. But most of these issues can be resolved by talking as a team about how the tools should be used.

Interesting read, will have to see how it turned out (in case you guys move back to Slack :D). Although, I'm not sure changing tools is the right answer, it sounds like you guys had everything you wanted and more. Why not modify Slack to your liking and not change tools entirely, this eliminates the need to learn a whole new set of tools to do the same work.

I think the point is to completely go cold turkey with the tool they know is good and tackle the problem with something they are unfamiliar with, disrupting existing habits. It sounds like they reached the point where modifying Slack (or more importantly, their communication habits) would just result in sliding back to the old ways.

one day in our office slack was down from like 11:50am to 1:10 pm and it was perfect. It was like a big sign lit up in the office that said "TALK TO PEOPLE". Everyone took a much needed slack break and got lunch. Maybe the admin of a slack network should be able to enable that timeframe to be off everyday.

Slack admin can set a team wide do not disturb period. Users can override if they wish.

We use jabber in my office, and it's definitely higher friction than slack; this made me think of it as at least slightly a positive for the first time. We also have a wiki, and a searchable database for topical mailing lists, and those get used a lot.

If someone has to send me an IM to get an answer to something about our product, and I can't link the answer to them by just searching our wiki (or documentation if it's user-visible), then I file a note to add it.

I haven't ever felt the need to berate someone for asking me about easy to find information, because someone who isn't at least slightly embarrassed to have their question answered by a link to a resource they could have found on their own in under 30 seconds is probably going to have enough problems in other areas.

Why has SMTP evolved in all those years?

Email could handle much more automation, and be friendlier to on-demand inclusion in discussion threads, but AFAIK, it doesn't support a standard way to provide:

1. End-user controlled behaviour.

2. Whole-thread forwarding initiated by the end-user.

#1 would require a way to allow stantard plugins to be written, either by sysadmin or end-users. (Obviously, the capability and authorization of each would be different. End-user ones would only be allowed to touch end-user own emails.)

#2 would allow easier evolution of email threads.

I'm not talking about proprietary extensions to a particular SMTP implementation. I'm talking a standardized protocol addition to support these scenarios.

Am I missing something? Were changes to SMTP ever attempted?

You can forward a whole thread. That's client-side behavior. The simple way is to select the thread, encapsulate it as an attachment of type RFC822/email, and send it off.

The complicated but more user-friendly way is to reconstruct the messages into a single non-repeating conversation view and send that.

In either case, SMTP doesn't need to change, and you don't even need support on the receiving client, just the sender.

> Why hasn't SMTP evolved in all those years?

Real answer: A duopoly in the email space give two-three companies too much power over SMTP and email in general (and they have no interest in changing it, IE 6 style).

These companies? Microsoft (Exchange, Hotmail/Outlook.com), Google (Gmail, Google Apps, Google Apps for Education), and Yahoo! (Yahoo! Mail).

If these "big three" don't want to support something then it doesn't exist. If they do want to support something then you're adding it to your SMTP/mail server stack regardless of how much you wish to.

Now, I know what you're going to say "what about Sendmail, Postfix, and other SMTP daemons?" But these open source email daemons are very beholden to what the "big three" do. If your SMTP daemon doesn't work with their servers then it is effectively broken and nobody will run it.

The reality is that the SOURCE of almost all non-automated email on the internet comes from these big three (Exchange shouldn't be under-estimated in this context).

So that's why, we're in an IE 6 situation all over again, but this time Google and Yahoo! are also playing gatekeeper in addition to Microsoft.

This is incredibly timely for me. We have grown from a team of 2 to a team of 18 in the past year, we're all remote and we literally huddle around Slack and warm ourselves to it's glow from morning till night. It's the core of our company culture and our comms.

I think Dave (the author and founder of 1password) is feeling the same thing I'm feeling as a CEO. It's a kind of weird anxiety that creeps up on you as the company scales and you feel like you're always-on from the moment you open your eyes to the moment you close them at night. I think it's a symptom of a virtual office and team. A real office on the other hand would provide that very real sense of driving home in the evening that gives you a very solid separation from work, the team, the opportunities and the issues.

To be clear: I'll never go back to a physical office, both for my own benefit and that of my team's.

I became aware of this problem with being always-on recently. I also started giving rather short unvarnished answers to questions on Slack and I realized something had changed. I've put it down to having no sense of quiet time. I don't mean not having any 'quiet time' but having no 'sense of quiet time' because someone might have messaged me. So even if I set myself to away, I'm still checking in just in case I dropped the ball because someone is waiting for a reply.

I've changed two things so far to try and fix this:

- Taking long walks (in addition to my regular bike rides) with Slack off. - I still code, so I turn Slack off and set my alarm for 1.5 hours from now or whenever I need to be back on. Then turn Slack off.

Things I'm considering:

- Banning Slack after a certain time at night (for me personally). Perhaps 8pm. - Banning Slack for myself until I'm "on" in the mornings.

Being a remote team I see Slack as absolutely essential and I don't think we could do without it. We are very productive via slack and we share music, jokes, news, ideas for blog posts and many other things via Slack. We also do our voice calls via Slack and we don't use video on purpose because it's distracting. So for us, Slack won't go away any time soon. I think if you can manage it, it's an amazing team platform.

On a broader note: I think digital addiction is a real problem. I think it's subtle and it involves checking the same thing more than 20 times a day in a non-productive obsessive way. Think Facebook, Reddit, Hacker News, hitting refresh on a SaaS thing that gives you a quick endorphin or adrenaline rush and of course Slack. I think the symptoms are subtle, the behavior is widely accepted as normal and it's destructive in several ways.

So I think it's important to develop a discipline that allows us to exist online safely, productively and in good health. I think what this discipline is is just beginning to emerge in our culture because the problem of digital addiction and being always-on is only beginning to be recognized.

~mark.

Digital addiction, especially with communications tools, has been a very real problem since the 1990s at least (with regard to Internets) and has become prevalent with the rise of social networks.

I've built and run several companies since the 1980s and always tried from the start to instil a culture of respect for other people's focus, which ranges from (as CEO) not 'looming' at their office door/desk expecting them to interrupt their focus to not 'telling' (asking) them to do something over a real-time communications channel (since the power differential will often cause them to interrupt something more important).

That means people don't interrupt or distract others without first asking politely via a non-realtime method (e.g. email) unless there's a genuine emergency (servers are down!).

Additionally, people should not feel obligated to stop what they're focused on to help someone else unless that is part of their role.

On the other hand if they're running out of steam, and need a distraction to get their thoughts back in gear, then catching up on help requests or doing something 'social' is OK, including getting outside for some fresh air.

With the increasing ubiquity of communications tools a key management activity is helping people to not feel obligated to be tied to them.

For example, with IRC and other real-time chat channels where there's a growing expectation that people are logged in all the time: don't! When you're done, log-out. Don't feel the need to have to 'scroll-back' to review history since you were last there. Treat it like entering and leaving a physical building - if you're not there, you will miss what is said.

From that comes the well-practised requirement in the non-tech business world that important discussions and especially decisions should be documented (some business sectors require this anyhow) and formalised (via arranging meetings with all stakeholders).

Don't assume people who don't respond immediately will ever see what you typed. If it is important to document it in a non realtime way; email, issue tracker, wiki, or whatever suits.

And as CEO ensure your people are NOT logging-in/commenting out-of-hours unless that is part of their job. Ensure they maintain a positive life/work balance in favour of their life, even if you have to send them home (as I've done many times with programmers that 'just need to finish this bit' and who you know will likely be there 3 hours later if you leave them).

Posting an update on this for anyone else in a growing org using Slack: Our team chatted today and decided to keep using Slack because it's awesome for remote teams and our needs. It works well for us. What we are doing now though is to us the 'Snooze' function which lets you set it on a timer. Then when someone msgs you they are told that you're in snooze mode and given the option to 'break through' the snooze and alert you anyway. We've agreed we'll only do that if it's urgent.

I think this will work well and probably scale well too.

Completely agree with @mmaunder comment on setting time for checking slack and not using it other times. No matter what tool be it outlook or blackberry, you need to set timing for the communication and collaboration. For the people who have collaboration/communication as not a primary job like developers/designer/engineer etc..

Also it is completely unacceptable to call this checking a tool beyond your shift/work a culture and it is indeed a bad practice setup by lead/ceo to keep everyone working all the time. The companies pay you for your time, so unless u get paid extra allowance to check these tools after hours please do not do it. For emergencies situation let people SMS and if no response in 15 minutes then call and that too have roaster who will be on call in which week or month.

It is a job of the leader/manager to ensure people have work life balance and they should setup internal polices and procedure to ensure people don't get to appreciate the one who is always on rather the ones who contribute with in the work hours. The management should make a culture of people talking about it so that it does not become forceful as people start doing this always on and others fear that they would be considered contributing less if they don't be online hence everyone stays on line for no reason.

For a company like 1Password there is absolutely no reason to be online all the time except for the support folks(and they too with in thier shift and have enough people to cover 24/7) and dev's can be engaged on call as required. All they need is setup couple of core hours every body is online to communicate and status update. Even geo diverse teams you can have core hours that ensure everyone is online for about 1 hour or 2 at the same for each team , if it is absolutely necessary.

I wish startup ceo's understand this and account that 8 hours a day is what person can reasonably put in work and if you need more hours it is going to cost business and that is part of the budgeting process. If you can't afford that then you are not yet ready to start the startup or do it it yourself. For god sake it is 21st century and if you are going to change the world first change your mindset and change the your company and make it a first class and make it 22nd century company where employees are not exploited because they can be(in the name passion, happiness, blah blah blah).

I still try to understand what Slack is that IRC isn't. At the moment I'm in the "someone managed to make money out of copying IRC"-phase including copying all the problems/pain points of IRC according to this article and comments here so far (highlighting, channel inflation, multiple conversations in one channel at the same time overlap ..) - what do I miss?

I don't use Slack, but perhaps people prefer its UX?

IRC is a protocol, it has nothing to do with UX... You can tack IRC on top of a pretty client and you can get pretty similar results I'd assume.

DISCLAIMER: I never used Slack.

UX != UI

Simple example: with Slack (or another hosted, web-based chat app), I can invite the non-technical head of sales to join it via e-mail, and they can. They literally cannot install an IRC client.

I can get similar results, but "I" isn't enough for a communication tool to be useful.

Why can't you do it through the web interface of a company-backed IRC network? There's literally no difference there, IRC is just a protocol, you can still wrap around your own local stack with registration, email notification, fancy UI (I know UI != UX) and auto-invite system or whatnot.

I just don't get it...

"you can still wrap around your own local stack with registration, email notification, fancy UI (I know UI != UX) and auto-invite system or whatnot"

Or pay someone to do that and maintain it for you.

Accessibility for non-technical users, and formatting.

In MatterMost (a very nice self-hosted Slack alternative) the integrated MarkDown-support means that sharing code and more extensive reports can be done with a helpful amount of formatting. I much rather read the ten lines of code a colleague is asking me about with code highlighting than without, and a summary of a colleague's visit to a customer reads a lot more pleasant with headings than without.

Also, emoji. Not something most of us on HN would miss, but a lot of the non-technical users seem to appreciate being able to nuance messages with them.

This article was much more focused than the "Slack, I'm breaking up with you" artucke posted to HN a few weeks ago: https://medium.com/better-people/slack-i-m-breaking-up-with-...

I've seen teams rely only on Slack for communication, including technical discussions.

I don't get it, and I'm concerned about the following:

1. proprietary service with no interoperability and high potential for loss of records

2. important technical details/arguments hidden in a chat log and not made part of a ticket/commit/comment

3. removal of async communication leading to more interruptions and less async emails one has thought about before responding

4. teams boasting the use of 10 or more channels

There are other issues with relying solely on Slack and killing off email, but these are the most important ones that always come up when I'm confronted with a Slack-only team.

I've had the same issue with IRC, so it's not my kind of communication medium to monitor 24/7, whereas I love bulk responding to emails and often ponder about a response for a while.

If there's something urgent, one picks up the phone, and usually one thinks twice before calling (interrupting) someone.

Using proper email threads, ticket discussions, etc. give you an electronic trail of the technical decision, and that's also why Fossil's inclusion of a distributed ticket system is such a great idea. Two years later, you can easily inspect how the code evolved and why it did in a certain way.

How do dev teams cope with Slack? I couldn't work without async email and use real time communications (text or voice) only on demand, in order to limit interruptions.

Why not IRC, Jitsi, Jira and a wiki.

IRC for chitchat / asking questions (PMs and highlights so there's no immediate need to respond)

Jitsi / IRC for meetings or small team collaboration.

Jira for bugs

Wiki for documenting design decisions and future work

IRC for chitchat and a issue tracker are great. I agree.

I prefer Etherpad for meetings, especially for virtual meetings. It includes a simple chat, but I never used that. http://beza1e1.tuxen.de/articles/meeting.html

A wiki is ok for meetings minutes, but I prefer documents now. Wikis always seem to deteriorate to the point of uselessness.

Why can't you just search your Slack for answers to old questions? Isn't that supposed to be part of the point? I've heard that's one of the main selling points.

Makes me think that something like Discourse should be used for all non-ephemeral communication.

Have the same thought as well.

Imagine all of these comments in a flat, linear wall of text. Threads++

Slack != commenting system.

tldr: a better hammer is a better hammer, not a replacement for your whole tool chest.

My understanding: free CI runners for everybody, 10 USD promo code to new users. Considering that DigitalOcean has always been giving away 10 USD coupons to non-users, the promo code is quite irrelevant. But the free CI runners are great!

Wrong article.

Woops. I thought I was on the DigitalOcean / GitLab one. Sorry.

Reply on news.ycombinator.com