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

Cards in Columns: The Task Board Revolution
An executive whom I’ll call Alex runs a fifteen-person team that
operates like an independent start-up within a major national
healthcare provider. His team focuses on data analysis. If, for
example, you’re a researcher working for this provider, and you win a
grant that requires you to perform some complicated number
crunching, Alex’s team can build you the tools you need. They also
implement internal projects that help the provider run more
efficiently, even spinning off some of these solutions as standalone
software products. Given these various roles, Alex, as you might
expect, has to juggle many different demands on his team’s time.
A big part of how he pulls off this feat is immediately visible
when you walk into his office. Dominating one of the walls is a three-
by-eight-foot chalkboard. It’s divided into five columns: plan, ready,

---

blocked, work, and done. The work column is further divided into
two sub-columns: in development and testing. Taped under each
column are stacks of hand-labeled notecards. If you stick around
Alex’s office longer, a pattern will emerge. Most mornings, the
project leaders on Alex’s team gather around “the big board,” as
they’ve taken to calling it, and discuss the cards. As they talk, the
cards are moved: some are shifted from one column to another,
while others are arranged into a different order in their current
column. What you won’t see is these project leads splitting their
attention between the discussion at hand and their email inboxes.
Alex’s team isn’t big on email (or instant messenger for that matter):
they see this technology primarily as a tool for interacting with
external partners. The information that really matters for their
getting things done is all right in front of them, scrawled on cards
taped to a chalkboard.
As Alex explained to me when I asked him how he avoids the
hyperactive hive mind workflow, the chalkboard in his office is not
the only tool used by his team. Each notecard taped to the big board
corresponds to a project. When a project makes it to the work
column, the group of employees assigned to the project will create
their own board dedicated to the tasks required to accomplish the
project. Unlike the big board, these smaller boards are typically
implemented in software. Alex’s team prefers two tools that are
popular in the software development community, called Asana and
Jira, for creating these digital boards. Once a project is underway,
those working on it will hold their own regular meetings to update
the project’s board—discussing the cards and rearranging them
among the columns.
When I spoke with Alex, for example, there was a card on the big
board labeled with a project that involved the process used by one of
the provider’s hospitals for storing the results of the genetic tests
they conduct on babies. At the time, the data was housed on an FTP
server. Alex’s team was tasked with figuring out how to move this
information into a more flexible database. He explained to me how
this project would advance:
We know about this project. It’s represented as a card in the
plan column. It’s ordered behind three other things that

---

have to get done first. Once it comes up to the top of this
column, we will discuss it and come up with detailed tasks to
add into Asana or Jira. On the big board, we’ll then move its
card to in development.
Alex typically holds these discussion meetings every morning. If
his development teams are fully engaged in projects—“rock and
rolling”—he’ll temporarily scale back these big picture meetings to
once per week until there’s more planning to be done.
—
This is the third time we’ve encountered a similar pattern:
information about knowledge work arranged into columns of cards
on a board. Alex’s team uses both physical chalkboards and virtual
boards implemented by Asana. Optimize Enterprises relies on Flow.
Devesh, from the last chapter, uses Trello.
The general idea of posting tasks on boards to organize work is
not new. Hospital ERs, for example, have long relied on tracking
boards: whiteboards, divided into a grid, that list every patient being
treated, including their room, the doctor or nurse assigned, and their
triage level. For the harried staff, the tracking board provides, at a
glance, a good overview of the current state of the emergency room.
It also simplifies the tasks of figuring out where to put new patients
and where doctors should dedicate their time. As mentioned, even
the early twentieth-century Pullman train company relied on boards.
They used brass tags hung on a wooden board to summarize the
assignment of brass workers to machinery.
Recently, a more refined approach to deploying tasks on boards
as a productivity tool has emerged. In this approach, boards are
divided into named columns, and work tasks are arranged as vertical
stacks of cards under the column that best describes their status.
Sometimes, as with the plan column on Alex’s big board, the vertical
ordering of cards indicates priority. This is the general setup
deployed by Alex, Devesh, and Brian Johnson.
The source of this approach to organizing work can be found in
the software development community, which over the past couple of
decades has increasingly embraced so-called agile methodologies for
producing software. The basic ideas behind agile were first

---

summarized in a 2001 manifesto penned by a group of seventeen
programmers and project managers. The manifesto opens
optimistically: “We are uncovering better ways of developing
software.” It then lays out twelve principles, each explained in plain
language. “Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software,” reads one
principle. “Simplicity—the art of maximizing the amount of work not
done—is essential,” reads another.
4
To understand agile, you must understand what it replaces.
Software development used to rely on lumbering, complicated
project plans that would quixotically attempt to figure out in advance
all the work required to produce a major piece of software. The idea
was that, given one of these plans, often lovingly rendered in striated,
multicolored Gantt charts, you could know exactly how many
programmers to assign at each stage and provide your customers
with accurate release schedules. This approach made sense in theory,
but for anything but the simplest projects, these plans almost never
proved accurate. Producing software is not like producing cars: it’s
hard to accurately estimate how long different steps will take or what
problems might arise. It also turned out that customers didn’t always
know everything they needed in advance, so the features being
developed would change on the fly, further undermining the
schedule.
The agile mindset argues that software development should be
broken down into smaller chunks that can be released into the wild
as quickly as possible. As users provide feedback, the information
can be quickly integrated into future updates—creating a fluid
feedback cycle that evolves useful software instead of trying to build
it perfectly all at once before releasing. As more and more software
became web-based, simplifying the process of releasing updates and
soliciting feedback, various agile methodologies became extremely
popular in the world of developers.
The word various is important here. Agile by itself is not an
organizational system; it instead defines a general approach that is
realized by multiple different specific systems. Two of the more
popular systems at the moment are Scrum and Kanban, which, if you
have any involvement with software, are terms you’ve at the very
least heard mentioned. Generally speaking, Scrum breaks work down
into sprints, where a team dedicates itself completely to delivering a

---