Time Blocking When Your Estimates Are Wrong
If time blocking is supposed to make the day predictable, mine fails most of the time. It is still worth doing, for a reason that has nothing to do with the estimates being right.
Most writing about time blocking assumes the blocks are roughly right. Mine are not. If the test is whether the plan matches the day, I fail it most weeks, and I have kept doing it anyway.
I keep a written list of what needs doing, and I write the blocks into Google Calendar alongside the meetings. Out of every 10 blocks, 7 or 8 overrun. When one does, I stop and move the rest of that work into another block rather than letting it eat the next thing. That rule is the only part of this that has survived contact with a real week, and it is doing more work than the planning is.
What the blocks are actually for
- Deciding what to work on, once, in advance. This is the real benefit. The cost of choosing at 10am, again at 11am, again after lunch is larger than any estimate error.
- Making the day's capacity visible. A list of nine things looks possible. Nine things in a calendar is obviously not, and you find that out before you promise it to someone.
- Protecting the next piece of work. Not the current one, the next one. That is the distinction most advice misses.
Why I stop instead of pushing everything back
If I let an overrunning block run until the work is done, the overrun lands entirely on whatever came after it, which is usually the thing I was least looking forward to and most needed the plan for. One wrong estimate then takes out the afternoon.
Stopping at the boundary and moving the remainder costs me the annoyance of leaving something unfinished. What it buys is that the rest of the day still exists. The unfinished work goes back on the list and gets a block of its own, usually a more honest one now that I have seen the real shape of it.
The estimates do not get better
I have been doing this long enough that I expected the estimating to improve. It has not, or not enough to notice: 7 or 8 in 10 still run over. I have stopped treating that as a problem to solve, because the work genuinely is unpredictable, and a plan that assumed otherwise would just be wrong in a more organised way.
What changed is that I plan fewer blocks than there are hours. Not as a clever technique, just as an admission of the above.
Calendar and list do different jobs
The list holds everything that needs doing and does not care when. The calendar holds commitments, including the ones I have made to myself. Keeping my own work in the calendar next to the meetings is what stops a day looking free when it is not, and it is why I will say no to a 4pm call that a list alone would have let me accept.
If you are starting
Do not aim for accurate blocks, you will not get them. Aim for two things: deciding in advance what the block is for, and a rule about what happens when it overruns, decided before it does. Everything else is decoration.
The same thinking applies to anything with a fixed window and work that does not respect it, which is why I care how long a build takes, as I wrote when getting a pipeline back under ten minutes.
What I did myself
I keep a written list of what needs doing, and I write the blocks into Google Calendar alongside the meetings. Out of every 10 blocks, 7 or 8 overrun. When one does, I stop and move the rest of that work into another block rather than letting it eat the next thing. That rule is the only part of this that has survived contact with a real week, and it is doing more work than the planning is.
Palak Patel, IT engineer, developer and researcherfacts confirmed October 2, 2026
Written by
Palak Patel
IT engineer, developer and researcher
Palak is an IT engineer, developer and researcher, and runs ToolNest. He uses the software he writes about in his own development work and says so when he has not. Every claim is checked against vendor documentation, changelogs and pricing pages before it goes live.