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.
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.
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.
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.
"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.
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.
> 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.
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).
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.
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.
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.
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.
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.
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.
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
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!).
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.
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').
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.
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?
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.
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.
> 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.
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.
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.
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.
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.
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".
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.
> 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.
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.
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.
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.)
> "/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.
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.
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'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.
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?
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).
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!
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.
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.
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 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.
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."
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.
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...
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.
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.
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
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.
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.
186 comments
[ 3.1 ms ] story [ 160 ms ] threadI 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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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...
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.
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').
> 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?
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.
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.
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.
Really dude? Why you don't check your tolerance threshold?
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.
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.
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.
[0] shameless
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.
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 user1234@chat-client.com, 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?
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.
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.
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).
I think this will work well and probably scale well too.
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.
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.
Better copy/paste (like most IM apps) would also make it easier to copy/paste some discussion into your bug tracker of choice.
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.
[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.
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.
https://www.androidpit.com/how-to-download-apk-file-from-goo...
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.
- 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.
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.
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.
Kyle