Notification Hell

January 10, 2016

Recently The Atlantic published an article titled The Triump of Email. It starts with a good history of e-mail and then goes on to describe that although e-mail started as a novelty, it proceeded to degenerate into a nuisance; eventually quoting a description of it as “notification hell”:

“We let email interrupt us dozens and dozens of times a day, and that is awful,” Moore said. “There’s research out there that says every time you get an email notification and you look at it, it takes you 64 seconds to recover. You basically can never work. You’re constantly recovering from the notification.”

“We’re stressing ourselves out,” he added. “We’re living in notification hell. That’s really the thing that’s at the root cause of why people hate email.”

Then, as is quite fashionable these days, it describes Slack as a solution to e-mail; even describing its use as literally “transformative”:

Slack, a real-time messaging platform built for the mobile era, may be the best known example of what business communications might look like in a post-email world, but many companies bill themselves as inbox destroyers. (It’s not an overstatement to say Slack can vastly reconfigure a person’s relationship with email: The Atlantic has used Slack since 2014, and, for me, it’s been transformative.)

I like Slack as a product (maybe even moreso than most having endured long periods of using Campfire and HipChat), but this is where this type of glowing endorsements really lose me. Slack is an incredibly functional, refined, and feature-rich chat program – maybe the best of its class ever written – but it’s a chat program, and not substantially different from its progenitor IRC which had its first implementation written in 1988.

I’ll give its major proponents the benefit of the doubt in that it that when comparing a Slack interrupt to an e-mail interrupt, the Slack interrupt has a few advantages:

  1. The bar to getting out a response is lower. You can get away with just typing in an emoticon, whereas with an e-mail, you might be expected to compose something a little more thoughtful. This might result in more (and faster) feedback from a larger group of people.
  2. If we consider that either type of interrupt may come with some kind of work required to respond (e.g. “why did this request fail?”), the average size of the work item coming through Slack is probably smaller. Larger work items tend to still come through more official channels like an email or a meeting (but by no means is this always the case).

But for counterpoint, we should also look at some places where e-mail shines:

  1. Messages tend to be well-organized and complete thoughts. These take longer to write on the author’s part, but are easier and faster to digest for all readers.
  2. Conversations are threaded (much more granularly than a Slack channel) and the “mute” function gets you precision control so that you only read what you care about (after the first message).
  3. Its use is dictated by the user (list subscriptions, tags, and filters) rather than the provider (channels, bots), and this has huge benefits in allowing those users to effectively manage incoming items in a way that works for them.

But all things considered, Slack has a huge downside that vastly outweighs any possible benefits to productivity: it’s always on. E-mail might be disruptive, but you get to use it on your own terms. During a normal workday, I might check it once an hour and clear out any incoming interrupts en masse by batching all that work together. But with Slack, those same interrupts will come in piecemeal at regular intervals, and worse yet, their senders will expect an immediate response; an easy recipe for never being focused enough to get through any significant work (more on this phenomena here).

The bottom line is that there’s no way that we can in good conscience describe e-mail as “notification hell” without calling Slack something far worse.

Notification Hell was published on January 10, 2016.

Find me on Twitter at @brandur.

Did I make a mistake? Please consider sending a pull request.