Write Your Own E-mail Protocols

If you study the transcripts of most e-mail threads, the back and forth messaging will reveal a highly inefficient process for accomplishing the thread’s goal.

There’s a simple explanation for this reality. When most people (myself included) check e-mail, we’re often optimizing the wrong metric: the speed with which you clear messages.

Boosting this metric feels good in the moment — as if you’re really accomplishing something — but the side effect is ambiguous and minimally useful message that cause the threads to persist much longer than necessary, devouring your time and attention along the way.

I’m as guilty of this as anyone. For example, look at this terrible reply to a meeting request that I actually sent not long ago:

I’m definitely game to catch up this week.

Ugh. As I sent the above I knew that in the interest of replying as quickly as possible, I probably tripled the number of messages required before this meeting came to fruition.

E-mail Protocols

What’s the solution?

Here’s a tactic that I’ve sporadically toyed with and that seems to work well: when starting or first replying to an e-mail thread, include in your message a “protocol” which identifies the goal of the thread and outlines an efficient process for accomplishing the goal (where “efficient” usually means a process that minimizes the total number of e-mails sent).

Consider, for example, the following improved version of my above response:

I’m definitely game to catch up this week. See below…
—–
Here are three time and date combinations that work for me to talk this week. If any of these three work for you, choose one: I’ll consider your reply a confirmation of the call. You can reach me then at <number>.

If none of these work, reply with a few combinations that do work, and I’ll choose one.

Option #1: <date and time>

Option #2: <date and time>

Option #3: <date and time>

Notice the format of this message. It opens with the normal informal tone that people expect from e-mail, and then segregates the more systematic protocol portion under a dividing line. In this case, the sample protocol is designed to reduce the thread to two e-mail messages if at all possible.

Pros and Cons

The hard part about this strategy is that it takes a little more time to craft each of your messages. It returns, however, two important benefits…

The first benefit is obvious: a well-designed protocol will reduce the number of e-mails you send and receive, and therefore reduce the overall time you spend tending your inbox (even if the messages you do send take slightly longer to write).

The second benefit is less obvious in the abstract but clear in practice: you feel less stress. When you fire off a quick and ambiguous e-mail, your mind knows the related project is still open, and therefore it will reserve some mental space to keep worrying about it.

If you instead identify the relevant goal and lay out a clear process for accomplishing it, your mind believes things are handled, and it’s more willing to let it go.

I know it sounds weird, but it’s true: including protocols in your e-mail, though somewhat clunky and artificial, really does reduce the grip your inbox has on your mood and attention.

I don’t use this strategy nearly as much as I should, but whenever I do, it works wonders for me. If your inbox is frustrating you, it’s worth experimenting with. I’ll be interested to hear about your experience.