I use a service called RescueTime which watches over my shoulder with a stopwatch, and keeps track of which applications I spend time in over the course of a workday. Generally, it breaks things down into three categories: blue time is spent using things like a terminal or a text editor, red time is spent on sites like YouTube, and gray time is mainly communication and scheduling applications.

There’s very little red on my reports these days, but there’s a fair amount of gray - if I could cut that down, I’d be freeing up useful time for blue work, which for me these days is reviewing pull requests, researching my team’s technology in detail, one-off research projects, and implementing features. This kind of thing is the core of my job, so the more uninterrupted time I spend doing it, the more I’m focusing on my comparative advantage. An ideal day would be all blue, with no gray, and no red.

So, where is that gray time going, and how can I cut it down in service of the blue?

The two gray-time sinks are Zoom and Slack. They’re used in quite different ways, and take different strategies to reduce.

I work full-time remote, so Zoom is a measurement of meeting time. Cutting down on Zoom time therefore means being in fewer, shorter meetings. This can a tricky negotiation, but it’s basically straightforward - check the agendas for recurring meetings, and skip the ones that I don’t need to be in; run short, efficient, prepared meetings myself; and lean toward skipping big meetings that will be recorded (watch the recordings later at increased speed, skipping the fluff).

Slack is a bigger chunk of my time than Zoom, and a more interesting one. I currently spend about a half-hour a day in Slack, according to RescueTime.

I got to thinking about this in terms of a queue of messages - messages pile up until I check it and process them all, which corresponds to emptying the queue.

There are two hazards to steer between: the Scylla of processing the queue too often (fragmenting my attention and drawing me into marginally-useful conversations) and the Charybdis of processing the queue too seldom (missing a time-sensitive question, or a short window in which to contribute usefully to something that matters).

How can I compute the sweet spot - the correct interval at which to check the queue?

I think what matters here is the rate of time-sensitive messages. If, for example, there was never a time-sensitive message, I could get away with processing the queue in big batches, weekly (or monthly, or annually). However, if time-sensitive messages came in at a rate of one per hour, processing weekly would be disastrous - I’d see messages on Friday that needed a response on Monday, and the system would quickly collapse.

Let’s call the rate of time-sensitive messages per day m. For any non-negative integer p, a processing rate of p per day means that any processing cycle has a chance of m/p of yielding a time-sensitive message. The more my colleagues will tolerate a delay in response, the lower a p I can get away with. 2m seems like a reasonable starting point for p, yielding a 1/2 chance of a time-sensitive message per processing cycle, and I can dial it up or down as events warrant.

Happily, based on a week of notes, my m for Slack messages is fairly low: I average only about 1 time-sensitive message a day (I was surprised by this). So, setting p at 2 means that I should be processing Slack no more than twice a day.

Few processing cycles per day is good, but for this to work well I also need to make processing efficient. The ideal is to open slack, skim and categorize every incoming message, and quickly close Slack and get back to something more useful.

I use Slack’s “Saved Messages” feature for this purpose. For each incoming message, I decide:

Thus, my processing cycles are fast, and interesting things pile up as “Saved Messages”. I handle those in batches during those strange gaps of time on meeting-heavy days which are too short to do serious work - open Slack, grab the first “Saved Item”, address it and unsave it. I try to empty this out entirely once a week (usually on Thursdays, which is one of my two meeting-heavy days).

Links