I'm halfway through Cal Newport's latest book A World Without Email. In recent years, I have grown acutely aware of the cognitive drain that derives from email. I thought I would share some thoughts on email in the knowledge work place.
Two of my major problems with email are that it's a) a noisy channel; b) prone to information duplication. In spite of this, many workplaces (especially universities), treat email as an infinitely flexible system for information management. As Newport is fond of pointing out, your inbox is full of undifferentiated information coming at you and it can be hard to keep focus on a project of any scale (even a mindless administrative task) when you need to rely on your inbox for information storage and retrieval. Trying to single-task on something that then requires you to reference an email can be surprisingly detrimental: just venturing into your inbox and seeing a few new messages awaiting your attention is enough to trigger unmanaged open loops that will create a drag on your attention. Not to mention the willpower resources you might need to use just to keep yourself from reading those messages. "Just a check" can be an alluring but ultimately self-destructive thing. Add to that the fact that email services and clients vary in the quality of their search tools and displaying threaded messages; threads can bury mission-critical data quite quickly and you can find yourself wading through a mess of stuff before you find the info you need, especially if you don't keep up with some kind of sensible foldering system (I suspect most don't). That brings me to the second problem: workflows that rely on email and documents embedded therein are prone data duplication. As anyone in computer science knows, this is often a terrible way to design software. Mission-critical data should live as a single copy with highly structured read/write privileges. You don't update it by creating new copies of it (unless those back versions are themselves important). It should be accessed via a link (pointer) or interface. Popular software version control systems like Git are designed around keeping a working copy at the front of the queue (back-versions that might be worth referring to later live deep inside the history and can be called upon only when needed). So, better workflows designed around keeping up to date with a workflow that itself could be changing would be better off moving their data into a web page accessed via a link. Perhaps if the workflow is changed, users could receive an email with a change log or similar update, but regardless of where we are in the process, the same link should access the same data. This way, you never have to sift through a pile of emails, encounter a distracting "urgent email" (that believes it must be done right now) while you're trying to focus on the core mission such as grading undergraduate research projects.
0 Comments
Leave a Reply. |
Martin d brazeauPalaeontologist, fieldworker, sometimes phylogenetic programmer. Transplanted Canadian in UK. All views are my own. How to pronounce my name? Rhymes with "bureau" or "chateau". He/him/his. Archives
December 2022
Categories
All
|