Unslacking Tideways Company
beberlei.de
beberlei.de
After leaving slack entirely from a robotics team and a science club, our productively increased.
No longer were we going off topic wasting precious time and making everyone in the channel read every 500+ messages some people engaged in. We instead chose to make more plans during meetings and through direct chat (Messenger).
However, Slack is usefull for forums such as donkeycar.slack.com where many hobbists come in and have questions on this software/hardware project. Slack is easily accessible for anyone to ask questions and with proper use, I was pretty productive in communicating effectively across channels.
Despite this, I believe that slack in general is a waste of time in a TEAM. Why not have meetings or meet up in real life rather than hiding behind a screen without any physical interaction? Slack, however, is a great alternative for forums since there is great searching capabilities within channels and there's always someone there to help.
I'm rather baffled by the use of chat for this kind of problem. (and I never clicked with IRC either)
So - I've got a problem and I come to a chat channel. It's probably been asked before. If I'm lucky I'll find my answer in a searchable chat archive and I won't need to visit at all. Otherwise I face two options:
1. Scroll back and try and find any previous mentions. Nearly impossible in my experience.
2. Ask my question and hope that people aren't sick of hearing it. If I'm lucky enough that a) someone is present who knows the answer and b) they respond in a timely manner then I still face the problem that - assuming it's busy enough for a and b to be likely - then my conversation is interspersed with several unrelated discussions. Also - the person helping me is likely to go quiet for long periods or disappear altogether because most probably they are doing other stuff.
Note that the final flaw (the interleaving of discussions) is a problem in all cases.
Now - can someone explain to me how this is better than a forum or Stack Overflow style site?
But I especially find that IRC is better for very niche questions that won't benefit anyone else (and won't have been asked before) that also requires some back-and-forth debug style to get to the bottom of it.
Similar to problems where email doesn't work and you need make a call instead. A ten minute call can sometimes save you a week of emails if they are not quick enough to answer (common with large timezone differences).
Also much quicker, you either get the answer or you don't, either way both are good to know (so that you know to try something else).
2. Conversely, they also mean that maybe you'll help someone else out while you're waiting.
3. It's easier to diagnose a problem in an informal back-and-forth than in the writing-for-posterity style that SO and fora encourage.
What would be great is some sort of IRC or Slack for HN where I could ask if someone recalls the article I'm thinking about, as well as general chit-chat for the community. I searched for this as well, and I think someone had tried to start up an IRC channel or even a slack, but it wasn't well populated.
Maybe there's a Discord I'm not aware of?
However, forums suffer from two crippling problems: 1. It's really hard to find active forums (discoverability), and 2. Forums are often overwhelmed with spam and security problems (integrity).
If those two problems could be solved, or at least mitigated better, then forums might make a comeback.
Well, that's pretty hard to do if you're working remotely!
Meetings are also bad productivity killer and if you are co-located in an office you must be careful not to summon ad-hoc meetings that interrupt one participant from their deep work.
In the book "Facebook Effect" by David Kirkpatrick[1], one programmer described how Mark Zuckerberg and the other programmers extensively chatted on AOL AIM even though they all sat at the same table elbow-to-elbow.
When one of the new programmers responded to one of MZ's chat texts by just looking up and vocalizing an answer, MZ didn't look away from his laptop to respond. Basically, the new programmer unintentionally broke the silence etiquette. The early Facebook team was using chat as virtual hallway conversations.
It seems the "correct" way to use realtime chat depends on differing personalities?
[1] there was more than one chat story in the book and this was one of them (but don't know for sure if Google Books link will show you the page excerpt): https://books.google.com/books?id=PxTvbM-VCPEC&pg=PA137&lpg=...
Libraries are the ultimate open offices after all. Tons of work used to and still gets done in libraries, and they're pretty much all open tables.
IMO, Slack can be pretty great for remote teams, although I agree you can definitely abuse it too hard and end up wasting time. One benefit of using text chat to have a discussion is that it you can easily scan through it and reference any section. There's also certain kinds of discussions which I think are easier to have through text, especially when you want to provide references and examples. It also makes it easier for introverts and non-fluent speakers to participate. On the other hand, physical discussions are hard to beat when you're whiteboarding or drawing diagrams, especially if you're still exploring the problem domain. You don't have to limit yourself to any single discussion format.
I'd say it's a 50/50 on work related and just screwing around.
And sidenote I am not sure where term "ping you" came from, but it needs to go away. It honestly conveys the message I don't need to or want to talk to the person that said it.
I assume it's like using sports euphemisms in the office to convey a concept... this is likely a military euphemism (from radar/sonar). On one hand I don't mind it because it removes the specifics about how the person will contact you, it just simply states that they will contact you (and the method may vary depending on the time of day/week). Sure, there are other ways to say that, just as there are other ways to say something is "on deck" or you're "punting" a decision.
Honestly, I hardly acknowledge those ping requests anymore. I'm sure there is a packet loss pun, but it's late and I'm tired.
It's weird, isn't it. We all have our triggers, I suppose.
For example, I assume anyone who explicitly qualifies only a small number of their comments with 'tbh' or 'Honestly...' is lying to me the rest of the time.
But slack was also super easy to use wrongly and drain so much time into. It really helped to declare slack a lossy source of comms. You shall not expect people to read it and you shall not use it as a data store. Important things go into email, wiki, tickets.
On a fully remote team, slack is so important, but all the same rules need to apply.
It drives me crazy when people send mass company emails with, for example, new policy or forms attached, and don't post them elsewhere. New hires only see them if someone remembers they exist and forwards them, plus it's impossible to figure out current state without spending a bunch of time playing email archeologist.
The email is sent as a notification that the content has been added, updated or moved.
Email should ideally serve as a notification system and a lossy communication system where things you want to retain need to be backed up somewhere else.
The nice thing wth email is that being an open eco system there are a lot of integrations that are supported easily.
We've been remote founders and employees in numerous distributed startups, and have always found the same issue, the noisy nature of chat/Slack and lossy nature of email necessitates a 3rd place to keep the important decisions, announcements and history of the company.
Lots of companies use wikis and forum software for this, and those can work, but we're betting that a dedicated solution can work better.
Some kind of tool is necessary for sure, but different tools set a different focus to provide a solution for organization teams and companies.
I guess everyone should find what works best for them.
We use an internal forum in addition to chat. Anything substantive goes in the forum. We'll regularly reference 5 year old posts.
I'm convinced that tight integration between source control, issue trackers, wiki pages, and forums is a good thing. Generally you can use URLs, but that's often cumbersome.
I'm curious why people don't like forums for discussions.
Proper threading.
Read/Unread tracking.
Keyboard UI. (And the mouse UI tends to be bad as well.)
Responsiveness. (Especially: page loads which are not instantaneous.)
Killfiles.
They generally have mediocre search functions unless they are entirely visible to Google.
These are off the top of my head.
http://home.httrack.net/~nocem/
Thunderbird does this by default. Reddit breaks threading when sorting by "new". On HN, you have to search the comments page "minutes ago" or "hours ago" to find new comments in an existing thread.
Instead, we went for XenForo, made by the original vB developers. It's got just enough modern technology to make it a bit more pleasant, and it's super fast (faster than vB 3). Migrating vB to that was easy enough too (took a while, but faster than Discourse which needed three days for the basic import and then still had a million tasks to run in the background)
We really wanted to to like Dicourse, but everyone on my team found some little thing that really annoyed them ("why does it hijack ctrl-f?", etc.). It was death by a thousand cuts. XenForo is the most modern of the traditional forum platforms that I reviewed. Everyone just gets it.
It used to have a halfway decent forum addon, and the ability to have the wiki features/content embedded was enough to convince us not to try and use a separate forum.
This article is really, "We couldn't adapt our processes to Slack, so we blamed the tool and replaced a chat app with processes, because we're special snowflakes and how could anything Not Invented Here apply to our totally unique problems of communication?"
Sure, they ended up with a series of other tools to cover their workflows, the thing they "invented" was how those tools work together to cover the gaps created by not actually having a comprehensive and well-configured chat app.
IMO just use forum software if you're going that way. Much more low volume, too (generally).
Further, "optimize for searching" isn't a thing. Teams gives full text search, and you can find any word or phrase you need to instantly.
I think you're optimizing for familiarity.
For example https://chat.zulip.org/#narrow/stream/3-backend/topic/Vagran...
If you don't want to be disturbed by notifications, there is the Do Not Disturb option to snooze notifications.
If you don't want to lose context, use Slack threads, which localize discussion around an issue to a single place.
If you have a fear of missing out because you're piping everything to Slack - have you considered segregating your alerts into specific channels and muting those you don't care about? (Alerts are a bad example, though - really, you should use Slack for a visibility record during an incident, but the only alerts you should care about should bother you with PagerDuty or OpsGenie - if they're important, they should bother you).
I do work for a larger company (some 400 employees) and we use Slack quite effectively. One thing that's really helped us is that, by consensus, we don't make decisions in Slack - everything of actual import should have a ticket to condense everything in. Slack becomes useful for us if we need immediate assistance, have questions or need to communicate in real time during an incident. It's also invaluable when you have remote employees (!).
How do people coordinate around incidents without something like slack? It used to be that everyone had to hop on a conference bridge, which I personally never liked.
For important discussions and decisions, we often paste a log of a chat and a link into tickets or change requests. This helps capture the conversation and people can review and/or challenge what happened.
As long as you keep it technical and kick the salespeople out of it, the conference call is very useful tool to keep people focused on mitigating the problem ASAP instead of spending time looking for the root cause (ex: restarting the application/reverting the bad commit instead of fixing a bug, creating a new build and pushing it through).
If the issue is not killing the company you can chat about it, sure, feel free to use the tool you feel most comfortable with. If we are in a "the site is down" situation though chatting is too slow (and I always promise the SWEs I will insta-revert their last deployment when that happens until I find a good one, though I rarely do so), and talking keeps your hands free.
In particular, image uploads (and possibly other attachments?) are always posted to the main channel, even if the message they were attached to was in a thread. Trying to conduct an image-heavy discussion -- like a discussion about a graphical design -- in a thread will just mean the main chat gets interrupted by a bunch of out-of-context images.
This is why the things that work for you don't work for others: Communication requires that all (or at least a significant majority) of parties agree to a protocol. It's not enough for a lone employee to start putting up Do Not Disturb when the culture insists on real-time responses.
I read somewhere that the crazy hours on Wall Street (purportedly 7 AM - 11 PM for new employees) are not because it takes 80 hours a week to get work done, but that there's a kind of social proof that one must demonstrate in order to be part of the "club". (Nobody's saying that you can't work 9 AM - 5 PM, they're just saying that everyone who was ever successful with the company put in the long hours, and you want to be successful, don't you?)
Similarly, it seems that Slack and other real-time communication removes some of the defenses that employees once had against these implicit demands. Note I'm not just talking about demands made by management of employees, I'm also talking about demands that employees put on themselves. (All it takes is one or two employees answering messages in the middle of the night to change people's expectations of when they'll get a response.)
As we enter an era of knowledge work, we're going to have to get better at recognizing and avoiding the social dynamics that can cause distraction and wasted time.
Use zulip - https://zulipchat.com . Opensource. Designed for threaded context.
One problem is that if you are trying to catch up on conversions, instead of just being time based, it's thread+time based, so while you can see which threads added messages while you were gone, it's not easy to actually read through them all.
The other big problem I found was people inevitably "reply" by (accidentally) creating a new thread, which then splits the conversation. If you're participating in real-time and there's not many separate conversions happening this isn't a big deal: but that's opposite to the situation where threading is actually theoretically useful, and catching up on multiple split threads is the worst combination of everything.
Maybe this is only really a problem with Microsoft's implementation, but I'm curious what other people have experienced?
I unironically wonder how widespread this problem is among the specific group of people who blame their lack of productivity on Slack, or failing that, how many people would admit their FOMO is enhanced by chat apps.
So many of the "productivity killing" problems I hear people griping about with Slack aren't really issues with slack, but human issues with boundaries of what we allow to take our attention not being defined, and ultimately, yes: FOMO. Things are going to get missed, you're going to come in late to certain conversations, but I often wonder do you need to be on the bleeding edge of these talks if they don't directly relate to you or even reside in the periphery of your responsibility radius?
Probably not, I would wager-but tl;dr very rarely does it seem like Slack is the cause of productivity problems, it just seems the convenient scapegoat. Especially since:
"work never happens in a vacuum" (FTA) is a statement that in my opinion, cuts both ways.
They're not specific to Slack, but they are specific to the existence of an official real time chat app. The boss expects you to read the chat, and if you just ignore it, you'll get in trouble and be deemed "irresponsible" if you aren't acting on it and participating in it.
I mean, you're right, you probably don't need to be on that edge, but Slack is this constant reminder of oftentimes BOTH important and unimportant issues, and they are difficult to separate so your attention is distracted regardless.
It's like saying "that endless supply of vodka in the liquor cabinet didn't make you an alcoholic." True, but if one DOES have a tendency to drink toward excess, getting rid of that liquor cabinet would be a great first step.
But the platform has a remedy for this does it not? In allowing you to turn on notifications for highlight words that you specify? Seems reasonable to me that if one wants to be alerted of conversations happening around certain topics, but work in peace without dings and bells for everything else, this feature works quite well in solving that split of attention between relevant and not relevant, no?
This may be an example of what I mean by boundaries; the user is completely able to define a boundary of distractions, turn them off, or turn them off but for certain highlight words so that they get notifications for, and are able to respond in a timely manner when a discussion comes up that might appreciate their input as a knowledge-holder/SME on the topic. Otherwise they continue to work unperturbed.
Is this a feature that people just don't know about or forgo using for some other reason, in your opinion?
Hit the nail on the head here. Things will get missed. The nice thing about Slack is that you can at least catch up with some conversations you missed at the end of day or in your free time. When you miss an IRL meeting, it's much harder to catch up. FOMO will be an even bigger problem when people start setting up meetings, especially ones where you aren't invited to or you can't attend because you're in another meeting.
This might be the key to whatever becomes the big "Slack-killer", assuming one comes around: Real-time-ish chat that with respects to workflow and UI/UX are structured around action-items (be they user stories, support tickets, or deployment artifacts), easily searchable, with support for taxonomy.
However how is the "Unread message" status icon, the notifications and e-mails about pings that are sent by default (Yes, you can deactivate them) not an indicator that by default Slack wants you to look into the program as often as possible. Maybe I am using it wrong, but I don't want to fight the defaults of notification overload all the time.
For example on Linux you cant even disable the system tray icon, I wrote a blog post with a hack to do this a few month ago: https://beberlei.de/2017/07/29/hide_slack_unread_and_highlig...
That's a good point, I know the nagging feeling you speak of just looking at my own iPhone and some of the messages that have queued up for my attention.
I'm not sure if there is really a way to reconcile that against our FOMO tendencies that technology seems to only be exacerbating-so I will concede that point but only so much. Yes the technology exacerbates the need to check in and remain accessible even across high latency channels (like distance, time zones, etc), but IMO only in the way that gravity also exacerbates the possibility that you will smash your finger with a hammer when trying to drive a nail.
One can admit that they might smash a finger when trying to drive nails, but they would still reasonably operate the hammer in a way that minimizes smashed fingers while still using the tool for its intended and designed purpose. I propose a similar view for our communication stacks.
Of course you can assign moral blame however you please, but the relevant "policy" question (in both the gun case and the slack case) is empirical.
You could measure the productivity of a single team with and without slack and see how things compare.
My guess is Slack would not fare well in that experiment, but I've never done it.
You absolutely can but if there's something about my post that insinuates any sort of 'moral' blame that a comparison to the "Guns don't kill people" trope (there's probably a better word for this) is warranted, then I've massively failed to express my intent clearly. Allow me to unpack this a bit for clarity.
The logical framework for "Slack doesn't disrupt your productivity, you allow your productivity to be disrupted" is certainly there, but that's about where the comparison begins and ends to the "Guns don't kill people" argument.
What I instead mean is tools like Slack and other real-time persistent chat apps definitely exacerbate FOMO and the need to reply, respond or react in someway to a notification. Their express function is to notify, to that end they're doing what we effectively ask them to do by using them in our workplaces. Note: I'm speaking rather broadly here, I'm quite aware you very rarely have a choice in the matter when joining a new company what chat service you're stuck with using.
But as I mentioned in another comment, they have this capacity about as much as a hammer has the capacity to injure a user trying to drive nails and hang a picture.
My curiosity of how we effectively 'blame' (pretend I'm speaking with a velvet glove here when I say blame I mean it as positively and delicately as possible) Slack for breaking our concentration is with the hammer analogy in mind. Certainly it has the capacity to disrupt but just like one would probably hold and use a hammer delicately enough to avoid harming themselves but deliberately enough to drive a nail, our comms stacks can easily be wielded just as well.
(That was a bunch of words up there above, but let me raise my hand right now and admit that I am absolutely guilty of checking every notification I see come in and breaking my own flow, it's why I even hold this position).
Right, so you are blaming yourself morally here (guilty of...). I'm not saying you're wrong to do so. I'm just saying that to solve the problem you can either:
1. blame yourself, and try to improve your own discipline when using slack.
2. stop using the tool that you know "tempts" you too much.
I'd rather bet on strategy 2. It's entirely analogous to throwing out all the junk food in your house when dieting. Sure, if you had the discipline you wouldn't need to do that, but so what?
I have no affiliation with the company/team, but love the product so much that I want to share it here!
The whole idea behind Twist is to be a team communication that doesn't have the productivity issues Slack does. I think it's a very well positioned and timed product.
We've been using it for months at our startup, Canny. Threads are a useful level of organization, such that it's always easy to find what I'm looking for. However, I don't feel like I need to check it constantly.
I have personally suffered from this far too long, specially when my work has been a hybrid of maker and manager. It becomes extremely hard to create pockets of maker time.
My solution has been to schedule 2-3 hour blocks of focused time around a project (Feature X) or responsibility (customer support) once or twice a day so that at the very least, I can create focus during those times. The key is to not over do it and get hung up on scheduling every minute, but just a few hours per day like this.
To facilitate this, I've built a slack bot that integrates with my calendar and I can mark these events as "Focus" events. The bot sets my status to "Do Not Disturb" during the event and if somebody tries to message me, they get a message that I am in heads down mode. They can then leave a note on why they were contacting me or if I they need me urgently, they can click a button and I get an immediate notification. When my focus time ends, I get a list of notes from my team on why they needed me and I can answer them one by one.
Effectively, I've found that once a team moves to Slack, all internal communication moves to Slack (instead of using slack for urgent sync and email for other async), and this brings back email like async model to Slack for the times when you need it.
You can try out the slack bot at https://slack.com/apps/A5MJB641F-oliv
In full disclosure, I've build the bot for my personal usage and don't intend to monetize it. It's just my way of giving back to the community. It's not very polished and doesn't have an onboarding flow, so if you need any help in using it, contact me at ishan.chhabra [at] gmail.com. I'll be happy to help.
In every case I've seen, Slack slowly replaces persistent documentation. Every issue one runs into can be resolved with a quick @here to the proper channel, or a DM to the tamer of Eldritch horrors (every company has one). This reduces the incentive to eliminate footguns or properly document everything, because look at us being all collaborative and solving problems together!
The smell for this behavior is having to search Slack for that last time someone helped you solve your problem. Slack is a great way to spread information, but it's a terrible tool to organize and store information.
If you ever have to do this, you take it as a sign to transfer that information into a document somewhere.
When I join a wide slack channel (e.g. #Design), I'm not interested in half a dozen different threads of communication happening on it everyday. But there might be couple of discussions per week that are pertinent and important for me to do my job well. There's NO way to ignore 90% of non-pertinent conversations without actually reading all the messages on the channel (yikes!).
I guess it's not suitable for every team though.
- Dozens of people in every room having multiple conversations, and any comment you make is quickly lost in the flow of other discussions.
- Ghost town.
I suppose we make heavy use to group DM's and project specific channels, but it really helps us keep communication streamlined and direct.
We don't really use email. If we need to ping someone on a PR review, it's done in Slack. If one of our systems is having issues, it's automated through a specific Slack channel.
This is the key probably. I can understand it doesn't work the way the author used it but personally I'm fairly happy with it (not to say it's the best, it's just one of the chat apps which mostly just works) and don't use all bells and whistles.
We use slack for 2 main things, 1 is chatty stuff which doesn't go to the issue tracker which has the important stuff which still needs to be there in a year (seems the OP had like everything in Slack, probably a source of problems mentioned) and due to me being a freelancer at that company it's perfectly normal I don't answer in a day or more. We learned to use it like that so no FOMO going on. The other use is as a 'dev/ci status channel' which is only viewed at passively: it gets all build info, PR/issue notifications etc which is a great overview, for us at least.
It makes much more sense to change the expectations / culture surrounding Slack usage at a company than to drop it outright.
You can use Slack and related applications for asynchronous communication in direct messages. On the other hand, I don't want to have to wait multiple hours for a reply when I only need a quick clarification in regards to a previous e-mail.
I don't want to waste my time with e-mail, and I don't think it's a better alternative.
There is real value in Slack and programs like it, and you give that up when you only use e-mail and GitHub issues and such. This is better if you have no one working remote, but it's far from ideal. Besides, if I had an office job I could ignore Slack messages. I couldn't ignore someone walking up and interrupting me in-person.
2. Phone calls are too real-time, to the point where you can't manage multiple separate phone calls near the same time or do something else if a phonecall only requires some attention.
Calls have their place, but I don't think they're a replacement for written communication.
The more responsibility you gain, the more interruptions you get. I have to make a conscious effort to ignore people for a few hours in order to get into a "flow" these days.
This can lead to some friction but I can't think of another way around the problem.
* Why does a chat blackout naturally follow a fear of missing out?
* What's different from the good ol' IRC days? Mute the channels, see them as transient, and focus on 1on1 conversations.
* Important conversations should not be solely communicated through a short-lived channel chat, but be summarized through email or whatever.
* You're already missing out on all the 1on1 conversations you're not in.
And I write this as someone who chronically checks for slack updates.
Maybe the "fear of missing out" isn't really about missing out on important information, as I initially thought, but about missing out on participation and the inevitable social/office dynamics around that?
I have never used IRC in a company, so I can't compare. Slack is the topic, because we used Slack. If we have had used IRC or HipChat or Microsoft Teams, then maybe we have come to the same conclusion.
Yes, summarization is important. However switching to E-Mail causes all its problems. New colleagues don't have the mails for example. Basecamp has chat and a forum/message board or todolists. We can easily link between these.
(Also are you sure minimizing interruptions should be a goal? If you cut off all communications you'll avoid interruptions, but that probably won't be good for your business)
I still have Slack, mainly because I like the #github channel that has all the GitHub activity, and the #industrynews channel, which has a bunch of RSS feeds of industry specific news. But those could be easily replaced with google groups/basecamp too.
Maybe I will just shut down the Slack...
Otherwise we know we can muted a channel but we cannot just do that to some certain channel because that's where the team annouencement happens.
Email isn't good either. Email can be easily get lost and not easy to search.
To me, Slack is super useful in 2 cases:
1. 1-1 or group chat between members on same topic 2. Archive log: I pipe all the information such as AWS activity(login, spin up server, AWS cloudtrait, Audit Log: ssh in out, K8S event...)
1. is useful to discuss on specific topics on a specificed thing.
2. is useful for on-call people to correlate with something, such as when AWS personal dashboard has issue we will know, when a server is added to autoscaling pool trigger Nginx reload, we may have trigger websocket reload and create a spike...those kind of things are very useful and easier to see compare to email to me.
We have a team of < 20 and Slack (and other comms tools like Hipchat which we used prior) were extremely useful and barely counter productive. There are a few channels that are noisier than others, but we do have a few important ones that are low volume where discussions do take place but are often forked into a separate discussion on another channel.
It's all about how your team uses the tool IMO and your team's organization of Slack. The key to FOMO is to not FOMO - missing out on conversations is fine (there are plenty you miss out on if everyone starts communicating and meeting offline), as long as you don't miss out on the important ones (which should be in a shared important channel).
Also, in a small company, over-communication is often more important than non-communication
Yeah, but you have to check immediately, unless you have immense willpower. And so the distraction is already made, the focus is lost, and the time spent switching contexts can't be recovered.
I'm open to advice on how to wean our project from chat to email (probably?) Or some better platform that helps new users and developers onboard without so much static
Someone new coming on board has a fairly organized point of entry, warts, bumps and all.
Anything else goes into our Discourse-based internal forum.
A question for HN for a hypothetical feature: What if the Slack client app had "ambient awareness" such that it suppressed notifications when the active window with focus is an IDE like MS Visual Studio, JetBrains, Xcode, emacs, etc. Would that help you?
Basically, it would work similar to Slack's "Do Not Disturb" feature[1]. DND could be expanded beyond "hours" to include a list of apps that shouldn't be interrupted.
Once a programmer switches away from the code IDE to the email program, that's the point the Slack chat notifications would appear. The idea is that programmers already sort of interrupt themselves[2] but since that timing is controlled by the programmer, a Slack notification is less stressful. Thoughts?
>Since work never happens in a vacuum, I would be happy to have only a single realtime notification tool (OpsGenie/PagerDuty) that sends notifications to poeple currently on-call, and only about problems that require realtime attention.
I don't use chat apps at work these days but when I did, I put AOL AIM, Yahoo Messenger, etc inside of a virtual machine that was minimized on screen. That way, everybody saw that I was "online" but their notifications were blocked behind the vm instead of making it to my desktop's taskbar. The vm acted like a firewall. I could then look at chat messages on my own schedule at my leisure -- typically once or twice and hour. For workplaces that expect you to reply to chat messages in 5 seconds, this hack won't work.
[1] https://www.youtube.com/results?search_query=slack+do+not+di...
Currently, I've built a slack bot for personal use that integrates with my calendar where I can create stretches of times as "Focus" events and during that time, the bot helps me establish an async communication model.
The bot sets my status to "Do Not Disturb" during the event and if somebody tries to message me, they get a message that I am in heads down mode. They can then leave a note on why they were contacting me or if I they need me urgently, they can click a button and I get an immediate notification. When my focus time ends, I get a list of notes from my team on why they needed me and I can answer them one by one.
Effectively, I've found that once a team moves to Slack, all internal communication moves to Slack (instead of using slack for urgent sync and email for other async), and this brings back email like async model to Slack for the times when you need it.
You can try out the slack bot at https://slack.com/apps/A5MJB641F-oliv
In full disclosure, I've build the bot for my personal usage and don't intend to monetize it. It's just my way of giving back to the community. It's not very polished and doesn't have an onboarding flow, so if you need any help in using it, contact me at ishan.chhabra [at] gmail.com. I'll be happy to help.
What are your alternative approaches?
FWIW my impressions is hatred of Slack is more a hatred of "I can't control by impulse to read everything so it's a tremendous time waster." Slack's not the problem, it's the person's self-control that's the problem in these situations.