|
Nonpersonal Email Protocols
Some aspects of our daily lives become so familiar that we have a
hard time imagining an alternative ever existing. One such example
of this effect is the canonical format of email addresses:
person@organization. There’s an elegance to this structure. When
you send an email, the underlying email protocol routes the message
to the organization specified in the address. Once there, the
organization’s email server delivers the message to the specific
recipient on the left side of the @ symbol. It’s this element of the
email address, the recipient field, that we take for granted. But if we
step back and examine it from a fresh perspective, an intriguing
question emerges: Why are the recipients in email addresses almost
always people, and not, for example, departments, projects, or
activities?
The historical answer to this question can be traced to one of the
earliest proto-email systems. In the early 1960s, computers were still
large and expensive mainframes that required dedicated rooms and
maintenance staffs. To use these machines meant waiting your turn,
at which point you would temporarily be given full control of the
digital behemoth, hoping it would compute your program, likely
inputted as punch cards, before your turn expired. Engineers at MIT,
frustrated by this setup, figured there must be a better way to divvy
up mainframe access. Their solution, launched in the MIT
Computation Center in 1961, was called the Compatible Time-
Sharing System (CTSS). And it introduced something revolutionary
into the world of computing: the ability for multiple users to log in to
the same mainframe at the same time using terminal machines
hardwired to the mainframe. These users weren’t literally controlling
the computer simultaneously; instead, the time-sharing operating
system running on the big machine would switch rapidly between the
different users, doing a little computation for one user before
switching over to do some computation for another, and so on. But
from the perspective of the users, it truly felt to each as if they had
the mainframe all to themselves.
The jump from CTSS to email was natural. One of the features
time-sharing introduced was the idea that each user account had its
own directory containing its own files, some private and some
accessible to everyone else on the system. Clever early users of CTSS
realized they could leave messages in one another’s directories. By
1965, this behavior was standardized with the MAIL command,
implemented by software engineers Tom Van Vleck and Noel Morris.
It placed a file called “MAIL BOX” in each user’s directory. When you
sent a message to a specific user with the MAIL command, the note
was appended to that user’s MAIL BOX file. People could use the tool
to read and delete messages in their own MAIL BOX files.
The very earliest email accounts were associated with individual
people, in other words, because the user accounts for mainframe
time-sharing systems were originally set up in this way. Once this
connection was made, it stuck. Ray Tomlinson, the engineer perhaps
most responsible for the person@organization address format that
later became standard, had previously worked on more advanced
versions of time-sharing messaging tools like MAIL.
17
—
This arbitrary and seemingly innocent decision to associate email
with individuals ended up playing a role in the rise of the hyperactive
hive mind workflow. As argued in part 1 of this book, the hive mind
scales up the natural way we have always coordinated in small
groups: unstructured, ad hoc, back-and-forth chatter. Because email
addresses are associated with people, it was easy to deploy this tool
to support this type of conversation, starting us down the slippery
slope that eventually led to uncontrolled messaging. In an alternative
universe where email addresses were instead tied to projects or
teams, the hive mind workflow might have felt much less natural,
and therefore might have had a harder time gaining traction.
The point of detailing this history is to encourage you to consider
breaking the convention of associating email addresses with
individuals, especially when seeking out efficient communication
protocols. By eliminating this connection between email and people,
you will, with one grand gesture, destabilize everyone’s expectations
about how communication should unfold, making it much easier for
you to rebuild these expectations from scratch with a protocol that
makes more sense.
Consider, for example, the client communication protocols
discussed in this chapter. When a client is used to contacting a
specific individual in your organization when they have questions or
issues, it might be hard to diminish their expectation of quick
responses. They will personalize these interactions and begin
treating delays as a personal affront (why are you ignoring me?!).
Now imagine instead that each client is assigned a dedicated email
address of the form clientname@yourorganization.com. It’s now
much easier to break them from the idea that their messages are
going to an individual person, who is seeing them right away and
therefore better answer them quickly! By depersonalizing
communication, you have many more options to optimize it.
I deployed protocols based on these ideas to help manage my
author communication. When I used to offer only a single email
address for readers to reach me, associated with my name, the
messages became overwhelming: not in just their volume but also
their complexity. When you think you’re interacting with an
individual, it’s natural to assume that they’ll be reasonable enough to
read your long story and offer detailed advice, or set up a call to talk
about your business opportunity, or connect you to relevant people
in their network. I used to do this gladly, but as my audience grew it
became more difficult.
To improve my author communication protocols, I introduced
nonpersonal email addresses. One of these, for example, is
interesting @calnewport.com, which my readers use to send
interesting links or leads. Below the address is a simple note: “I really
appreciate these pointers, but due to time constraints, I’m usually
not able to respond.” In my experience, if you put such a disclaimer
next to a personalized address, like cal@calnewport.com, it will be
widely disregarded, as our expectations for one-on-one interactions
are so strong. But when the disclaimer appends a nonpersonal
address, like interesting@calnew port.com, I receive few complaints
—without preconceived expectations, you’re able to set them from
scratch.
There are many different ways to build low-cost protocols into
your professional life or organization, but in many cases, freeing
email addresses from individuals provides a powerful boost to these
efforts.
Do'stlaringiz bilan baham: |
