How to protect two uninterrupted hours (or one deep block) daily

For three Wednesdays in a row, I accepted a "quick sync" that a colleague several time zones away had booked at 09:30. It was a perfectly friendly invitation. It sat right in the middle of the only two-hour stretch in my week that nobody else had claimed, and I said yes each time because saying yes to a thirty-minute call felt cheaper than explaining why I did not want it.

It was not cheaper. Each of those Wednesdays, the morning became forty minutes of warming up, the call, ten minutes of follow-up messages, and forty minutes of trying to get back to where I had been. On paper I had lost thirty minutes. In practice I had lost the block, because two forty-minute pieces are not the same thing as ninety minutes in one go. The work I had planned for Wednesday moved to Thursday, which pushed Thursday's work to Friday, and so on.

What finally changed it was not a productivity system. It was deciding that the block was a commitment like any other meeting, and treating it with the same seriousness everyone else gave their calls.

Why two hours, and why not more

Most remote work that matters needs one window where a single task is the only task, long enough to reach something reviewable. For a lot of jobs, two hours is about right. It is enough for many coding changes, a properly drafted proposal section, a reconciliation you have been avoiding, or a test plan that unblocks someone else.

One hour often goes mostly on setup. You open the files, remember where you were, rebuild the picture in your head, and just as the work starts moving, the hour ends. Three hours is lovely on the days you get it, but planning around three hours on a normal remote week means planning around something that rarely happens.

I also do not believe most people can do more than one or two of these a day. Planning four deep blocks and getting one is demoralising. Planning one and defending it properly is how real work gets done on weeks full of other people's calendars.

Planning one and defending it properly is how real work gets done on weeks full of other people's calendars.

Choose the slot from the calendar, not from enthusiasm

The common mistake is deciding the task first ("I'll finally do the migration tomorrow") and then trying to find two hours for it. Do it in the other order. Look at the calendar for the next few days and find the longest gap that is usually quiet, then put a hold in it called something plain, like "Focus: main task". Only after that, decide what goes inside.

Usually quiet is the important phrase. A gap that looks empty is not the same as a gap that is quiet. When I looked properly at a normal week, my mornings were empty but not quiet after about 10:30, because that was when the colleagues further east were wrapping up and sending their end-of-day questions. The afternoons were quiet until about 15:00, when the colleagues to the west came online. The actual quiet window was 08:00 to 10:30, and that is where the hold went.

Protect sleep while you are at it. A deep block at 06:00 or 22:00 that you skip every other day is not a system, it is a wish. A slightly shorter block at a time you will reliably keep beats a heroic one you keep half the time.

Inside the block there is one outcome, written as a finish line someone else could check. Open the files you need before the hold starts, so the first minutes go on work rather than on finding things. Close chat unless your job that day really is responding to incidents.

Screenshot

Treat the hold like a meeting you are attending

If someone books over a meeting with a client, you would not quietly drop the client. You would say there is a conflict and offer another time. A focus hold deserves the same, otherwise everyone around you learns, correctly, that your holds are decoration.

Here is roughly what I sent about the Wednesday sync, after three weeks of not sending it:

I keep 08:00 to 10:30 CET for focused work, so 09:30 Wednesdays
breaks it in half. Could we try 14:00 CET instead? If that is
awkward for you, I'm happy to do this one async: send me the
questions by Tuesday evening and I'll reply in the doc by
Wednesday 11:00.

The reply was "oh, sure, 14:00 is fine". Three weeks of lost mornings, solved by one message. I suspect this is the most common outcome by far, and the main reason people do not send the message is that they imagine a fuss that never comes.

Not every meeting can move. Before accepting one that lands in the block, ask whether it needs a live conversation to reach a decision, or whether it will simply consume the only time you have to make anything. The second kind can usually become a short written brief with a recommendation and a deadline for reactions. When a remote team needs a meeting has a good test for telling them apart.

Watch out for fragmentation, which is a quieter version of the same problem. A calendar that shows you as free in four separate thirty-minute pieces is not offering you two hours. Thirty minutes is enough to load a problem into your head and not enough to do anything with it. Merge, move or decline until there are at least ninety minutes in one piece, then try to grow it.

Say when the block ends, not just that it exists

Do not disturb, closed doors, headphones and status messages all fail in the same way: nobody knows when they stop. Waiting with no end in sight is unreasonable to ask of a colleague or of anyone at home, so people stop waiting.

An end time fixes most of it. "Focused until 10:30, back on chat then" gives a teammate a reason to hold their question for forty minutes instead of pinging twice. If your team uses availability levels, point the non-urgent level at your end time, which is the idea behind available all day is a bad system. At home, the same end time goes on a card or the shared calendar, and the household version of that conversation is in protecting focus at home.

Also agree what actually counts as urgent, in one sentence. For me it is "production is down, or a client deadline today is at risk". Everything else waits forty minutes and is usually still fine.

Shrink the task until it fits the hold

Ambitious tasks grow to fill anxiety. "Fix onboarding" will happily consume a week of blocks without ever being finished. "Reproduce the drop-off on step three in staging and paste the reproduction steps into the ticket" fits inside two hours and leaves something another person can open.

If you finish early, take the next slice of the same work rather than "quickly checking" chat. The quick check is how a successful block quietly turns into a bad afternoon. If you need help sizing slices to the block, timed rounds can help; Pomodoro for client work is how I break a two-hour hold into pieces.

On tired days, a shorter hold with a sharper task still beats waiting until you feel focused. Feeling focused is mostly something that happens after you have started.

When the hold breaks anyway

It will. A client's site goes down, someone at home needs you, a manager decides your focus time is optional this week. The block was never a guarantee, only the best chance of the day.

When it breaks, take sixty seconds before you stand up: write the next action, save the work, note anything you will forget, and pause the timer. Then deal with the interruption and come back to that one line. If the break is mid-debug, take it more seriously than you think you need to, for the reasons in interruptions during debugging.

If the whole block is gone, downgrade the day rather than chasing it. One twenty-five-minute task you finish is worth more than three attempts at two hours in a fragmented afternoon. If the whole morning went, recovering after losing two hours is about getting the rest of the day back without dragging it into the evening.

Weeks when two hours is not realistic

Some weeks will not give you two hours. On-call weeks, travel, a launch, a week of school holidays. Take forty-five minutes with a clear finish line and stop feeling bad about it. Two hours comes back when the week allows.

A meeting-heavy Wednesday, for example: stand-up at 10:00, client call at 14:00. I would take 08:50 to 09:50 with a task that finishes in an hour, like reproducing one bug and writing up the steps. After stand-up I would stay out of chat until 11:30 unless something is on fire. Not two hours, but proof that the day can still produce something.

Clients deserve to be told how this works, because otherwise silence during your block looks like you have vanished. In the first email of a project I say when I reply, when I am heads-down, and how to reach me for real emergencies. A short note before shutdown, of the kind in writing async status people read, closes the loop so nobody is left wondering.

Judge the hold by what it produces

A good block ends with something reviewable: a pull request open, a section sent, a decision written down, a reproduction attached.

• A pull request is open
• A section is sent
• A decision is written down
• A reproduction is attached

Perfect silence is not the measure. Plenty of my best blocks had a delivery and two messages in the middle of them.

Run it for a fortnight and check at shutdown each day whether the main task moved to done, or to blocked with a clear question. If that happens on most days, the system works. If it does not, either the slot is wrong or the task is still sized for a calendar you do not have.

I used to think defending focus time was slightly selfish, as if everyone else's questions were more legitimate than my need to think. That idea did not survive looking at what I actually produced on defended weeks versus the others. Put the hold on the calendar before you know what goes in it, say when it ends, and send the polite message the first time someone books over it. Most people will move. The ones who will not are telling you something useful too.