Updating Ideas from David Allen’s “Getting Things Done”
Where its foundational ideas need tweaks for the modern world
Updating Ideas from David Allen’s “Getting Things Done”
Where its foundational ideas need tweaks for the modern world
Mike Stein
Sep 08, 2026
1
5
Share
Technology and culture have changed since 2001. How does that change your GTD method? (Photo by
Bagzhan Sadvakassov
on
Unsplash
)
Last week, I reviewed
David Allen
’s
seminal productivity text
Getting Things Done
, a 25-year-old read that holds up surprisingly well and is rich with useful foundations for task management.
Book Review: David Allen’s “Getting Things Done” at 25
Mike Stein
·
Sep 1
Read full story
I did, however, find a few points where, since my original read of this book in 2013 and as the modern workplace has developed, I’ve gone on to disagree.
Death by a thousand 2-minute actions
Chapter 2’s Workflow Diagram, a flowchart for handling all types of inbound “stuff”, is the image that had stuck with me the most from my original 2013 read of the book. It’s relatively simple, yet touches the key pieces of triage process design: filtering for actionability, identifying the next move, and teeing it up for appropriate action.
The piece of this flowchart that I immediately adopted was its
2-minute quick task threshold
: if a new task would take less than 2 minutes to complete, just do it immediately rather than save it for later.
I think 2 minutes was the right threshold a few decades ago, but
as work got faster, 2 minutes started to feel to me like the wrong cutoff point.
What were once printed memos are now Slack DMs – and I do think the Slack era was the inflection point here.
It’s easy for a series of 2-minute tasks to add up to hours a day of distraction when work happens through constant low-friction, realtime communication and collaboration.
You want to be sweeping and triaging often, but many can no longer stay productive while hitting all these 2-minute tasks out when you encounter them.
So my current quick task threshold is 30 seconds.
I now routinely create short-term batches and sweeps for tasks that take between 30 seconds and 2 minutes, such as most
Slack messages
,
emails
, and
notifications
(click on those links for my methods for each!), which decreases context-switching and maintains focus rhythms without compromising on reasonable response times.
Relatedly, the flowchart’s frame of delegation as a potential triage path for a long task
is a broader pet peeve of mine – if it’s not worth you doing, why is it worth a colleague doing
? Are we working with teammates we trust and align with on goals, or are we playing hot potato? In the framework of the book, the “Someday/Maybe list” discussed in Chapter 7 seems like the better default triage; if it’s not important, it shouldn’t be delegated as a task for someone to do, but it should be lightly captured and offered up as a possible task we could do later so that others can weigh in.
The many modern collection buckets
Chapter 2 offers up three requirements for effective collection (aka
capture
):
Every open loop must be in your collection system and out of your head.
You must have as few collection buckets as you can get by with.
You must empty them regularly. (page 29)
All apt for the turn of the century, but a bit of a mixed bag today. #1 is still critical, and
taming open loops
is a tougher challenge than ever. However, I’ve moved away from both #2 and #3.
It makes sense to have as few collection buckets as possible when they were physical baskets on your desk or different notebooks you use, but when most of these, along with almost all of everything else that flows into your work, are now digital and continuously sync to whatever device you happen to be near, the inherent advantage of minimizing buckets decreases. On the other hand, as the number of digital buckets – messaging apps, notifications, different email accounts, or even different filtered folders and tags within an email account – increases over time,
there’s upside in
keeping these buckets separate
but managed automatically
via
email filtering
,
notification batching
, and the like, as long as you build the right process around
when you check those batches
. It’s still a balance of pros and cons, but for the past decade or so, my default is no longer to strictly minimize “buckets”.
Once you adopt that mindset, it’s no longer necessary or wise to empty all of your buckets regularly.
Different buckets allow you to check the important buckets more often and the less important buckets less often.
Your goal is to set up the right processes and communication expectations so that you pay the appropriate amount of attention to each bucket. The result should be some buckets that you rarely get to
and that it’s ok if you end up never getting to
, such as
emails not to: or cc: you
and
the bottom of your RSS feeds
.
The book said you “can’t organize what’s incoming” (page 31), but using technology to filter, pre-triage and batch your inbounds means you now
can.
Shifts in meeting culture
One of the greatest blocks to organizational productivity is the lack of decision by a senior person about the necessity of a meeting, and with whom, to move an important issue forward. (page 214)
This is an interesting angle that the book raises in the context of brainstorming for project planning. I sat with this for a while, but I think I just haven’t seen this. I can imagine this having been true in some places, especially at the biggest companies in decades past, but I never ended up working anywhere like this.
Every scrappy team I’ve worked with suffers from the opposite problem:
too many unfocused, low-return-on-investment meetings
.
Among the too many meetings, the good ones are those where the responsible party has
thoughtfully chosen the focus of the meeting and the audience
. The bad meetings are those that pull in too many people for too long for too indistinct of a meeting outcome – and, in my experience,
these bad meetings skew towards the brainstorming and project planning meetings
that the quote addresses.
That doesn’t mean brainstorming meetings are always bad. The best brainstorms have both clear goals and guardrails on the discussion. They involve pre-meeting exercises such as drafting early ideas in a collaborative document to upvote. They invite people in, but also encourage people to opt out (or contribute to just the asynchronous pre-meeting document) unless they feel they will be valuable. Project planning, too, should be collaborative and transparent, but rarely warrants live meeting time from every member of a team.
Put it into practice
What’s your current quick task threshold, i.e. how quick does a task have to be for you to do it immediately rather than defer it?
If you haven’t thought about this before, what has your implicit one been?
Should it be lower, so you can retain your focus on deeper work throughout your day?
If it feels like it should be higher, should you instead try building better
processes for clearing your deferred batched tasks
?
What are your collection buckets?
Does each one have a reason to exist, or can any be combined or abandoned?
How often do you work through the collected tasks in each bucket? Is that in line with their relative importance?
To re-up my recommendation:
Get your team reading this book
. It’s packed with practices and ideas that will help you build or rebuild your productivity foundation, and differences in approach like the ones I lay out here are great conversation starters within your team.
If you have any sort of reading list or book club group, get this in the mix.
Even better, give a copy to your new hires – that’s how I got mine, and it was a valuable positive signal on the team’s values that set a common expectation of the standards to hold each other by.
My newsletter’s kind of a book, and highly shareable, too!
The "book" order of my archives
I’ve organized my archives into a recommended reading order. You can learn more about this “book”
here
or hop to the next or previous “chapter” via the links below.
Previous chapter:
Book Review: David Allen’s “Getting Things Done” at 25
Mike Stein
·
Sep 1
I first read David Allen’s foundational Getting Things Done 13 years ago. I had already self-discovered the value of to-do lists and on task capture but had never seen or thought about any structure, principles or practices beyond that. This book was a pivotal early moment in my long path towards buildin…
Read full story
Next chapter:
April 1, 2026 Reading Group Readout: Frog and Toad’s “A List”
Mike Stein
·
Apr 1
Thank you to the thousands of paid subscribers1 who participated in highly rigorous, often-contentious discussions over the past several weeks as we reread the 1972 productivity classic “A List” from Frog and…
Read full story
1
5
Share
Previous
Next