Email: A source of stress
Email has been a significant source of stress for me. Canonical, Red Hat, Debian and free software projects all are a firehose of announcements, discussions, bug reports, review requests, questions, and work tasks every day.
I am fairly good and efficient at quickly deleting the 90% irrelevant email, but the type of “10 seconds for the sender to write, half a day of work for me to act upon” emails pile up, break my motivation, and cause annoyance and refusal. This also leads to me having an unacceptably high lag in responding to my coworkers about important, but not very time-consuming questions, as they just fall through the cracks. It also led to me basically not participating at all in group discussions.
Email processing used to be a “filler action” in between two compiles, test runs, and similarly short forced pauses. That is enough to delete the next batch of noise, and quick actions, but not enough for thorough discussions or “please review this design document”. I used to take some longer time stretches for the non-trivial mails, but not systematically.
I had wanted to practice “Inbox Zero” for years, but in reality I only managed to clean up all my mail boxes before summer vacation and end-of-year holidays, and even then usually not all of it. Over time, more and more old stuff piled up and stared at me every day. Thus emotionally, email was not a helpful tool, but a major annoyance – both to me, but of course also to people trying to contact me and having to wait for an answer sometimes for weeks.
How to fix this?
Shortly before the end-of-year holidays last December, I went through the usual “clean my desk” exercise again, and as usual it felt so good afterwards. But then I thought “I really mean it this time – how can I make this stick?“. How can I keep Inbox Zero perpetually?
Goal: Every email that I get must not stay in any of my three inboxes (personal, work, Debian) for longer than a work day. At every work day there must be at least one time when all inboxes are empty (“zero”).
My previous attempts at this all failed, so clearly some things had to change. I now know that it is vitally important to really be at zero. “Almost all” is simply not good enough (“broken window theory”).
So I decided to try the following:
Treat email as real work: E-mail is a first-class deep work activity like my development tasks. Schedule it, time-bound it, configure it more properly, and find a systematic way how to deal with things that I will realistically not get to.
Have a workflow: Find rules and adjust them over time what to do with different classes of email. This takes off the mental effort of having to think much about the “how and when” in every single case.
Measure/gamify it: Keep a record of when I hit the goal, generate reports of it, and show me how close I am to making this a habit (which usually takes two to three months). I found that keeping an existing non-trivial streak was working quite well when learning French at duolingo.
Create external pressure: Announce my goal to my coworkers. I don’t want to report “meh, I failed again”.
Reduce the amount of email: In the last 4 months I got 159 emails every workday on average. Analyze types of emails which I regulary ignore anyway, and set up email filters, GitHub notifications, and reduce mailing list subscriptions to reduce that by at least 20%.
According to my gtimelog, I had spent pretty exactly 1 hour every day on email or IRC discussions on average in the last year, although with a rather wild daily deviation (unfortunately I didn’t track email and IRC separately). I feel that’s about the limit of what I find acceptable, so I started my scheduling with that.
Conceptually, I want to split my days as much as possible into “maker schedule in the mornings” for software development, and “manager schedule” in the afternoons for meetings and project management. Email would fit right into the latter, so I started with putting in that hour at 14:00 o’clock every day.
But in practice I feel a strong urge to “see what’s burning” in the morning. So I quickly changed that to 30 minutes in the morning, and another 30 minutes after our standup meeting in the afternoon.
I put these as appointments into my calendar, so that I would get reminders and not try to sneak in something else at that time.
These are my rules for a new email:
- Takes ≤ 10 mins or is urgent? → do it right away, archive/delete
- Will I realistically ever deal with it? If not, do a quick “sorry, perhaps ask XXX” reply, archive/delete
- Otherwise: track in GTD (“someday/maybe” list is entirely legitimate!) or our team’s Jira board; if it needs reply/action later, move to “waiting” folder, otherwise archive/delete
Incoming bugzilla emails for our project are similar, but a bit more refined:
- Review all bugs as they come in, put urgent ones on TODO list, or assign them to the team
- Delete non-urgent bug notifications
- Schedule weekly bugzilla review, to clean up and move interesting/important ones into the sprint
Some browsing in F-Droid quickly brought up the Loop Habit Tracker app. This is pretty much exactly what I wanted: You can track a set of habits you want to develop, state your goal (like “all inboxes zero 5 times a week”), every evening I tick the boxes that I achieved on that day, and it does all the rest. It computes statistics, streaks, and a “how close I am to make this a long-lasting habit” score:
This nicely shows that I most often don’t achieve this on Saturdays, as I don’t want to spend too much time on Saturdays to catch up with the stuff that happened late on Friday. I expect this to start look much worse once the Covid restrictions end, and we start travelling again 😀 But that is okay – I deliberately formulated my goal in terms of “every work day”.
While I was at it, I also started to track some other habits: “do sports” (4 times a week), “eat vegetarian” (6 times a week), and “practice guitar for at least 20 minutes” (4 times a week), as this is really fun!
Last December, I told this goal and my plan to my manager and one of my co-workers. She also formulated some goals of her own, and we review each other’s progress every other week in an 1-on-1 video call. I really like these – they feel like a “running mate” situation where we can talk about what we tried, what worked, and what didn’t.
For two weeks I looked at each email that I got, but not acted upon, and tried to generalize if it was possible and worth it to not get it any more in the future. I unsubscribed from a few old mailing lists, Debian and Launchpad projects, fixed some default assignees in bugzilla and such, but I found this is really hard for most things: There are just too many mailing lists, bug trackers etc. where 5% or 50% of their email output is relevant for me, but there’s no simple pattern to it.
In the last three months I actually got more email on average than before – 342 on every work day.
According to the habit tracker, I’ve managed to keep my streak since day #1, and I now feel a lot better about email as an useful tool.
For me, the “have a workflow” and “measure it” strategies were the decisive bits.
The scheduling in the calendar also helped quite a lot, but I find that I often deviate from this anyway – I still open mutt way more often during the day. Although this mostly happens because of GitHub notifications, where doing e.g. PR review iterations would just be too slow otherwise.
But that doesn’t seem to break much, I still stick to the split from above by and large. I actually spend less time in mutt than before, and it’s much more systematic and effective. I even stopped putting them into my calendar, as the “morning/afternoon dedicated email activity” has become a habit now, and I can apparently allow myself some more flexibility. Once I feel that this slips, I’ll reinstate the calendar appointments.
The “external pressure” wasn’t a deciding factor – I’m fairly sure that the intrinsic motivation would have been enough. But it certainly can’t hurt to add this approach – aside from the fact that in our all-remote team we rather spend too little than too much time in personal chats.
Trying to reduce email was a dead end – there just isn’t enough control that a receiver has over the firehose. It’s a lot less effort to quickly scan the subjects and use mutt’s “delete thread key (Ctrl+D) gratuituously than trying to build a complex pattern of rules.
I’d love to hear about your ideas and experiences, too! Please refer me to your blogs, mail me, or prod me on Twitter.