Why Multitasking Is Unproductive and What to Do Instead
ashleyjanssen.com
ashleyjanssen.com
For example, if you are mostly providing informative responses to things in chat, it makes sense to talk to lots of people at once. Replies come in at a certain rate, and your ability to write messages can serve the demand even if degraded by half.
If you are using the chats to put out orders or requests, you may find that the asynchronicity of communication allows you to receive the results of those requests (e.g. items shipped out) before a cut off time.
Pretty much anything that can be queued, and that "blocks" a lot, imo, is a good candidate for multitasking.
Anecdotally, it does not cost me a particularly large amount of mental overhead to switch between tasks. This is further reduced if I keep a "container" for a small task like an idle conversation, so that it doesn't litter the memory space of my primary task. The performance impact, minus time spent on the other task, is probably <20%, and I'm happy to throw that out if it either makes the task more fun, or decreases latency on something else.
If a sub-problem comes up, I might literally push the first sheet down on the stack, "open up" a new sheet, and then pop that off the stack when done, returning me to the previous sheet.
This tends to merge smoothly with what the article describes as the Ivy-Lee method, so far as having a context to refer to capturing larger tasks for a [next] day.
1. Time-blocking 2. Ready-to-resume plan 3. The Ivy-Lee method
I was familiar with time blocking, and in general familiar with ideas behind "ready-to-resume", but not Ivy-Lee, which looks attractive. In particular, I liked this because it also has a decision-fatigue reduction component.