GTD is a method for getting commitments out of your head and into a system you trust, so that the head can do the thing it is good at instead of the thing it is bad at.
David Allen published it in 2001. It predates every app that now implements it, and its central claim has aged better than most productivity writing: your mind is for having ideas, not for holding them.
The five steps
Capture. Everything that has your attention goes into an inbox. Not sorted, not judged. The only requirement is that catching a thought is fast enough that you actually do it. See the capture habit.
Clarify. Take each item and ask what it is. Actionable or not. If it takes under two minutes, do it now. If not, it becomes a next action, a project, a delegation, or a someday item. If it is not actionable, it is reference material, or it is rubbish.
Organise. Put it where it belongs. Next actions by context, projects on a project list, reference into your notes, calendar for things genuinely tied to a date.
Reflect. Review the whole system weekly. This is the step that keeps it alive.
Engage. Choose what to do from the lists, based on context, time, energy, and priority, in that order.
The load-bearing idea is the next action. Not "website redesign" but "email Sara for the logo files". A project stalls when the next physical action has never been decided, and most procrastination on paper turns out to be an undefined first step rather than a motivational failure.
The science, fairly stated
Heylighen and Vidal's 2008 paper is the usual citation. It argues that GTD matches what is known about situated and distributed cognition: the brain leans heavily on the environment as external memory, as a trigger for action, and as a source of affordances. GTD is, in that reading, a disciplined way of building such an environment.
Note what that is and is not. It is a strong conceptual fit with cognitive science. It is not a controlled trial of GTD, and controlled trials of GTD as a whole system are basically absent. Anyone citing that paper as proof that GTD works is overreading it.
There is better evidence for one specific component. Masicampo and Baumeister found that unfulfilled goals intrude on thinking and impair performance on unrelated tasks, and, crucially, that making a plan for the goal eliminated the interference without the goal being completed. That is the Zeigarnik effect plus its off switch, and it is the closest thing GTD has to a mechanism with direct experimental support.
The practical upshot: the relief comes from deciding, not from doing. An open loop that has a defined next action stops occupying you even while it remains open. This is also why capture alone does not work, and why an inbox full of unclarified fragments feels worse than no system.
Where GTD is strong
When you have many small commitments from many directions. Managers, consultants, freelancers, anyone whose day is other people's requests. This is the shape of work GTD was designed around, and nothing else handles it as well.
When the anxiety exceeds the workload. The characteristic GTD result is not doing more, it is the background hum going quiet. That is the Masicampo finding, working as advertised.
When commitments live in ten places. Email, chat, verbal, a calendar invite, a sticky note. Consolidation is most of the value, and it is why the note inbox is a prerequisite rather than an accessory.
Where it fails
Honestly, because the failures are common.
The weekly review is the whole system, and most people drop it. Without it, lists rot into an archive of things you have decided not to do, and looking at them becomes unpleasant, so you stop looking, and it is over. If you can only sustain one habit, sustain the weekly review.
Contexts have aged badly. In 2001, @phone, @computer, @errands were real constraints. Now nearly everything is @computer, and the primary constraint is energy and focus rather than location. Most working GTD systems today sort by energy, or by project, or by a rough today list.
It says nothing about priorities. GTD is a processing system, not a strategy. It will happily help you execute the wrong things very smoothly. Allen's higher "horizons of focus" address this and are the part everyone skips.
Deep work fits badly. GTD is optimised for many small discrete actions. A single project that needs six uninterrupted weeks does not decompose usefully into next actions, and a system that rewards clearing small items can quietly crowd it out. See deep work.
It can become the work. Maintaining the system is satisfying in a way that resembles progress. This is the collector's fallacy applied to tasks rather than notes, and it is the most common way GTD goes wrong for people who like systems.
GTD and your notes
GTD is a task method, not a knowledge method, and the confusion between them causes a lot of mess.
The clean split: actions go in the task system, reference goes in the notes system. A project's next action is a task. What you learned while doing the project is a note. Keeping reference material in your task list buries the actions, and keeping actions in your notes means they are never reviewed at the right moment.
Where it connects to PARA is direct, and not accidental: Tiago Forte built PARA on GTD's project structure. Projects, areas, resources, archive is essentially GTD's outcome horizons applied to files. If you already run GTD, PARA is the matching filing system, and second brain is what happens when you take the reference side as seriously as the action side.
The one thing worth taking from GTD even if you reject the rest: capture everything, and give each thing a defined next step. That pair does most of the work.
More in note-taking workflow, interstitial journaling, and PKM mistakes.