How Do Do It Tomorrow and Time Blocking Work Together?

And how Time Blocking sharpens Do It Tomorrow in return.

Do It Tomorrow, a system built by the productivity writer Mark Forster, means keeping two lists — a closed, fixed list of what you're actually working on today, decided this morning or the night before, and a separate list for tomorrow, where anything new that shows up during the day gets written down instead of acted on right away, unless it's a genuine same-day emergency. Time blocking means taking whatever's on your list and assigning it an actual slot on your calendar in advance — 2:00 to 2:45, draft the proposal — instead of leaving it as an item you'll get to whenever there's a gap. The two protect different things. Do It Tomorrow protects what counts as today's work from silently expanding every time something new arrives. Time blocking protects when each item on that list actually happens from being eaten, piece by piece, by whatever interrupts you next. A closed list that isn't scheduled still gets worked reactively, item by item, all day. A scheduled calendar that isn't capped still gets rewritten every time a new task muscles its way in.

What each one is actually for

Do It Tomorrow

Do It Tomorrow works off two lists instead of one. Today's list is closed the moment the day starts — nothing gets added to it during the day, no matter what comes in. Anything new that arrives while you're working — an email, a request from a colleague, an idea you have mid-task — gets written onto tomorrow's list instead, where it waits until tomorrow becomes today and that list, in turn, closes. The one exception is a genuine emergency, something that actually can't wait, which is meant to be rare rather than the default excuse for reopening today's list every time something feels urgent. The effect is that at any point during the day, you can look at your list and know it isn't secretly growing behind your back while you work through it.

Time Blocking

Time blocking takes whatever tasks you have — from a to-do list, a project plan, wherever they come from — and assigns each one a specific slot on your actual calendar, the same way you'd schedule a meeting: not 'work on the proposal sometime today' but '2:00 to 2:45, draft the proposal.' The task moves from being an open-ended item you'll get to eventually into a fixed commitment with a start time and an end time. The point is that a calendar slot is harder to quietly skip or postpone than a to-do list item, because it occupies a specific piece of your day the way a meeting would, and because deciding when something happens in advance removes a decision — when do I do this? — from the moment you'd otherwise have to make it under pressure or distraction.

What you get out of pairing them

Run alone, each system leaves its own specific gap open. Do It Tomorrow gives you a list that can't silently grow during the day, but nothing in the system itself stops you from bouncing around inside that closed list all day reactively — working on whichever item feels most urgent each time you glance at it, rather than in the order you'd actually decided mattered most, so the list stays capped but the day still gets spent reactively. Time blocking gives you a calendar full of protected slots, but a single unmanaged new request — an email, a Slack message, someone stopping by your desk — can still talk its way directly into today's blocks, bumping a scheduled item, because nothing in the system is stopping new tasks from muscling into a day that's already been mapped out. Put together, Do It Tomorrow decides what's allowed onto today's map in the first place, and time blocking decides exactly when each thing on that already-capped map actually happens — so the same new request that used to derail either system on its own now has nowhere to land except tomorrow's list, where it gets its own scheduled slot in turn.

What Do It Tomorrow rests on

  • Implementation intention closes intention action gap randomised trials
    Pre-committing to a specific situational cue paired with a specific response lets the behavior fire automatically when the cue occurs, without depending on in-the-moment willpower.
  • Closed lists reduce overwhelm practitioner report
    A fixed bounded list of tasks rather than an ever-growing open list reduces the felt overwhelm of an infinite to-do list.
  • Deferred capture protects commitment practitioner report
    Writing newly arriving tasks onto tomorrow's list rather than acting on them immediately protects today's already-committed plan from being derailed by reactivity.

What Time Blocking rests on

  • Externalizing makes pattern visible randomised trials
    Putting an internal pattern into an external, structured form makes it visible and available for examination instead of remaining implicit and merely enacted.
  • Implementation intention closes intention action gap randomised trials
    Pre-committing to a specific situational cue paired with a specific response lets the behavior fire automatically when the cue occurs, without depending on in-the-moment willpower.
  • Pre commitment reduces decision fatigue plausible mechanism
    Deciding in advance how time will be spent removes many in-the-moment choices that would otherwise be hijacked by reactive demands.

Where they actually meet

Both systems are a version of the same move — decide now, execute later without re-deciding — aimed at two different decisions that would otherwise get made in the worst possible moment to make them well: mid-interruption, under the pressure of a freshly arrived request. Do It Tomorrow decides in advance whether a new task belongs to today or tomorrow, so that decision doesn't get made reactively every time something new lands. Time blocking decides in advance when today's already-settled items actually happen, so that decision doesn't get made reactively every time your attention is free for a moment. Neither system trusts the in-the-moment version of you to make either call well, and both are built around that same honest assumption.

The principle underneath both

Deciding the specifics of a plan in advance — what belongs on today's list, and exactly when each item on it happens — removes a decision from the moment it would otherwise be made, and that moment is reliably the worst one available for making it well: mid-interruption, under a new email's pressure, with the day's patience already partly spent. A decision made calmly in advance and simply executed later tends to hold up better than the same decision made fresh, under pressure, in real time.

What that makes the real goal

What both are actually building toward is a version of today that no longer requires a real-time decision at the exact point something new, distracting, or tempting shows up — because whether it belongs to today, and when today's real items happen, were both already settled earlier, at a calmer moment, by a version of you with more perspective than the version currently mid-interruption.

Other practices that serve the same goal

Getting Things Done's closed-versus-open-loop capture system solves a very similar problem to Do It Tomorrow's two-list structure, by insisting that anything not being acted on right now gets captured somewhere trusted instead of held in memory or left floating on an open list. The Eisenhower matrix addresses the 'what belongs on today' half by sorting tasks on urgency and importance rather than by arrival time. The Pomodoro Technique protects smaller stretches of time than a full time block, twenty-five minutes at a stretch, which can work better for people who find a 45-minute block too long to defend from interruption. All of these, in different shapes, are aimed at the same underlying goal: deciding in advance so the moment of actual work doesn't also have to carry the weight of deciding.

A tradition that already does this

Long before either system had its current name, manufacturing and project management drew this exact line between two separate decisions: what belongs in this batch or sprint — a closed, committed scope, decided in advance and protected from new arrivals mid-run — and when each item in that batch actually happens, a specific schedule laid out within it. Kanban and scrum both formalize precisely this split, decades before Mark Forster's Do It Tomorrow, published in 2006, or the current productivity-blogger version of time blocking existed under those names; this pairing is an old, well-tested structural idea applied to a single person's day instead of a team's sprint.

Let the closed list decide what's even eligible for a slot

Before you block out tomorrow's calendar, run Do It Tomorrow's rule first: everything that arrived today that isn't a genuine same-day emergency goes onto tomorrow's list, not directly onto tomorrow's schedule. Only once that list is closed for the day do you go through it and assign each item its own block. This ordering matters more than it might seem to: time-blocking a list that's still open to new arrivals means you'll spend the next day rearranging blocks around interruptions instead of protecting them, because the thing underneath the calendar never actually stopped growing — you just scheduled a moving target.

Give a deferred item an actual slot, don't just move it

Do It Tomorrow's tomorrow-list can quietly turn into a dumping ground: an item gets pushed from today to tomorrow, then from that tomorrow to the next one, without ever actually getting a real time attached to it — a subtler version of the exact overwhelm the closed-list structure was supposed to prevent in the first place. Borrow time blocking's discipline directly: the moment you write something onto tomorrow's list, also assign it a specific block on tomorrow's calendar right then, in the same motion, rather than leaving 'tomorrow' as an open-ended promise that can keep sliding.

10:41am, an email lands mid-block

You're forty minutes into a 90-minute block reserved for a report that's due Friday, and an email arrives: a colleague needs input on a slide by end of day. Your first instinct is to switch over and knock it out now, since it feels quick. Instead, you open tomorrow's list — not today's, because today's closed this morning — and write 'slide input for Dana' at the bottom. You immediately open tomorrow's calendar and drop an 11:00am block onto it, thirty minutes, before you let yourself go back to the report. The whole interruption costs you ninety seconds instead of the fifteen minutes it would have cost to actually switch tasks, and the report block, the one you're still sitting inside of, stays exactly as long as you originally protected it.

When this is worth reaching for

The role brings frequent unplanned inbound requests — Slack messages, email, someone stopping by with a 'quick question' — so both what counts as today's work and when today's work actually happens are under constant, small pressure from things arriving in real time. It's especially worth building if you've noticed one system failing on its own: a closed list that still gets worked chaotically all day, or a time-blocked calendar that keeps getting silently rewritten by whatever just landed in your inbox.

Where this does not apply

If your work is genuinely reactive by its nature — an on-call role, frontline support, anything where responding promptly to whatever just came in is the actual job rather than an interruption to it — layering a closed daily list and rigid calendar blocks on top of that kind of role fights the real shape of the work instead of helping it. Forcing a support engineer's day into fixed 45-minute blocks when the job is answering tickets as they arrive is asking the system to protect against the very thing the role exists to do. For work like that, a much looser structure — a rough priority order for downtime between interruptions, not fixed slots — tends to serve better than either system used strictly.

What the evidence does and does not support

Implementation intentions — the general finding that deciding a specific cue and a specific response in advance makes the response far more likely to actually happen — have strong randomized-trial support, and both halves of this pairing lean on that same underlying mechanism. The specific named systems, Do It Tomorrow and time blocking, are practitioner-developed productivity methods rather than clinically tested interventions; their support is anecdotal and reasoned from the underlying research rather than trial-tested as complete systems in their own right. No study has compared running both together against running either one alone; that comparison is this page's own reasoning about how the two mechanically fit, not a measured result.

Practice this with IX Coach

Try this practice

The two practices on their own

Other pairings with these practices

The principles underneath both