responsibilities of this role is to head the graduate committee, which
oversees our graduate program, including approving changes and
answering requests about policy.
As you might imagine, this leads to a large number of incoming
issues that I’m in charge of resolving. Taking a page out of Devesh’s
playbook, I internally deploy a Trello board to help make sense of
these requests. My board has the following columns:
☐
waiting to deal with
☐
waiting to deal with (time sensitive)
☐
to discuss at next graduate committee meeting
☐
to discuss at next meeting with department chair
☐
waiting to hear back from someone
☐
working on this week
When someone sends me an email or stops by my office with an
issue concerning the graduate program, I immediately transform it
into a card and place it in the applicable column on the Trello board.
At the beginning of each week, I review this board and move
cards around as appropriate: deciding, for example, what I want to
work
on this week, or what needs to be discussed in upcoming
meetings. I can also follow up on issues I’m waiting to hear back
from someone about. My general rule is that when I move a card to a
new column, I send an email update to the person who brought me
that issue. For example, if I move something from a
waiting column
to the
discuss at next graduate committee meeting column, I’ll send
a note to the appropriate person telling them that we’ll be discussing
their issue soon. If I take a card off the board because I completed
the
corresponding task, I’ll let the relevant people know the ultimate
resolution. And so on.
The key property of this system is that the professors and
graduate students in my department know nothing about it. I
suppose I could try to insist that they all log in to my Trello board to
enter new issues or check on the status of old issues. In theory, this
might save me a few extra messages, but in reality, no one would
actually do this—and I can’t blame them! It takes me about thirty
minutes, once a week, to process
my board and send update
messages. I receive massive benefits from structuring all these issues
so clearly, and because I spent a little extra time to make my
interface seamless, my colleagues can enjoy these benefits as well.
—
At first encounter, my advice for applying the attention capital
principle to groups seems at odds with my advice for applying the
principle to individuals. The former emphasizes the need for clear
communication about the workflows replacing the hyperactive hive
mind, while the latter suggests you keep these changes largely
private.
A closer look, however, reveals that both approaches are
based on the same principle: people don’t like changes they can’t
control.
When modifying the workflow of an entire team or organization,
everyone can be involved in this change and feel empowered to
optimize it. As discussed earlier, this provides a sense that the locus
of control is internal, motivating people to stick with the changes.
When you alter your personal workflow, by contrast, those you work
with didn’t really have a say in what you decided to do. If they’re then
presented with a new system that
will impact their own work, but for
which they had no input, the locus of control moves toward the
external, creating irritation and a tendency to try to push back and
reassert some control. They don’t applaud your clever new
autoresponder; they instead find ways to tear down the restrictions it
has imposed on them.
The psychology at play here is perhaps a bit subtle, but also
crucial to master if you hope to succeed in maximizing your attention
capital. Work is not
just about getting things done; it’s a collection of
messy human personalities trying to figure out how to successfully
collaborate. The three chapters that follow look closely at specific
strategies for replacing the hyperactive hive mind with much more
effective workflows. The value of these detailed approaches, however,
will be greatly diminished if you don’t first master the subtle art of
putting them into action in a way that sticks.
