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.
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.
So I flattened it back down to chronological order and it feels like that restored a lot of sanity.
 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.
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 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 :) )
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.
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.
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.
Better copy/paste (like most IM apps) would also make it easier to copy/paste some discussion into your bug tracker of choice.
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.
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.
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.
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...)
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. ¯\_(ツ)_/¯
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.
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. :-)
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.".
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.
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.
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.
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.
... 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.
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.
But maybe slack should position itself as an advanced alert management tool (which is what many seem to use it for).
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.
That's interesting. And still leads to the question "why slack, not IRC"?
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.
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.
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).
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.
- 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.
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 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.
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.
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.
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.
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.
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).
Are you going to know that the problem you are encountering with your bluetooth connection was solved in freenode's #pulseaudio 3 years ago?
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.
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.
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...
> 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.
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?
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.
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.
Really dude? Why you don't check your tolerance threshold?
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.
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.
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.
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.
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?
"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.
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.
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.
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.
Sadly, some people need those emails to keep using the tool everyone else is using directly. I wish it wasn't like that.
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').
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.
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.
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.
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.
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 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.
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.
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.
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.
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?
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 firstname.lastname@example.org, we could just forward it to the correct e-mail.
An interesting concept indeed.
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?
It's also, you know, private.
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.
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.
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.
> 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 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.
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.
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.
The solution to this guy's problems are to chill out.
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.
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/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.
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.
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.
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?
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.
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.
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.
I think this will work well and probably scale well too.
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).
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).
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.
DISCLAIMER: I never used Slack.
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.
I just don't get it...
Or pay someone to do that and maintain it for you.
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.
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
I prefer Etherpad for meetings, especially for virtual meetings. It includes a simple chat, but I never used that.
A wiki is ok for meetings minutes, but I prefer documents now. Wikis always seem to deteriorate to the point of uselessness.