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

problem. Imagine that each machine in a distributed system starts
an operation, such as entering a transaction into a database, with an
initial preference to either proceed or abort. The goal is for these
machines to reach a consensus—either all agreeing to proceed or all
agreeing to abort.
The simplest solution is for each machine to gather the
preferences of its peers and then apply some fixed rule—for example,
counting the votes to determine a winner—to decide which
preference to adopt. If all the machines gather the same set of votes,
they will all adopt the same decision. The problem is that some of the
machines might crash before they vote. If that happens, the rest of
the group will end up waiting forever to hear from peers that are no
longer operating. Because delays are unpredictable in an
asynchronous system, the waiting peers don’t know when they
should give up and move on with the votes they’ve already gathered.
At first, to the engineers who studied this problem, it seemed
obvious that instead of waiting to learn the preference of every
machine, one could just wait to hear from most of them. Imagine, for
example, the following rule: if I hear from most machines, and they
all want to proceed, then I’ll decide to proceed; otherwise I’ll default
to abort, just to be safe. At first glance, this rule seems like it should
lead to a consensus, so long as only a small number of machines die.
And yet, to the surprise of many people in the field, in a 1985 paper,
three computer scientists—Michael Fischer, Nancy Lynch (my
doctoral adviser), and Michael Paterson—proved, through a virtuosic
display of mathematical logic, that in an asynchronous system, no
distributed algorithm could guarantee that a consensus would always
be reached, even if it was sure that at most a single computer might
crash.
20
The details of this result are technical,
21
 but its impact on
distributed systems was obvious. It made it clear that asynchronous

---

communication complicates attempts to coordinate, and therefore,
it’s almost always worth the extra cost required to introduce more
synchrony. In the context of distributed systems, the added
synchrony explored in the aftermath of this famous 1985 paper took
several forms. One heavy-handed solution, used in some early fly-by-
wire systems and fault-tolerant credit card transaction processing
machines, was to connect the machines on a common electrical
circuit, allowing them to operate at the same lockstep pace. This
approach eliminates unpredictable communication delays and allows
your application to immediately detect if a machine has crashed.
Because these circuits were sometimes complicated to
implement, software approaches to adding synchrony also became
popular. By leveraging knowledge about message delays and
processor speeds, it turns out that it’s possible to write programs that
structure communication into well-behaved rounds, or simulate
reliable machines that can help synchronize the actual unreliable
machines participating in the system.
This fight against asynchrony ended up playing a crucial role in
the rise of the internet age, enabling, among other innovations, the
software driving the huge data centers run by such companies as
Amazon, Facebook, and Google. In 2013, Leslie Lamport, a major
figure in the field of distributed systems, was given the A. M. Turing
Award—the highest distinction in computer science—for his work on
algorithms that help synchronize distributed systems.
22
What’s striking about these technical results on asynchrony
versus synchrony is how much they diverge from the conclusions of
the business thinkers tackling these same issues in the workplace. As
we’ve learned, managers in office settings fixated on eliminating the
overhead of synchronous communication—the annoyance of phone
tag or taking the elevator to a different floor to chat with someone in
person. They believed that eliminating this overhead using tools like
email would make collaboration more efficient. Computer scientists,
meanwhile, came to the opposite conclusion. Investigating
asynchronous communication from the perspective of algorithm
theory, they discovered that spreading out communication with
unpredictable delays introduced tricky new complexities. While the
business world came to see synchrony as an obstacle to overcome,
computer theorists began to realize that it was fundamental for
effective collaboration.

---

People are different from computers, but many of the forces that
complicate the design of asynchronous distributed systems loosely
apply to humans attempting to collaborate in the office. Synchrony
might be expensive to arrange—both in the office setting and in
computer systems—but trying to coordinate in its absence is also
expensive. This reality summarizes well what many experienced as
office communication shifted to email: they traded the pain of phone
tag, scribbled notes, and endless meetings for the pain of a
surprisingly large volume of ambiguous electronic messages passed
back and forth throughout the day. As the engineers discovered when
they tried to coax their networked computers into reaching a
consensus, asynchrony is not just synchrony spread out; it instead
introduces its own difficulties. A problem that might have been
solvable in a few minutes of real-time interaction in a meeting room
or on the phone might now generate dozens of messages, and even
then might still fail to converge on a satisfactory conclusion. It’s
possible, in other words, that once you move your workplace toward
this style of communication, the hyperactive property of the
hyperactive hive mind workflow becomes unavoidable.
Hive Mind Driver #2: The Cycle of Responsiveness
Harvard Business School professor Leslie Perlow is an expert in the
culture of constant connectivity that dominates the modern
workplace. As she recounts in her 2012 book, Sleeping with Your