jml's notebook

Published

2020-01-18

At work, someone recently shared a post on backpressure, specifically in the context of Python. It's OK, but I think you'd be better off reading the medium post it links to or Ted Kaminski on backpressure.

Anyway, it reminded me of why Slack sucks.

The idea with backpressure is that any system (consumer of requests) is going to get overloaded and needs a strategy for dealing with it. Per Jay Phelps, there are three strategies:

1. Control the producer (e.g. slow down requests)
2. Buffer the requests (e.g. keep them in a queue and deal with them later)
3. Drop the requests (i.e. ignore them)

There's a variant of 3 that Phelps doesn't mention, which is handling requests in a much cheaper way. For example, you could reject requests rather than drop them.

Control also has a variant. The consumer can exert backpressure by communicating information about its load. This requires producers to cooperate, but this is more or less how kanban sometimes works. It's probably better to think of it as "signal to the producer".

So what does this have to do with Slack?

On an average working day, I guess I get several Slack DMs or @jml messages an hour. This means my mean time between interruption is something like 10 to 30 minutes. That's more than I can handle. What are my options?

The easiest thing is to drop the requests. That is, to ignore them. However, the Slack UI makes this hard, as such requests are permanently highlighted, and have badges that function as calls to action. It's also hard psychologically to just ignore my colleagues. I'm also not sure it's the right thing.

The next easiest thing to do is buffer the requests. Except, Slack doesn't really have a way of doing this. The closest I get is starring messages that need responding, or copying a link to the message into my actual todo list. It's very fiddly. Also, my colleagues can't tell the difference between being ignored and being queued. For some people, I'll say I'm busy right now and I'll get back to them later, but I've learned others interpret this as an invitation to negotiate, so I'll stay shtum.

All of which is another way of saying that Slack provides no signal to people about how busy their interlocutor is. This is especially true when there's a culture of DMing. When you DM someone, you have no idea how many DMs they have had in the last five minutes, nor from how many different people.

Compare this with email, especially Gmail.

With email, there's no expectation of immediate reply. In Gmail, the Inbox acts as a queue, so no special tricks are necessary with starring and what not.

With Slack, you kind of need to have notifications turned on for DMs and mentions, not so much because of other people's expectations (there is that), but because there's no good way of reviewing the mentions and dealing with them one by one, the way there is in Gmail. It has a default backpressure strategy of buffering requests.

Dropping a request takes a single keypress ([ on an open message) and then you'll never see that message again, unless you search for it. In Slack, you have to register an intention to ignore the message in your brain, and then remember that intention each and every time you look at that message.

Email, like Slack, lacks any support for communicating your load to those making requests.

I don't really have a conclusion for this. I just wanted to write down my thoughts to get them clear in my head.

It's right to value timely, responsive help, but that's something we seem to do by default. It's also right to value deep focused work on things that are difficult and not as immediately rewarding as a colleague's smile. I think very, very few people or organizations drift toward that--it has to be something intentional. These values, help and focus, are in tension but are not polar opposites. It seems reasonable to me that any organization would be almost constantly debating and deciding how much to favour one over the other.

What sucks is when we let someone else's software make the decision for us. It needs to be the other way around.