"Read "A World Without Email" by Cal Newport"

Discussions - Public
1

@team If a book reading task sounds good to you, keep reading… :blue_book:

Based on a recommendation by @antoviaque, I’m going read A World Without Email by Cal Newport (the author of Deep Work). From what I can tell, it seems to give advice on how to avoid an inbox-driven workday and increase productivity.

If that sounds interesting to you, please read it too! It would be nice to get a conversation started here to hear everyone’s opinion on the book, as well as any points that particularly stood out.

Happy reading!

8 Likes
2

Hey @Ali this looks interesting, will give it a read. :slight_smile:

1 Like
3

This sounds great, I’m interested to read it. I’ve heard good things about ‘Deep Work’, so I may pick that up at the same time.

Does this mean we can log time spent reading the book? This could be a long time as it’s not a short text. :thinking:

1 Like
4

Hi Samuel!

@antoviaque Please confirm this for us:

Does this mean we can log time spent reading the book? This could be a long time as it’s not a short text. :thinking:

1 Like
5

Yup that’s a really nice book :) You might even recognize the inspiration behind some of my workflow changes lately ;p

For logging the time, it is a significant task and commitment, so I would limit it to people who are directly and actively involved on the Workflow manager epic work, since there it can be justified as research/discovery. For others, a task on the learning epic can also be considered - but that would be on a cell budget, so something to clear out with your cell’s sustainability manager.

Btw @Ali would it be ok to make this thread public?

6

@antoviaque Sure! I’ve made the post public and have removed the link to the Jira ticket. Thanks for clearing up my confusion on who should log time for the reading the book. :)

7

@anon46505572 Just a heads up in case you missed Xavier’s response here…

8

Thanks @Ali

Yep that makes perfect sense.

I’d be interested to read it on my own time anyway, since it sounds useful in general. Would OpenCraft be interested in covering the cost of the book for those who wish to read it?

9

Hi @anon46505572. I’m going to hand your question over to Xavier. @antoviaque Please will you weigh in here?

10

@anon46505572 Yup, that sounds fair – if you buy it, just send the receipt to @gabriel and he can add it on your next invoice. Also even for covering the time reading it (or anything related to learning in general) the option I was mentioning is definitely available, though it requires to balance the need against other cell budgets:

a task on the learning epic can also be considered - but that would be on a cell budget, so something to clear out with your cell’s sustainability manager.

Btw, for those who will read it, it might be worth keeping in mind what I said in the related UX discovery document about it https://gitlab.com/opencraft/dev/workflow-manager/-/merge_requests/8#note_547930069 :

I don’t follow all his conclusions – for example, he is a bit quick to dismiss async work and replace it with synchronous meetings - async is more complex to get right, but also allows more parallelized deep work when it is done right. But given how much of the rest of the book applies well to what we are discussing, it has many good points worth considering from our async angle.

2 Likes
11

I’ve just finished the book. I found it fascinating.

Like @antoviaque, I agree that Newport is too quick to suggest synchronous meetings (it might just be a personal thing, but I find that meetings really disrupt my work day). However, I agree with pretty much everything else he had to say.

One of the sections I liked most was Newport’s exploration of the way in which our brains are wired to work. He argues that our brains aren’t designed to manage the type of workflows that constant digital communication creates (he calls this the “hyperactive hive mind”). He believes that the disconnect between how our brains are designed, and how they are being forced to function, leads to anxiety and difficulty concentrating.

While reading this, I realised that he was describing exactly what I experience from time to time. Being able to pinpoint the things that trigger my anxiety makes it that much easier to deal with. The quote below pretty much sums it up:

  • “This mismatch between how we’re wired to communicate and how we’re coerced into communicating by modern technology creates a deeply human sense of frustration.”
    (Cal Newport)

This part of the book also made me realise that I might be causing anxiety for others too! By sending unnecessary messages, or pinging people when they don’t really need to be included in a conversation, I am probably contributing to their stress levels. This realisation has made me think twice before hitting the “@” button in a comment.

Here are a few other resources that Newport mentioned that I would still like to look into:

I hope you all enjoy the book as much as I did! :nerd_face:

5 Likes
12

I’m being onboarded as the new reviewer for the Workflow manager epic. As part of this, I went ahead and read the book, too.

I think Newport’s suggestions of meetings make a lot of sense, though they need to be contextualized (he made it pretty clear that meetings can be a big timewaster, and in fact are sometimes used to paper over work and give a sense of accomplishment.) Unfortunately even when well employed, they’re less useful in our case than for others.

A particular tricky lesson to pull from the book is that asynchronous communication methods, by default, tend to be inexpensive to send and expensive to respond to. They also encourage ‘always-on’ behavior where you’re paying attention to pings that will break your concentration, and feel distracted if you haven’t answered them. This distraction is deeply primal and has origins in our evolutionary history-- so it’s not something so readily ignored.

This causes a ‘tragedy of the attention commons’ where it’s very easy to break someone else’s concentration. Email acts as a ‘catch-all’ for coordination activities that have no formal intake and output processes. The net result is that everyone is unable to focus on real work because everyone is focusing pings.

This presents a unique problem for OpenCraft, as a company that is all remote. In fact it’s a problem that I imagine has gotten worse with time, as I’ve been around long enough to see how some things have changed.

We started by using Trello. Trello is highly celebrated in the book, and for good reason. The card-based method of organizing conversations, and being able to engage when you’re ready, helped a great deal in cutting down the amount of asynchronous chatter. As I recall, we switched to Jira due to a few technological limitations, especially surrounding time tracking and billing.

Jira, however, sends far, far more emails. It’s also a tool that adds a lot of friction by trying to be everything and do too much at once.

Looking at the pain points in our process, a lot of them involve the back-and-forth through Jira as we plan sprints, and while I’m usually not involved directly in help@ and urgent@ email threads, I do find myself actively engaged in contact@ emails, which often aren’t tied to any specific ticket.

Reading this book leaves me full of ideas, some of which we’re not in a position to execute on any time soon, but which are fun to think about for long-term possibilities:

  1. Could we migrate our contact lists to a ticket system? One that can tie threads directly to tasks for us, and put the history right in our app, in a card, rather than piling up in our inboxes?
  2. We do have a policy of 24-hour turnaround for notifications from clients. How do we ensure that all items are responded to within their time limit without having a big inbox pile?
  3. Where are the key attachment points for plugins in the workflow software? This is important to consider-- because it will affect what patterns of automation we could potentially support.
  4. We’re trying to avoid building a giant monolith that does everything like Monday or Jira. But we do want to make several smaller apps that can work together. Doing so will likely remove a lot of context switching by providing oppportunities for automation. Are there particular workflows and interactions between the apps we want to consider? This is similar to point 3, but more concrete.

I’m also excited to work on this project. Not only is it a really cool problem to work on, it’s one that I’m certain I’ve already written a lot of software that may be useful for. To elaborate, Artconomy has a great deal of minutia-management that these apps are going to need. Rather than writing it all from scratch, it would likely be cheaper for me to port this code, add documentation, and turn it into libraries our apps can use. So I look forward to that possibility. Some of the things include the websocket code, the form and state handling, notifications system, and potentially even the financial calculations. I already know that the unique shortcode handling function will be useful, and that one’s a library that’s already ‘ready to go’ here.

7 Likes
13

@Fox Glad to read you’re onboarding to this epic – and looking forward to your work and thought on this. I think you’ve described some of the main challenges pretty well.

1 Like