When batching tasks helps and when it hurts

The review batch that cost someone a day

On one remote team I worked with, I decided to be disciplined about code review. Instead of reacting to every review request as it came in, I would do them all together at 16:00, once my own feature work for the day was done. It was a textbook batching move, and for my own focus it worked beautifully. My mornings got longer and calmer.

It took about two weeks for someone to point out the cost. A developer on the team was six hours ahead of me. She would open a pull request in her early afternoon, which was my morning, and then wait. My 16:00 batch landed after her working day had ended. So every review I batched cost her a full day of turnaround, and twice she had started a second branch on top of the unreviewed first one to avoid sitting idle, which made the eventual merge messier for both of us.

Nothing about the batch was wrong in isolation. It was a good batch in the wrong place. That is most of what I now think about batching: it is a trade, not a virtue, and you only find out what you traded when someone else's calendar meets yours.

It was a good batch in the wrong place.

What a batch actually buys you

Every kind of work has a setup cost. For email, it is loading your mental picture of who is waiting on what. For code review, it is getting into the reviewer's frame of mind and having the right repositories pulled. For invoicing, it is opening the accounting tool, finding last month's numbers, remembering how the export works. Do six of the same thing in a row and you pay that setup once instead of six times. That is the entire benefit, and it is a real one. The real cost of context switching works through what those setups add up to in a day.

Batching starts to hurt in two situations. The first is when the cluster eats the only window where deep work was possible. The second is when it becomes a hiding place: a pleasant, productive-feeling way of clearing small items while the hard thing never gets a continuous hour.

My working rule is short. Batch when the tasks share a mode and none of them need depth. Protect the primary block first, then put a time limit on the cluster.

The admin morning that ran to lunch

The hiding-place version is the one I fall into most. A typical plan: chat, email and ticket tidying from 09:00 to 10:30, then a protected feature block from 10:30 to 13:00.

That works perfectly when the batch actually ends at 10:30. What usually happens is "just one more thread," then a reply that needs a screenshot, then a ticket that turns out to need a quick look at the logs. At 11:45 I look up, and the feature block has become forty-five apologetic minutes before lunch. The calendar said batch, then depth. My behaviour said batch until depth was impossible.

The fix was not willpower. It was a cap. I now cap communication batches by both time and count: say sixty minutes and twenty threads, whichever comes first. If three threads are left, they wait for the next window. They were going to wait for something anyway. Better that they wait for a scheduled window than for my feature work to give up.

Work that batches well

Shallow communication. Status replies, scheduling, clarifications that do not need you to read a branch.

Reviews, carefully. Reading several diffs in one sitting is genuinely faster than one an hour with a full reload of your own work in between. But as the story above shows, the timing has to respect the people waiting. I now do a short review window at the start of my day, when colleagues further east are still online, and a second one mid-afternoon.

Operational chores. Invoices, expense photos, licence renewals, backup checks. None of these deserves to be interleaved with debugging.

Coordination clusters. Standup prep, stakeholder notes and a short sync belong next to each other, so the meeting-shaped part of the day happens in one place.

Each of these has a clear done state for the batch: inbox clear for this pass, review queue empty for this window, admin folder closed.

Work that does not

Small feature tickets "to get them out of the way." Five small tickets in a row can cost more than one medium feature, because each one loads a different corner of the codebase. They look like a batch because they are all small, but they do not share a mode. Five small tickets can be harder than one feature goes into why.

Debugging. Bugs do not respect batches. Parking a half-understood bug to "batch fixes on Thursday" usually means paying the full reload twice: once to understand it now, again to understand it on Thursday.

Hard thinking, saved up. Batching all the difficult design work into Friday afternoon rarely produces Friday afternoon thinking. It produces Friday afternoon.

Your low-priority batch while someone else's urgent thing waits. If a teammate is blocked on you, your carefully batched personal admin is now their delay. And if three people each wait for their own batch window to answer the same question, the team does the work three times. Avoiding duplicate async work is worth sorting out before you optimise your own queue.

Batching and sequencing are different tools

Sequencing is doing things in order without clustering them: A, then B, then C. Batching is A A A, then B B B. Some days need sequence. If I am taking one feature from branch to merge, reviews of my own pull request should happen as they arrive, because forcing them into a 16:00 slot just creates waiting inventory.

So I name the day in the plan. A batch day is for coordination and shallow work. A sequence day is for one thread, with reviews and replies handled as they come in. The days that go worst are the unnamed mixed ones, where I am half batching and half sequencing and end up with neither throughput nor responsiveness, and a vague sense of having failed at both.

Some chores want a weekly home

Some batches work better on a weekly rhythm than a daily one. I invoice on the last working day of the month, do sales follow-ups on Tuesdays, and keep a learning block on Thursday afternoons. The calendar looks oddly empty on other days for those categories, and that is the point: they already have somewhere to live.

For freelancers this matters more than it seems. Non-billable work with no home leaks into evenings, and that leak is structural, not a character flaw. Billable hours are lower than working hours puts some numbers on it.

A mixed freelance day

Say Client A needs three asset exports, Client B is owed a status update, and I have a proposal draft due for a prospective client.

The version that works: the proposal is the primary, fifty to ninety minutes, done first. Then one batch for all three of Client A's exports. Then one status update for Client B. Three blocks, three modes, each closed before the next.

The version I used to do: bounce between export dialogs and proposal paragraphs every ten minutes, because all of it felt small and I could "keep things moving." Things moved, in the sense that windows opened and closed. The proposal took the whole afternoon and read like it.

When to break a batch

Break the batch when new information changes priority: production is down, a security patch lands, a client deadline moves. Do not break it because the feature waiting after it is uncomfortable.

Also break it when an item turns out not to belong. A "quick question" email that needs you to read three services is not a communication task any more. Turn it into a ticket, schedule it as depth, and reply with when you will have an answer. Answering it inline during an admin batch is how a sixty-minute window becomes the morning.

One honest test helps me spot when batching has become avoidance. If my batch windows reliably get longer on days when the primary feels hard, I am not batching. I am procrastinating with good organisation. The question at shutdown is not "did I process thirty emails?" It is "did the checkout fix reach staging with notes on how to verify it?"

The order I keep coming back to

Name the primary before opening the inbox. Do the batch windows after the primary block, or after the primary is parked with a restart note. If a batch ends with items left, write the first one into the shutdown note so tomorrow's sweep starts there instead of rediscovering it. And if the list only ever grows, no amount of batching will rescue it; why your task list keeps growing is the better place to start.

Batching is one of the few productivity techniques that genuinely saves time. It just saves it by moving waiting around, and the waiting has to land somewhere. Before you batch anything, ask whose day the delay ends up in. If the answer is yours, fine. If it is a colleague six hours away, find a different slot.