Don’t Play Slack-a-Mole

A quantified look at Instant Messaging

If you’ve worked at a company that uses Slack, or talked to anyone who does, you probably know that everyone loves Slack. It feels great to not have to write emails or archive them. It also feels great to get an immediate response, and see conversations resolved in minutes, not days. Slack makes their users feel 32% more effective, in addition to being a more transparent, personal, and friendly medium. Plus, in Slack, it’s like everyday is casual Friday — punctuation, capitalization, and grammar give way to emojis and gifs. Slack is fun!

So what’s the catch? Sometimes, Slack (or your favorite chat app, this topic applies equally to any of them) is the best tool for the job, but I’d like to delve into cases where it isn’t. Every tool has pros and cons. The cons with Slack are so small that you probably can’t feel or perhaps notice them, but I intend to quantify them for you because they can add up. Yes, with math. And because math papers have footnotes, I will have footnotes — but I promise they’ll be fun to read!

‘Everyone loves Slack’ because we reap the benefits in a concentrated, big dose when we start a conversation in Slack. However, we pay the cost in diffuse little increments as we get pulled in to conversations throughout the day.

By cost, I don’t mean what’s on our invoice. I mean whatever didn’t happen, after you saw a notification ‘just asking for a quick look at [insert thing you are not currently working on]’. (Footnote 1) Since this kind of cost is fuzzy, I knew I needed real data rather than anecdotes to measure how massive it actually was. I’ll also show you how we fixed it, and don’t worry, it wasn’t by getting rid of Slack.

The listening cost of channel messages

After pulling a month’s worth of message data, I ran the numbers. Every day, the average “channel” at our company contains 39 new messages. (For non Slack-users, a channel is the name for a public team chat about a particular topic, and most employees are members of several.) Across all channels, around 6,400 messages are sent per day, just at our company. But is that too much?

Each channel has many ‘listener’ members, in addition to active participants in the conversation. Conservatively assuming 10 employees per channel gives the total reach of those messages; it turns out those channel members are indirectly asked to ‘have a quick look at this’ roughly 20 million times per year. And that’s just spread over our 164 total Slack users. While we don’t look at every message, roughly 11% of these messages have an @channel or @here in them that trigger a push notification, so we definitely look at an absolute MINIMUM of 2 million of them. (Footnote 2)

Why all this silly math? You don’t know what you don’t measure, which makes a cost so seemingly small and of such high volume of particular interest to me. This simple calculation had me off to the races to dive even deeper, if for no other reason than because I was pretty sure nobody else would. The results were super interesting.

The listening cost of DMs

I’d like to specifically focus on the set of messages not included in my numbers above, because that is where I really started to feel the cost of using Slack. The 20 million reach of messages only accounts for channel/group messages. However, nearly two-thirds of Slack messages at our company aren’t in channels at all! They’re in Direct Messages (DM).

Managed by Q Slack Messages by Type, Month of Nov ‘16

While a DM may sound like less of a concern for interruption than a public channel, they have a very different social contract:

- Unlike channels, you are assumed to always be listening. The sender knows you received a notification about their message, much like SMS.

- Unlike channels, you are the only person who can weigh in on the matter, so the message cannot be answered by someone else. It is awaiting your response.

This means that DMs feel much more urgent and important. Ever interrupted an in-person conversation because you noticed something in a Slack channel? Me neither. But you better believe I’ve cut off a verbal conversation midstream to answer a DM.

So what is the aggregate listening cost for DMs? At our company, over 10 thousand direct messages exchange hands EVERY WORKDAY. Sure, many of those messages span conversations and happen in rapid succession, so not all are interruptions. But the first one in a conversation is. If I could quantify an average DM conversation length, I could determine how many of those were new messages — or interruptions. So, like a nutjob conspiracy theorist, I actually did the work to quantify that. (Footnote 3)

The data reveals that the average person at our company receives over 14 inbound DM conversations per day. I asked around, and people generally seem to cop to that, so it passes the sniff test.

Let that sink in. 14 is a data-confirmed, low-end-average for the number of high urgency, high importance interruptions each person at our company gets over DM every day.

“So,” you say, “what’s the big deal with 14 interruptions per day? Had they been emails, I still would have dealt with them eventually.” But you didn’t deal with them eventually. You dealt with them immediately.

DMs prevent prioritization

Inbound DMs have a default urgency of NOW and a default assignee of YOU. This urgency suggests last-in-first-out (LIFO) as a rule for prioritizing the work. So imagine you’re working on unit A of work, and you get a DM about a different unit of work (unit B). You refocus and start doing unit B, but then you get a new DM and refocus again, now on unit C. You’ve gone from working on whatever was at the top of your list (unit A) to juggling it with two other projects someone else picked for you to work on. You probably let unit C become the most important, solely because it was the most recent.

What’s more, often there is another team member better suited to address the work in the DM, and maybe they have a lower opportunity cost or know how to get to the solution quicker. With a DM, you’re the only option. (Footnote 4)

There is a popular word for what’s happening — someone else puts some work into the very top of your queue, interrupting what you are doing and obligating you (socially or implicitly) to work on it now. The workplace slang is to call it a firedrill.

DMing someone might as well be called firedrilling them.

A deeper understanding of listening cost

Every time you step away from your work, you don’t just succumb to someone else’s priority. You also lose some of your progress. Think about trying to read a book while shopping for groceries. You couldn’t seamlessly switch between the two — in fact you would likely do a horrible job of both tasks. (Footnote 5)

For a moment, set aside the time you spent on the distractions, and imagine you had a stopwatch timing only the original work you were doing, stopping during time spent on the new task. Let’s assume that the interruption made the elapsed time to finish the original work just 5 minutes longer than had you not been interrupted (although it’s probably way more).

Now the kicker, and the point of all this math. At 14 interruptions per day, that five minute cost adds up to over an hour (~72 mins) of productivity lost. By every person at the company.

Every. Single. Day.

To avoid any confusion, the 72 minutes is not the time spent on the interruptions, this is just a slowness tax we all have to pay every day. The only reason we aren’t up in arms is because nobody measures this cost. (Footnote 6)

I like to call this unmeasured, unpredictable interruption phenomenon Slack-a-Mole. Don’t play Slack-a-Mole. You’re never gonna win the oversized teddy bear.

What we did about it

At first, my team created a ticket-based system for requests to be submitted to support teams at Q. We figured at least requests would then stay out of our DMs. A tried and tested solution; but it turns out ticketing systems suck. We immediately got desire paths telling us as much. In our case, the desire path was people firedrilling us over DMs telling us ‘I’ll submit a ticket, but [insert conversation anyway]’. Woof. People don’t want to load up a website and fill out a form to talk to you. It’s impersonal, one-directional, and slow.

Part of my team’s mantra is that being user-centric is not something that should be relegated to consumer-facing product teams. We may have mostly internal stakeholders, but we treat them like they could churn away from us.

Getting to a better solution

First, we arrived at a partial solution by copying something that was common on other support teams at our company — a dedicated support channel in Slack for our team. People could come in and make requests to the team, and not the individual, but they could still use Slack to do so. This enabled us to get back in the driver’s seat of picking who worked on which requests. The team member that was least deep in the weeds of their work could hop in and take a first pass at helping.

But the ‘do it now’ problem persisted, and then we all had to be on alert to stay on top of incoming requests before they got ‘buried in the feed.’ Getting buried in the feed is inherent to instant messages: the same happy phenomenon of ‘one less email to archive’ means important, unhandled stuff can get buried too. Some teams rotate a person as ‘on call’ for this job, but as a team of three, losing most of a whole member’s productivity was a pretty costly solution, and seemed like an undesirable assignment.

So we designed a 20% effort, 80% solution. Focusing on the end-user experience, and using our trusty tool Zapier, we embraced the desire path and created a way for people to log a request in our support channel that would ‘save it for later.’ Zapier would scan messages for a delimiter we made up ($request), and save it to our team’s task list in Asana. We also built a loop-closing notification with Zapier. When we complete $request tasks in Asana, the stakeholder gets a notification in our channel that it has been done, and by whom, so they can ask any follow up questions.

Turn on $request for your company TODAY

Sound interesting? It‘s DEAD easy! In fact, here is a step-by-step template to turn on $request in your org!

Suddenly, my whole team could stay heads down in work if needed, knowing that anything we had to get to later was saved. We’d see a list of every request made, triage ownership and drag and drop them into whatever priority we wanted. Our queue of work changed from Push to Pull, and it felt great.

Results

Anecdotally, our inbound DM frequency feels orders of magnitude lower now. In addition, our channel has many of the hallmarks of a ticketing system, but to the user, it has the awesome usability of Slack. $request is our silver bullet.

Our support channel now has one of the highest memberships of any within our company’s Slack instance, and seven other teams asked us to set up $request for their department. SEVEN. This means that at this point, more teams at our company use $request than don’t, and they each independently came to me. The viral internal adoption of this solution made me realize that I should write this article and instructions so you could build it yourself.

How $request plays out in the data

I again analyzed our dataset focusing on seven channels: three regular old Informational channels (control group), two standard Support channels, and two $request-powered Support channels. Here’s a quick look at the results (good numbers are greener and bad ones are redder):

The long and short of it is that the $request-enabled channels have greater engagement (Footnote 7) per member, but with lower effort from support team members. Even better, they had drastically lower or nonexistent percentages of @channel/@here messages — the shotgun-spread firedrills aimed at dozens or even hundreds of people in a desperate search for whomever can help.

I am elated to see the data support my enthusiasm for this new process, and even more elated that we can feel all the benefits of Slack while mitigating the catch. We love Slack!

Yes, this will work for your team too

The most common backlash to this idea I hear is ‘this would just open us up to all the dumb little things people want’. Anecdotally, it happens, but I find this to be the exception rather than the rule. Either way, remember you are now in the driver’s seat for prioritizing and even responding to these ideas. We put no SLA on $request, because now that the progress is evident, we have earned the trust that we are building the best stuff on the list. Sacrificing all the benefits I have mentioned (Footnote 8) to reduce your prioritization overhead, to me, is crazy. There are literally websites where you pay good money for user feedback and usability testing. We built a machine to draw it out organically. It gives us an edge in faster iteration by having shorter learning cycles.

Based on my team’s increased productivity, I highly recommend you give this system a shot. Follow our instructions and let me know about your experience in the comments!