Everyone knows about the terribly boring and ineffective meeting that should have been an email, but… Should it really have been an email? I’m not so sure. I think email in the workplace was fine when that was all we had, but that form of communication has outlived its usefulness and should mostly be replaced by other mediums. There, I said it.
Emails are traditionally used for 3 main purposes:
Announcements
This type of email is meant to deliver information and a response is not expected or required. It can include some call to action, but usually that action is optional (e.g. if you find something wrong in the information part) or external to the email (e.g. fill out some form).
As far as anyone pays much attention to announcements, email is a perfectly good medium for this type of communication. It lands in everyone’s inbox and waits there until they read it or it gets buried under the constant stream of emails. The subject can easily signal to the recipient if they’ll find the content interesting and relevant or not, reducing cognitive load.
Personally, I pretty much ignore anything that doesn't have [Action Required] in its title. I don't even do Inbox Zero, I just periodically mark everything as read. If I missed something important - someone will let me know one way or another. And if no one does - well I guess it wasn't that important to begin with.
Personal communication
Emails can be used for personal communication, but its asynchronous nature and formal structure (subject, content, signature) makes it feel a bit impersonal. So while it’s great for introductions, I think for chat is better for personal communication in general, but also specifically for workplace communication.
While chat has the advantage of being asynchronous, it does have a synchronous mode – once both parties are available at the same time, they can have a real-time conversation (that’s what the Alice is typing… is there for). Emojis and gifs and the absence of a strict structure makes it much closer to a face-to-face conversation. Email is far less conducive to this type of synchronous back and forth.
Discussions and decisions (D&D)
Some organizations rely heavily on email to get things done. In this usage pattern, they’ll send out a question and start a discussion over email. Typically, this type of email includes a short introduction with a description of the issue, a few points they want feedback on, and a call for action (let me know what you think).
This is where it gets messy and this is the type of communication I believe should be replaced by a collaborative document.
Common pitfalls in D&D emails
Splintered replies
Because an email is just a block of text, a person can only reply with another block of text. So, even if they’re only addressing to one point in the original email they have to respond to the whole thing. This sub-subject may require it’s own specific discussion, but it can’t be separated in anyway from other discussions on different points of the email.
Hey everyone! background background * Point A * Point B * Point C What do you think? Thanks, Alice >> Looks good to me! >> Thanks, Bob >>>> Question about B? >>>> Thanks, Carly >>>>>> Answer on Carly's question about B. >>>>>> Thanks, Alice >> Comment about A. And also B? >> Thanks, Daryl >>>>>>>> Good point about A! >>>>>>>> Thanks, Bob >> Have you though about D? >> Thanks, Ellen >>>> Point about A taken, already answered B above. >>>> Thanks, Alice >>>>>> Oh sorry, missed that! >>>>>> Thanks, Daryl
This is a manufactured example without any real content, but you can see how a discussion like this can be hard to follow. Some questions or responses may be lost in the thread, and it’s hard to discuss a specific point without spamming everyone who may be interested only in some other aspect of the discussion.
The format may also cause issues in some cases: I’m not sure how this happens, but I’ve seen threads that somehow end up reversed like some kind of weird corporate Memento – the latest response appears at the top , which makes it quite difficult to get a coherent understanding of the discussion. Others get so deeply indented the content gets squashed into something entirely unreadable.
Double quotes
In order to avoid misunderstandings, responders often quote the specific point they are referring to, making constructing a response a frustrating exercise in copy-paste. Eventually people get tired of copy-pasting the whole thing (usually within two responses) and the original context is lost, making it even harder to understand the conversation.
Hey everyone! background background * Point A * Point B * Point C What do you think? Thanks, Alice >> Point A >> I think we should use approach X. >> Point B >> I think we should reconsider this and do Y instead. >> Thanks, Bob >>>> I think we should use approach X >>>> Sounds good to me. >>>> I think we should reconsider this and do Y instead. >>>> I disagree, this has been discussed before, we're sticking with B.
Derailing the conversation
Often, the first responder will ask about one or two points, and anyone who joins after that will only respond to what the first responder said. The original content will be lost and the conversation will focus only on a subset of the issues. It’s very hard to go back to the beginning and raise new issues and questions once the conversation has gone in another direction. See for example poor Ellen from the first email thread, who asked a question and no one even noticed.
Organizational Knowledge
While having an effective discussion is important, the above email ailments pale in comparison to the final and most important issue: Emails provide the illusion that a decision has been made and communicated.
The neverending story
At the most basic level, there is no way to effectively end an email thread. Even if there is a clear message at some point saying: This is the decision we’ve reached. Someone can always respond later with new questions, disagreement or even messages conveying support. There is no easily accessible and verifiable source of truth for the decision or its approval by relevant stakeholders.
Another side effect of the never ending stream of messages is that the decision may disappear somewhere in the middle of the thread. Good luck digging that up later.
Finding Nemo
Many messages are sent to specific people. That information is not accessible to anyone who was not on the original thread unless someone forwarded it to them. This specific problem can be solved by sending the message to some form of group (e.g. a Google group, Slack channel, Microsoft have their own version of this in Teams) but that may cause spam for many irrelevant people, or worse – having those irrelevant people chime in, adding to the general noise. Not to mention, anyone searching for this information will have to wade through a long back-and-forth of email messages to try and figure out what the bottom line was.
Most of these issues will occur in other conversation mediums as well (e.g. chat). The only advantage some of the other mediums have over email is that they're usually editable. So even if the rest of the post doesn't convince you this type of discussion should be moved to a collaborative document - do yourself a favor and use a medium that allows editing messages. When the conversation is over, update the final decision in the first message for future reference.
Recap
Emails are ineffective for anything but the most trivial discussion, and is inconvenient for uncovering the resulting decision at a later time. This means the organizational knowledge is effectively lost.
Use a document instead
Instead of sending out an email, write a block with the same basic elements you’d have in an email.
Date for historical reference, subject for context. Relevant background, content and call to action.
In this replication of the original discussion we can see the following improvements over an email:
Comments
Since comments refer to a specific section of the text, we no longer see splintered replies or double quotes. In addition, no single commenter can derail the conversation because the original text is still clearly visible and continues to be the main anchor of the discussion.
When Daryl selects point B to ask his question, he will immediately see that Carly already asked that question, eliminating unnecessary repitition.
Ellen has no appropriate anchor for her question, but she can still get her question seen and answered by commenting on some hard to miss unused real-estate.
Approval
Once the discussion is over, each stakeholder must explicitly state they’ve reviewed the content by checking their box. In some collaborative documents users can be tagged and they will be notified that they have an assigned task waiting for them. Some even include reminders that will continue to nudge the assigned users until they complete the review (i.e. check the box).
Total recall
After the comments have all been answered and the review completed, Alice can tidy up by resolving the comment threads and updating the text to reflect the important points and final decision. If anyone wants to see how the decision was reached, the comments and edit history are available in previous revisions of the document. For everyone else, the main points and final decision are easily accessible.
To ensure the information is available to whoever needs it, the document should be kept in an accessible and searchable location. This means its permissions should be set to the widest appropriate audience, preferably a group and not specific individuals.
If, at a later time, the information in this document becomes obsolete – it’s best to update it to reflect that or even archive it. Don’t delete it! It’s important to keep the historical context. Just make sure it’s clear the information is no longer up-do-date.
[Action Required]
Since task assignments may also get lost in the constant stream of notifications, I do recommend calling the attention of required approvers via chat or email. Be careful not to duplicate the content from the document, just give the subject and a link so they can complete the discussion and review in the document and nowhere else.
One document to rule them all
Some heavy weight processes like design reviews are already carried out in documents. However, if you start opening a document for each minor discussion, you’re going to end up with a lot of documents, which can become rather hard to follow. It’s still better than email, don’t get me wrong, especially if you keep them all in the same folder. However, there is a better way to keep all that knowledge under control.
The Pensieve (or: Project Log)
In the Harry Potter Wizarding World, a Pensieve is a magical basin where one can store their memories and enables the owner to examine and sort through thoughts and ideas.
Each project should have their own Pensieve document where they store all those one-off, relatively scoped discussions and meeting notes. If spontaneous discussions did happen via email or chat – they should be summarized and copied into the Pensieve. This creates a single location which can be relied on to contain all the little things that will need to be referenced later, but don’t really deserve a document of their own.
If you maintain some kind of page or index as the main entry point for each project which contains all the project information like design docs and product specs (which I think is a good practice), you should link to the Pensieve from there, as it’s an important piece of the project.
The name Pensieve was suggested by one of my Twitter followers, and I think it's genius. Unfortunately, it's been a tough idea to sell and I've seen several teams who've adopted the idea (yay!) calling their Pensieve a Project Log. I've started doing the same, so I guess you can't argue with success.
Illustration
This is how I suggest you structure your Pensieve, but it’s entirely up to you how to manage it. You might want to add team meetings, retros, on-call hand-offs etc. in the same document – or not. You may have some advanced documentation framework that enables creating an effective Pensieve in some other structure other than a single document. Experiment with the tools you have and see what works for you.
✏️ Our Project Log ✏️ Welcome! This document is meant to be the “hive mind” of Our Project. It will help us make decisions effectively and preserve a collective memory of why and how those decisions were made. [Important link] [Important link] Feb 14, 2022 | Product sync meeting notes Attendees: @Alice, @Bob, @Carly, @Daryl, @Ellen Summary: * Point A * Point B AIs [] @Bob to clarify X [] @Carly to finish-up Y Feb 10, 2022 | Rollout plan decision Slack discussion summary We've decided to start rollout at 5% on Feb 15th, increase to 20% the following week, and if all goes well - GA by Feb 28th. The feature is opt-in and we feel the risk of a fast rollout is low. Jan 31, 2022 | Copy adjustments The copy in user flow Z is confusing, we think it should be changed to have a clearer call to action. Suggestion: #1 Start now! #2 Begin free trial #3 Activate! Please vote on your preferred option! [] @Bob [] @Daryl [] @Alice Jan 15, 2022 | M1 status update We are on track for M1 GA at the end of the month. Task 1 - done Task 2 - done Task 3 - in progress Task 4 - done Task 5 - not started
I know this is a major change from how most of us do things, but I hope I managed to convince you why a collaborative document is a better and more effective way to discuss and decide, as well as preserve organizational knowledge.
I don’t usually end posts with a call to action, but in this case I’m quite curious and excited for you to share examples of what you’ve done with these ideas.