A world Without Email: Reimagining Work in an Age of Communication Overload

The Protocol Principle
The Invention of Information
Claude Shannon is one of the most important figures in twentieth-
century science, yet few outside the specialized fields he helped
innovate know his name. Perhaps his largest intellectual leap was his
1937 MIT master’s thesis, which he submitted at the age of twenty-
one and, among other contributions, laid the foundation for all of
digital electronics.
1
But it’s toward another of his most famous works
that I’ll turn our attention now, as it will prove useful in our quest to
move beyond the hyperactive hive mind workflow. I’m talking about
Shannon’s invention of information.
To be more precise, Shannon wasn’t the first person to talk
carefully about information or to try to quantify it. But his 1948
paper, “A Mathematical Theory of Communication,” established a
framework called information theory that fixed the flaws of earlier
attempts to study this topic formally and provided the tools that
ended up making the modern digital communication revolution
possible. Underlying this framework is a simple but profound idea:
by adding complexity to the rules we use to structure our
communication, the actual amount of information required by the
interactions can be reduced. In this chapter, I’ll adapt this principle
to workplace communication, arguing that by spending more time in
advance setting up the rules by which we coordinate in the office
(what I’ll call protocols), we can reduce the effort required to
accomplish this coordination in the moment—allowing work to
unfold much more efficiently. Before we elaborate this claim further,
however, we must make a brief diversion to better understand
Shannon’s transformative insight.
2

---

—
Shannon developed his groundbreaking work on communication
while he was a scientist at Bell Labs in the 1940s. Building on the
earlier efforts of fellow Bell Labs scientist Ralph Hartley, Shannon
began by stripping away any notion of the “meaning” conveyed by
information. In his framework the challenge is more abstract. A
sender wants to transmit a message from a set of possible messages
to a receiver by sending symbols from a fixed alphabet over a
channel. The goal is for the receiver to identify which message from
the original set the sender had in mind. (Shannon also added the
possibility of noise on the channel that can corrupt some of the
symbols, but we’ll put that aside for now.) To keep things as clear as
possible, Shannon further simplified the symbol alphabet to just two
possibilities: a zero or a one. Putting this all together, in this
framework, communication is reduced to the following game: a
sender chooses a message from a well-known set of possible
messages and transmits a sequence of zeros and ones over a channel
monitored by the receiver, who then attempts to identify the
message.
Before Shannon, Ralph Hartley had already identified something
roughly like this setup as the right way to think about transmitting
information. But Shannon added a twist: in many cases, a sender
might be more likely to choose some messages than others, and this
might help the sender communicate using fewer symbols on average.
Imagine, for example, that a sender is transmitting letters from the
English alphabet as part of a longer message. If the first two letters
sent are “t” and “h,” then this severely restricts which letter is likely
to be sent next. The probability, for example, that the sender will
next transmit “x” or “q” or “z” is zero. But the probability that the
sender is about to transmit “e” is quite high. (Like his better-known
British counterpart in the pantheon of computing pioneers, Alan
Turing, Shannon had done some work on code-breaking during
World War II, and therefore would have been familiar with the idea
that certain letters are more common than others.)
Shannon argued that in this case, when the sender and receiver
are trying to work out in advance the rules for how they will map
transmitted symbols to letters, the protocol
3
they come up with
should take into account these varying likelihoods, as this might

---

allow them, on average, to get away with using far fewer symbols to
communicate.
To make this idea more concrete, consider the following
scenario. You’re in charge of monitoring a meter that measures some
important piece of equipment. The meter has a dial with 256
different values that span from −127 to 128. The chief engineer wants
an update on the meter reading every ten minutes. Because she
works in a different building, you rig up a telegraph wire so that you
can communicate this information using a binary code of dots and
dashes, preventing you from having to go find her in person to
deliver each report.
For this scheme to work, you and the engineer must first agree
on a protocol for how you’ll encode the meter readings. The simplest
thing to do would be to map each of the 256 meter readings to a
unique sequence of dots and dashes. Perhaps, for example, a reading
of −127 is transmitted as dot-dot-dot-dot-dot-dot-dot-dot, while a
reading of 16 is transmitted as dash-dot-dash-dot-dot-dash-dash-
dot, and so on. Some simple math (2
8
= 256) tells us that there are
exactly 256 different sequences of eight dots and dashes, so you’ll be
able to assign a unique pattern to every possible meter reading.
This protocol would require you to send eight telegraph symbols
for each meter reading. But let’s say your goal is to minimize the
number of symbols you have to send, as the telegraph key is
annoying to use and hurts your hand. At this point, according to
Shannon, you should take into account the likelihood of the different
readings. In this scenario, let’s assume you know that the meter is
almost always going to read zero, as this is the normal operating
state of the machinery being monitored. If it reads something
different, this means there’s a problem, and problems are relatively
rare. To be more concrete, let’s say that you expect the meter to read
zero 99 percent of the time.
You and the engineer might now agree on the following more
nuanced protocol. If you send a single dot, this means the reading is
zero. If you send a dash, this means the reading is not zero and that
you’ll follow this dash with an eight-symbol pattern that maps to the
specific nonzero reading you’re measuring. Notice, with this new
protocol, in the worst case you are sending more symbols than the
simple protocol, as for a nonzero reading the new protocol requires
nine symbols to be sent (the dash followed by an eight-symbol

---

pattern), while the simple protocol always requires only eight
symbols. But in the best case, the new protocol requires only one
symbol, compared to eight for the simple alternative. How do you
compare the costs of these two scenarios? Shannon suggests you use
the specific probabilities to calculate an average cost. We calculate
the average number of symbols per message in our new protocol like
so: .99 × 1 + .01 × 9 = 1.08. In other words, if you average the
number of symbols you send per measurement over a long period of
time, it will work out that you’re sending only slightly more than one
symbol per message, making this new protocol massively more
efficient over time than the original protocol.
4
This was the central idea of Shannon’s information theory
framework: clever protocols that take into account the structure of
the information being communicated can perform much better than
naïve approaches. (This wasn’t the only contribution of information
theory. Shannon’s paper also showed how to calculate the best
possible performance for a given information source and
revolutionized the way engineers thought about reducing
interference from noise, making both high-speed electronic
communication and dense digital storage possible.
5
) Without these
insights, something as routine as downloading a movie from iTunes
might take multiple days instead of a handful of minutes, and the
images making up your Instagram feed might require an hour to
appear instead of just the seconds we’ve come to expect.
These same ideas apply beyond digital communication. Soon
after Shannon’s seminal 1948 paper began to spread, engineers and
scientists in a variety of fields recognized the general usefulness of
his framework. Information theory began popping up in many
contexts far separated from the world of digital files and computer
networking, from linguistics, to human vision, to the understanding
of life itself (biologists realized that DNA can be understood as an
efficient, Shannon-style information protocol). We will now add one
more area where Shannon’s framework provides insight:
coordination in the office.
—
In a standard work scenario, various parties need to communicate
with one another about various issues—agreeing on a time for a
meeting, determining the next step for a joint project, answering a

---

client question, providing feedback on an idea. These coordination
activities are structured by rules. Often these rules are implicit, in
that they capture norms that aren’t written down anywhere, and
sometimes they’re more formal. Consider, for example, a small
consulting firm that regularly receives requests from potential clients
that need to be evaluated to determine which are worth pursuing as
new business. If the firm embraces the hyperactive hive mind
workflow, then their implicit rule for deciding how to respond to
these requests is likely to just initiate an email conversation among
the relevant team members and hope to eventually arrive at a
conclusion. A more formal rule, by contrast, might be to hold a
meeting every Friday morning to go through that week’s requests as
a group and decide right then which ones to pursue and who will
take the lead. Whether implicit or formal, many office activities are
structured by some manner of rules. In honor of Shannon, let’s call
these collections of rules coordination protocols.
Shannon’s information theory framework teaches us that for a
given task, the protocol you choose matters, as some are costlier than
others. In classical information theory, the cost of a given protocol is
the average number of bits you need to transmit to complete the task
—as with our simple meter reading example from above, a protocol
that uses fewer bits on average is better than one that uses more.
When evaluating coordination protocols in the workplace, however,
we’ll need some more nuanced notions of cost.
We might measure cost, for example, in terms of cognitive
cycles, which describes the degree to which a protocol fragments
your attention. To be even more precise, we can follow the lead of the
RescueTime researchers discussed in part 1 and divide the workday
into five-minute buckets. To measure the cognitive cycle cost of a