Your day is a mess. By the end of the day, the predominant feeling is that you probably got nothing done. Or maybe you got nothing done and wasted countless hours on low priority, unimportant tasks.

If that’s the case, you’re not alone. That was me two years ago. Did I solve all my time management and planning problems? Far from it. I did improve the situation a lot, though. Up to the point that I’m comfortable enough to say that I moved from a “fire-fighting” phase to a “what can we improve now?” phase. Big problems are a thing of the past. I’m now looking for opportunities rather than running after issues.

In “Life hacking 101: I’m bad at to-do lists, now what?” I discussed that one of the significant causes of frustration could be context switching.

From now on, I’m assuming that there are no other extraordinary causes. For example, there is a pandemic; Life catapulted you working from home on a kitchen table sitting on a high-chair, in a single room apartment with two toddlers around.

One important caveat when analyzing any complex problem is that there isn’t a single root cause most of the time. Many factors are contributing to the rise of a problem. Some elements can have more impact than others, and solving the most impactful one might be a good strategy. Although there are cases in which a lateral-thinking-based approach might be better: do not address the big culprit, instead workaround it and smooth all the surrounding issues first.

How did I do that?

In “I’m a procrastinator, I fail at to-do lists.” I described the way I plan for the upcoming week. The planning activity is not the same anymore. Instead, I implemented minor improvements here and there over time. The essence, though, didn’t change. Every Friday, I carefully plan next week. During the week, if something changes or something didn’t work out as intended, it’s reflected on my calendar.

I started the described approach around November 2018; by the end of 2019, I had 14 months of data stored in my calendar. For a completely different reason outside the scope of this article, at the beginning of 2020, I spend a whole Sunday retroactively categorizing all the entries in my calendar and collecting data in a spreadsheet. The spreadsheet groups data using the following categories:

  • Product management/ownership
  • Day to day tasks
    • Business tasks
    • Technical tasks
  • Mentoring
  • Onboarding
  • Conferences
    • Preparing
    • Attending
  • Interactions with customers
    • Support
    • Other activities
  • Planning
  • Reporting
  • Open Source / Communities
  • Inbox and To-Do lists

Those are not the actual names I’m using; most of them use the internal vocabulary, which would probably make little sense to the reader. The essence is preserved, though.

Every Friday, while planning next week, I spend a few minutes collecting in the spreadsheet current week data.

It’s February 2021, and I have more than two years of data. Last month I sat down, again on a Sunday, and spent some time looking in-depth at what I have. What I found is, in retrospect, not surprising, but still very interesting.

In 2019 a little less than 25% of my work time were conferences. Three entire months, more or less 90 days, 720 work hours dedicated to conferences. More importantly, two-thirds (68%) of that time was spent actually attending the conferences. Think about it: 489 work hours spent traveling, attending, and giving talks at conferences. And let’s be honest, a conference talk lasts one hour in the worst case, sometimes less.

Another interesting data point was that about 18% of my workload was unplanned activities. During the week, unexpected tasks happened, something I did not plan the previous week’s Friday planning session. In 2019 I wasn’t tracking those events; I was filling calendar slots with “Inbox & TODOs” items. Finally, my reporting effort told me that 14% of my time was “Product management/ownership,” and another 14% was “day to day tasks.” Results came as a surprise, I felt unproductive and overwhelmed, but I was unaware of how unproductive and overwhelmed I was. Think about it for a moment; the two most important categories, product management, and day-to-day tasks, accounted for less than 30% of my total work time. And I’m not telling you how fragmented were the remaining activity clusters.

2020, the year of the pandemic

In Italy, we started suffering from the effects of the COVID-19 pandemic in the February/March 2020 timeframe. I live 60 kilometers away from the eye of the tornado where everything (outside of China) started, and the tornado took very little time to lock us at home for months.

Conference time dropped to 3%, a few online community events. The notable thing was the redistribution of that available time:

  • Product management shifted from 14% to 20%
  • Day to day tasks from 14% to 27%

Not that bad, the majority of the time recovered from not attending any conference went into planned productive work. Unfortunately, when it comes to the unplanned stuff, better tracked in 2020, the benefit was a mere three percentage points gain, from 18% to 15%.

15% of unplanned work is the average for 2020. During summer it was still around 18%, and now it is down to 11%. Given that the situation was the same, I sat down once more for another round of analysis around August 2020.

Why that amount of unplanned work? Looking in-depth at my calendar week by week, it was clear that activities were too fragmented. If there is a recurring 1-hour sync call at 10 AM European time, the morning became a context switching mess.

The other problem was that a 100% increase of “day to day tasks” led to an even worse situation. We work in small groups, and we tend to pair a lot; I was joining too many activities, which means joining too many groups, which resulted in even more fragmentation. Each day I was working with three or four different groups, on top of all the other things.

I had two options: give up on a few things or find a solution to reduce context switching hell. I did not want to give up on anything, and to some extent giving up on some things giving up was not an option at all.

Why not both?

The first thing was to rearrange as much as I could my calendar to group similar things. For example, during recurring product management syncs, we capture action items, and at the end of the sync, we assign action items to each participant. It’s easy to view those action items as tasks on a to-do list, in which case the problem for me is that they get a very low priority (remember that I’m a procrastinator). Instead, I scheduled a recurring 45-minute slot ten minutes after every sync to get all the assigned action items done.

Tip: always leave a buffer between scheduled calendar events. Things can exceed their planned time, or we need a break, coffee, tee, or a snack, or the restroom. Or leave time for low-effort context-switching filler activities ;-)

I didn’t stop myself from defining “action items” slots on the calendar. I spent a significant amount of time rearranging my weekly schedule, which was enough to alleviate some of the problems. Again, with the goal of grouping similar activities.

The second thing was to serialize more and parallelize less. How? Join fewer groups, but more importantly, be more conscious about what you join. Theoretically, zero context switching is possible if we were doing one thing. In my case, and probably this is true for everyone, it’s impossible, and I’m okay with it. Instead of trying to be on top of everything every day, I moved, where possible, to a two to three-hour-long slots calendar. When working on group assigned tasks, I try to allocate to each task two to three hours. Those are long enough to get a lot done, short enough for my attention span, and compensate for the context switching effect well. At the beginning of the slot, it takes me about 15 minutes to answer the question, “where did I leave off?” And then have a significant amount of time at full speed. At the end of the slot, the ten or fifteen minutes buffer works like a decompression time to prepare me for the next thing.

Tip: I have a three-screen setup, and I do not keep email or Slack open on any screen when in need of concentration. Our eyes are extremely good at being distracted by a new Slack message or a new email. If you need Slack, use CTRL+Shift+D (in the App and the browser on Windows) to hide the sidebar and keep open only the channel you need. Or use a multi-desktop setup to create an isolated environment for the current task. Sometimes I find myself running a lot of desktops.

What you do is equally important to how you do it.

With a two to three hours-long slot, half a day is gone. And that simplifies things a lot. Let’s imagine a typical workday:

  • I sit down (stand up to be more precise) at my desk around 8.15.
  • The first 15 to 30 minutes are: making sense of life, trying to remember my name, attempting not to spill coffee on the keyboard, and quickly going through notifications, such as email and GitHub.
  • The long slot starts, and by the end of it, it’s 11 or 11.30

Usually, lunchtime is around 12.30. After the long slot, I need some decompression time, and then I need time to go back home. I have an office, the flat where we live is too small to work from home properly.

What can I do for the next 45 minutes? That’s easy; we have many activities that fit perfectly, ranging from tasks that we call “Small tasks” to customer support to more critical activities that work well in an asynchronous manner even if performed by a group of people. Mornings set, and afternoons follow the same pattern. There are days in which there are more traditional types of meetings and days where for most of the day, I work alone or spend the majority of the day “pairing” with one or more colleagues.

Conclusion

Context switching is one of the ugly beasts that can be a productivity disruptor. It’s not the only culprit, that’s clear. Distractions are just around the corner and can be as problematic as context switching. In any case, before taking any action in an attempt to fix any personal productivity issue, it’s essential to dissect the problem and try to understand its source. Only once we have a better understanding of the problem we want to solve can we implement countermeasures.

Photo by Ryoji Iwata on Unsplash