The useful part of time blocking is one sentence: decide in advance what a stretch of time is for, so you are not deciding at the moment you sit down. That is the whole mechanism, and it is worth doing.

Everything built on top of it — the themed days, the colour taxonomy, the rule that every minute of the week must be assigned, the Sunday evening ritual of laying out the grid — is not the mechanism. It is a practice that grew around the mechanism, and almost all of it assumes you can decide what goes in your own calendar. Most of what is written about time blocking for time management is written for that person. If you are not that person, the practice collapses within about two weeks and you conclude you are bad at it.

You are not bad at it. It made three assumptions about your calendar that are not true.

Three assumptions it makes about your calendar

That you fill it. The canonical version has you assign every hour of the week on a Sunday or a Monday morning. This works if the only thing that puts events on your calendar is you. If other people have booking rights, you are not laying out a week — you are making a prediction about a week, and predictions that cover forty hours are wrong by Tuesday. Then the grid is a document that disagrees with reality, and the sensible thing to do with it is stop looking at it, which is what everyone does.

That the blocks are interchangeable. The practice treats a block as a container: work goes in it, and if the block moves, the work moves with it. Some work is genuinely like that — reviewing, replying, administrative batches. The work you most want blocks for is not. Something that takes ninety minutes to get into and produces nothing in the first twenty is not portable, and moving it from Tuesday morning to Thursday afternoon is not a reschedule, it is a restart. What an interruption actually costs is the reason the arithmetic does not work out the way the grid suggests.

That the calendar is private. A block is a message to everyone who can see your availability, and the practice never treats it as one. Fill your week wall to wall and you have not protected anything — you have published a week with no white space in it, which reads to most teams as either unavailability or a bid for status, and gets overruled. A block that is all of the calendar protects none of it. The block has to be legible to the person booking over it before it has to be comprehensive.

The two-block week

Here is the version that survives contact with a calendar you do not own. It is deliberately small.

Two anchor blocks a week. Two hours each, named after a deliverable with a date — not “focus”, not a project area. Two is the number because two is defensible. You can tell your manager you hold four hours a week for a named piece of work and it sounds like planning. Fifteen blocks sounds like a system, and systems get overruled.

Everything else stays white space. Not because the rest of your time is unimportant, but because white space is what you spend when something lands. If the week has slack in it, a meeting on Wednesday afternoon costs you nothing and you spend no correspondence on it. If the week is wall to wall, every single incoming request is a collision you have to handle.

One batching window, if you need one. A single recurring slot for the shallow pile — replies, approvals, expenses, the ten-minute things. One, not a themed day. It exists so that the anchor blocks are not where you quietly do admin.

One rule for collisions. When something lands on an anchor block, move the block within the same week if you can and give it up if you cannot, but do not move the other anchor to compensate. One anchor surviving is a normal week. Both surviving is a good one. Zero is the signal to go and have the conversation rather than to redesign the grid.

That is it. It fits on a sticky note, there is nothing to maintain on a Sunday, and it degrades gracefully — a bad week costs you one block rather than invalidating the whole structure.

What to stop doing

Specific practices to drop, with the reason:

  • Assigning every hour. It is a prediction, not a plan, and a wrong prediction is worse than white space because you now have to repair it.
  • Colour systems. A taxonomy of seven colours is a maintenance obligation that produces no decision. You are not going to look at the pie chart. Two states — committed and open — is enough.
  • Re-blocking after every collision. When a block gets taken, the instinct is to immediately rebuild the week around the loss. Do not. Take the loss, keep the other anchor, carry on. Rebuilding is how a practice turns into a chore and then stops.
  • Blocking your best hours by default. Your most contested hours are usually your best ones. Holding the second-best hour reliably beats losing the best one weekly, and this is a concession worth making knowingly.
  • Thirty-minute blocks for deep work. A thirty-minute block for something that needs an hour to load is an appointment with a feeling of productivity. Either give it ninety minutes or put it in the batching window and admit what it is.
  • Keeping a block that has lost its deliverable. When the thing in the block’s name ships, the block has no claim on anyone. Rename it the same day or let it go.

When time blocking is the wrong tool

Three situations where the answer is not a better grid. Recognising one of them early is worth more than any of the advice above.

Your load is the problem, not your structure. If meetings occupy most of the working week, blocking is rearranging what is left. There is no grid that produces focused hours out of a calendar with none in it, and the work is in the recurring set — reviewing what recurs and killing what nobody will defend. Count the hours before you design anything; the audit takes ninety minutes and it tells you which problem you have.

Your work is genuinely reactive. Support, on-call, sales coverage, incident response, an assistant covering someone else’s day. For these roles a blocked week is a fiction and the honest structure is a rota with coverage windows, not personal focus blocks. Advice written for a maker’s schedule is the wrong advice here, and following it mostly produces guilt.

The real constraint is unclear priorities. If you cannot name the deliverable to put in the block, blocking will not help, and building the grid will feel like progress for about a week. The missing input is a conversation with whoever sets your priorities, not a calendar layout.

There is also no reliable public figure for how much time blocking is worth — the numbers in circulation come from the companies selling scheduling software, and the honest position is that the mechanism is plausible and the magnitude is unmeasured. That is not a reason to skip it. It is a reason not to treat it as a discipline you are failing.

The test after two weeks

One question, and it is not whether you kept to the grid.

Did the thing named in the anchor blocks move? If it did, the structure is working and you do not need more of it. If the block was reliably held and the work still did not move, the block was not the constraint — look at whether the work was actually the priority, or whether it needs more than four hours a week to progress at all.

And if the blocks were not held: count how many times, and by whom. Two numbers from two weeks is enough to turn this from a personal-discipline problem into a scheduling problem with somebody else’s name on it, which is the only form in which it tends to get solved.