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

Case Study: Working at the Extremes
In the spring of 2019, I taped an interview for The Rich Roll Podcast.
During the episode, we talked about some of the ideas explored in
this book. I mentioned that the agile methodologies popular among
software developers were an interesting example of a more
thoughtful alternative to the hyperactive hive mind workflow. A few
months later, soon after the episode was released, I received an old-
fashioned printed letter in the mail, delivered to my office at
Georgetown University. It was from a longtime Silicon Valley
programmer and executive named Greg Woodward. He mentioned
that he had just heard my interview with Roll and was particularly
interested in our discussion of agile methodologies. As he explained,
if I really wanted to understand the potential of optimized
workflows, I needed to learn about the small software start-up where

---

he was currently the CTO. They deployed a methodology that “takes
all of the agile practices and dials them up to a 10.” It was called,
appropriately enough, extreme programming—and it blew my mind.
Woodward began writing code and managing development
teams in Silicon Valley in the mid-1990s, after completing his PhD in
mechanical engineering at Stanford. His dissertation applied an
efficient style of algorithm to run physics simulations relevant to the
NASA space shuttle program. He remembers his first decade
working in software development, a period of lumbering waterfall
schedules and novel-thick feature specifications, as “frustrating.” In
2005, looking for a better way to write code, he managed to find a
job at Pivotal Labs, a company that had developed a reputation
among Silicon Valley insiders for its eccentric but outrageously
productive approach to software development. They called it extreme
programming, or XP for short. As Woodward explained to me, this
methodology is relentlessly optimized. “XP has taken all of the
software development best practices,” he said, “honed them
extensively, and then discarded anything that didn’t work.”
Woodward became a believer. After working with Pivotal for several
years, he brought the XP methodology with him to every company
he’s helped managed since.
Here are some (but not all) of the core ideas behind XP.
Programmers who are working on a big project are divided into
smaller development teams, typically consisting of no more than ten
individuals. In an era where remote work is increasingly common,
XP development teams work in the same physical room, where face-
to-face communication is prioritized over digital alternatives. “We
rarely check email throughout the day,” Woodward told me,
discussing the development team he currently manages. “Sometimes
my developers will literally go days without checking emails.” If you
need something from someone else on your team, you wait until they
look like they’re at a natural stopping point and then walk over and
ask them. Woodward describes these conversations as “one hundred
times more efficient than email.”
One complaint I’ve heard from many software developers is that
they’re often bothered electronically by people outside their team,
such as members of the marketing department, or customers—
leading to constant interruptions that pull them away from their
primary work of making great software. I asked Woodward how XP

---

handled these distractions. “The project manager serves as the
liaison to the rest of the company and customers,” he explained.
“[These outsiders are] trained to funnel their feature requests, bug
reports, and so on through the project manager. . . . The
development team is shielded.” The project manager places any tasks
extracted from these interactions into a priority queue. The team
works on tasks from the queue one at a time, deciding after each task
is complete which they should tackle next.
One of the more extreme elements of XP is its commitment to
what’s known as pair programming. XP developers work in groups of
two that share a computer. “Unenlightened managers would think
that you would get fifty percent of the productivity with two
developers working on the same thing at the same computer,”
Woodward explained. “In actuality, you get three to four times more
productivity.” As he elaborated, the crucial step in programming is
not the actual act of mechanically typing commands into a computer,
but instead crafting the underlying solution that is then translated
into code. When you work with another person, you can push back
on each other’s ideas—finding flaws and coming up with new angles
that might work better.
To illustrate this concept, Woodward gave me a recent example
that had occurred a couple of weeks before our conversation. At the
time, he explained, he had an idea for a software feature that would
provide a “big performance boost.” He was thinking about the idea
on his commute into his San Francisco office. “By the time I got into
work, I thought I had the strategy for implementing the feature
pretty much all figured out.” Woodward sat down with his pair
programming partner for the day and began explaining his idea.
They discussed it for forty-five minutes. During the conversation, his