A World Without Email: Reimagining Work in an Age of Communication Overload by Cal Newport, March 2021

I was surprised to enjoy this book so much, because I actually like email a lot. Certainly, I much prefer it to instant messaging or text messages.

The thing is, the title of this book is really misleading. It is not actually about email. Instead, it is about a dysfunctional process (or an absence of process) in the modern workplace, and how email has helped cultivate it and continues to enable it.

Cal Newport uses the term The Hyperactive Hive Mind to describe this. What it means is that instead of careful and deliberate advance planning, more tasks now tend to be coordinated via ad-hoc messages back and forth between team members, managers and other stakeholders.

Apparently this happens over email in many teams. I feel grateful for not having experienced that myself. As a software developer it is second nature to use a kanban board or other project management tools to plan projects and individual tasks. I can’t even imagine working without such tools, but many do, at least in other professions. In fact, on of the major points of the book is that we should be using things like Trello instead of just coordinating our work via email threads.

To me, the choice of Email, Slack, Trello or Jira is not what’s interesting about this book. Much more relevant to me is how we have come to accept starting a work task based on incomplete information, knowing that we can just obtain this information as we go along.

It’s simply too easy to ask when unsure. This is true for any modern communications platform, although they’re certainly not all created equal. Project tools like Trello, Clubhouse or Twist at least keep things organised by topic. Slack and Email invite unstructured back-and-forth with only the channel or subject line to organise the information.

There’s a clear line back to the discussions we had early in my career where Scrum was really gaining traction in the software development world. One of the key points was that nobody should start working on a task until it is Ready. Meaning that it is actually known what needs to be done, start to finish. As I recall, this was one of the most important rules, second only to the rule about not interrupting a team when it is in a Sprint.

This fits perfectly with the message in the book. The terminology is different, but the point remains the same: Plan ahead and make sure the task is ready. And once you start working, don’t let yourself get interrupted. While Scrum focused entirely on teams, Cal Newport makes the point that this principle is equally applicable for individuals.

–

While reading the book I often thought about how I structure my time, and how we as a team organize our work (I work in the 9-person product team at GoMore, a p2p car sharing platform).

As all other product teams, we have a huge backlog of small and big features we’d like to get done. But as we have matured as a team, we have become increasingly aware that it is not efficient to just pick something and get started. Tempting as it often is.

It is possible for sure, and sometimes it feels easy in the beginning. Assemble a small group (designer, frontend, backend, iOS, Android) and get started after a short kickoff meeting. We know what we want to build, let’s just figure out the details as we go.

Is that a good approach? Let’s say I start working and get stuck with my work after half a day because I’m unsure of how to handle some edge case. What are the costs?

First, I need to disturb someone with my question, usually our CPO. Let’s say I shoot him an email (in honor of the book…in reality I’ll probably be impatient and DM him on Slack instead).

But then what?? I need to figure out what to do now that I’m blocked. So I have to context switch, probably picking up a support ticket or a small task from our “pool” of minor things to work on. If I’m lucky there is something within the same project I can pickup to stay in the same place mentally.

I don’t know when I can get back to the project I should be working on, because I don’t know when I’ll get an answer from my CPO. So I don’t know how much time I have. Maybe I’ll have to tread waters for the rest of the day.

Worst case, I didn’t phrase the question clearly enough and I get a clarifying question in return a few hours later.

It is pretty obvious that this is not a great way to work, but it’s not at all uncommon. Whenever someone is working on a problem and they shoot you a “quick question” on Slack, you should probably both pause and consider how this could have been avoided. It’s not that I want to avoid human interaction, although it may come across that way. But as much as I want to be a helpful team player, I’d much rather spend my time pairing on actually challenging issues or on creating product value myself, rather than answering questions that we should (as a team) have thought of earlier.

So for any project, we should do our best to identify as many unknowns upfront and find answers that everyone working on the project can familiarise themselves with. Knowledge should be spread from a single source of truth, not distributed ad-hoc.

On our team, we try to achieve this by starting any new feature work with a Feature Brief, which is simply a Google doc, usually 1-3 pages long.

It first describes the motivation for the feature in a few sentences. This is just useful as background and may inspire questions and critique.

Then the most important section: The lists of must have and should have changes to the product. This describes exactly what we want to change, divided into a mandatory part that must be completed for the feature to make sense, and an optional part that we can tackle as time permits.

As we think about the new feature (before working on it), we come up with questions and fill in more detailed information on these items. Often, this extra information is about edge cases or conflicts with existing items.

For example: A “must-have” of a new feature is that the renter pays a 25% cancellation fee on late cancellation of a car rental. But what if a 15% coupon discount was applied to the purchase? Is the coupon still spent or do we charge the entire fee from the credit card payment? Also, should loyalty points still be earned from the 25% of the payment we keep? There are tons of details that we just don’t notice until we’ve spent significant time thinking about the project.

Also, very importantly, the Brief contains a section for Unknowns. So we make it explicit what we do not yet know and need to clarify before we can finish the project. We often use comments in the document to keep track of who is working on clarifying these unknowns at any given time.

Finally there’s a Notes section with non-essential background information that is just good to know for anyone working on the project.

We sometimes color code text by status. Orange for in-progress and green for done.

The Feature Brief is the single most important document when working on a new feature. It’s short enough to never be overwhelming, but at the same time it must (by definition) capture everything essential about the new feature. The Brief links to external documents like designs and the project board containing the lower-level “stories” for each technical change we need to make in a codebase.

–

This turned into more than a book review. Which goes to show why I liked the book so much. It made me realise what we do right on our team, and why. And perhaps what we can do even better.

I highly recommend this book, even if you’re like me and secretly like email. Again, it’s not about email, it’s about how messaging is used in a team. And of course, since I went on a tangent and started writing about software development, I only touched on a single aspect of the book. It contains many more valuable insights and is quite well-written.

Rating: 5/5