Batch processing for efficiency

You are paying a toll every time you switch, and you have never counted the tolls

There is a factory floor in your day that you have never noticed. Every time you check email between paragraphs of a report, every time you glance at Slack in the middle of a design session, every time you pause your analysis to respond to a quick administrative request, you are performing the cognitive equivalent of shutting down one machine, reconfiguring the tooling, running a single part, shutting down again, reconfiguring back to the original setup, and then trying to remember where you were in the original production run. In manufacturing, this would be recognized immediately as catastrophic inefficiency. In knowledge work, it is considered normal.

The previous lesson established the two-minute rule: if a task costs less to do than to manage, dispatch it immediately during your administrative windows. But that lesson left a structural question unanswered. How do you organize the administrative windows themselves? How do you decide when to sit down with your pile of small tasks, and how do you process them once you do? The two-minute rule is a decision heuristic for individual items. Batch processing is the scheduling architecture that makes the heuristic operational at scale.

The principle is this: group similar small tasks together and process them in a single dedicated block, so that the setup cost of engaging with that type of work is paid once instead of once per task. This sounds obvious. It is obvious. And almost nobody does it consistently, because the human instinct to handle things as they arrive is powerful enough to override what we know about efficiency.

The setup cost that nobody measures

Every type of task carries a setup cost — the time and cognitive effort required to enter the mental state where you can perform that task effectively. Replying to email requires loading the context of multiple ongoing conversations, recalling the status of various projects, and shifting into a communication mindset where tone and clarity matter. Processing invoices requires opening your accounting system, recalling your chart of accounts, and entering a detail-oriented analytical state. Making phone calls requires shifting into a verbal, interpersonal mode where you are thinking on your feet rather than composing carefully.

These setup costs are real but invisible. Nobody tracks them. Nobody measures the four minutes it takes to remember where you were in a financial reconciliation after checking a Slack notification. Nobody accounts for the seven minutes it takes to rebuild your mental model of a complex email thread after you stepped away to approve a purchase order. The task itself might take ninety seconds. The setup cost might take five minutes. And if you perform that type of task twelve times during the day, scattered across twelve different interruptions, you pay the five-minute setup cost twelve times — sixty minutes of overhead that produces zero output.

This is where manufacturing has a century of advantage over knowledge work. Shigeo Shingo, an industrial engineer at Toyota, spent decades studying setup times in manufacturing. His work, formalized in the late 1960s and published as the SMED system — Single Minute Exchange of Dies — addressed the problem of changeover time: the time required to reconfigure a machine between production runs. Before Shingo's work, die changes on stamping presses took hours. Manufacturers responded by running enormous batches — thousands of identical parts — to amortize that setup time across as many units as possible. Shingo's insight was that setup time itself could be dramatically reduced, allowing smaller batches without sacrificing efficiency. He reduced die changes from hours to minutes, sometimes to seconds.

The relevance to personal productivity is not the technique of reducing setup time — though that matters — but the underlying economic principle. Every production run has a fixed setup cost and a variable per-unit cost. The total cost per unit equals the per-unit cost plus the setup cost divided by the number of units in the batch. As batch size increases, the per-unit share of setup cost decreases. At a batch size of one — processing a single email, making a single phone call, handling a single administrative item — you bear the full setup cost for a single unit of output. At a batch size of twenty — processing all your emails at once, making all your phone calls in sequence, handling all administrative items in a single block — the same setup cost is divided across twenty units.

This is not a metaphor. This is arithmetic. If your email setup cost is four minutes (open inbox, scan for context, shift into communication mode) and your average email takes two minutes to process, then handling one email costs six minutes total. Handling twenty emails in a single batch costs four minutes of setup plus forty minutes of processing — forty-four minutes total, or 2.2 minutes per email. You have nearly tripled your email efficiency without writing a single word faster. The savings come entirely from paying the setup cost once instead of twenty times.

The context-switching tax, revisited

The setup cost argument is about time. There is a deeper cost that operates at the neurological level and is far more destructive: the cognitive switching penalty.

Gloria Mark and her colleagues at the University of California, Irvine, have spent over a decade studying interruptions in knowledge work environments. Their research, published across multiple papers from 2004 through the 2020s, established several findings that are directly relevant to batch processing. First, the average knowledge worker is interrupted or switches tasks every three to five minutes. Second, after an interruption, it takes an average of twenty-three minutes and fifteen seconds to return to the original task at the same level of engagement. Third — and this is the finding that connects most directly to batch processing — the cost of switching is not constant. It varies with the similarity of the tasks being switched between.

Switching between two similar tasks — from one email reply to another, from one data entry to another, from one phone call to another — incurs a much lower switching cost than switching between dissimilar tasks. The reason is that similar tasks share cognitive context. The mental models, vocabulary, tools, and modes of thinking overlap. When you switch from email to email, you stay in "communication mode." Your brain does not need to rebuild a fundamentally different cognitive framework. When you switch from email to data analysis, you are dismantling one framework and constructing another. That reconstruction is expensive.

This is the neurological foundation of batch processing. By grouping similar tasks into a single block, you keep the cognitive framework stable across multiple items. The setup cost — loading the relevant context, entering the appropriate mental mode, activating the right tools — is paid once at the beginning of the block and maintained throughout. Each subsequent item in the batch benefits from the context that the previous item already established. The twentieth email in a batch is processed faster than the first, because by the twentieth email you are deeply fluent in the conversational threads, the project statuses, and the communication patterns that make fast, accurate replies possible.

What the email researchers found

In 2015, Kostadin Kushlev and Elizabeth Dunn at the University of British Columbia published an experiment that tested the batch processing principle directly, using email as the test case. They randomly assigned participants to one of two conditions for one week. In the first condition, participants checked email as often as they wanted — the normal, reactive pattern. In the second condition, participants limited their email checking to three times per day, processing everything in batches.

The results were significant across multiple measures. Participants in the batching condition reported lower daily stress, as measured by validated stress scales. They also reported higher positive affect and a greater sense of being in control of their day. Crucially, there was no measurable decrease in their responsiveness on important items — the things that actually needed timely replies still received them. The stress reduction came not from doing less email, but from eliminating the constant low-level vigilance of monitoring the inbox throughout the day.

This finding aligns with a broader pattern in the attention research literature. The cost of continuous monitoring is not primarily the time spent checking. It is the attentional fragmentation that checking produces. When you know you might check email at any moment, you never fully commit to the task at hand. A fraction of your attention remains allocated to the inbox, monitoring for the ping, the badge, the notification. This residual attention — what Sophie Leroy at the University of Washington has called "attention residue" — degrades performance on the primary task even when no interruption actually occurs. The mere possibility of interruption is enough to reduce cognitive depth.

Batch processing eliminates this residual attention allocation. When you know that email will be handled at 1 PM and not before, you can fully commit to your deep work block from 9 AM to 1 PM. The inbox is not being ignored — it has a scheduled processing time. But between processing times, it is closed. Your attention is undivided. The quality of your focused work increases not because you are trying harder, but because you are no longer leaking cognitive resources toward an inbox that does not need monitoring.

Cal Newport and the shallow work containment principle

Cal Newport, in "Deep Work" published in 2016, formalized a principle that extends batch processing beyond email to all categories of shallow work. Newport observed that knowledge workers spend the majority of their time on tasks that are logistically necessary but cognitively undemanding: email, scheduling, administrative approvals, status updates, form-filling, routine correspondence. He called this "shallow work" and distinguished it from "deep work" — the cognitively demanding, focused, high-value activities that produce the outcomes people actually care about.

Newport's key argument was not that shallow work should be eliminated. It cannot be. Organizations require communication, coordination, and administration. His argument was that shallow work should be contained — batched into defined blocks that occupy a bounded portion of the day, so that the remaining time is available for uninterrupted deep work. Without containment, shallow work expands to fill all available time, because it arrives continuously and each individual item feels urgent enough to warrant immediate attention. The sum of individually reasonable interruptions is an entirely unreasonable day.

The connection to Manager time versus maker time — manager time versus maker time — is structural. Paul Graham's original distinction between manager schedules (organized in hourly blocks, optimized for meetings and decisions) and maker schedules (organized in half-day blocks, optimized for sustained creative focus) maps directly onto the batch processing principle. Shallow work operates on a manager schedule — it can be handled in small increments scattered throughout the day. Deep work operates on a maker schedule — it requires large, uninterrupted blocks. Batch processing is the mechanism that converts a manager-style day (interrupted every few minutes by shallow tasks) into a maker-style day (long uninterrupted blocks punctuated by short, dense administrative sessions).

The practical architecture looks something like this. You designate two or three administrative windows per day — perhaps thirty minutes in the morning, thirty minutes after lunch, and thirty minutes at the end of the day. During these windows, you process all accumulated shallow work in batches organized by category: email first, then Slack, then administrative approvals, then scheduling. Outside these windows, you do deep work. Incoming shallow tasks are captured — written down, added to a list, dropped into an inbox — but not processed. The capture takes seconds. The processing waits for the next administrative window.

The batch size tradeoff: efficiency versus responsiveness

Here is where batch processing encounters its fundamental tension, and where naive application of the principle causes real damage.

Larger batches are more efficient. If you check email once per day instead of three times, you pay the setup cost once instead of three times. You spend less total time on email. Your deep work blocks are longer and less fragmented. On pure efficiency grounds, the optimal strategy is to batch as aggressively as possible — check email once per week, run all errands in a single monthly trip, make all phone calls on one afternoon per month.

But efficiency is not the only variable. Responsiveness matters. Relationships depend on timely communication. Opportunities have expiration dates. Some urgent items genuinely cannot wait twenty-four hours, let alone a week. A client who sends a time-sensitive question at 10 AM and receives a reply at 5 PM has experienced a five-hour delay that may be completely acceptable. The same client waiting until the following morning may feel neglected. The same client waiting a week has probably found someone else.

This is the anti-pattern of batch processing: batching so aggressively that the delay between batches exceeds the reasonable response window for your context. The optimal batch frequency is not "as infrequent as possible." It is "infrequent enough to create meaningful uninterrupted blocks, frequent enough to meet the legitimate responsiveness expectations of your stakeholders."

For most knowledge workers, the sweet spot for email batching is two to four times per day. This creates blocks of two to four hours between checks — long enough for meaningful deep work, short enough that urgent items are addressed within a few hours. For instant messaging, the sweet spot might be once per hour during collaborative periods and not at all during deep work blocks. For physical errands, once or twice per week. For phone calls, one dedicated block per day or every other day. The specific frequencies depend on your role, your relationships, and your industry. The principle is universal: batch as much as your context allows, but not more.

The failure to calibrate batch frequency to context is how batch processing becomes a productivity ideology rather than a practical tool. Tim Ferriss, in "The 4-Hour Workweek" published in 2007, popularized extreme email batching — checking email once per day, or even once per week — as a lifestyle design strategy. For Ferriss's specific context (a self-employed entrepreneur with assistants handling urgent matters), this was effective. For a project manager with a team that depends on timely communication, it would be destructive. The principle is sound. The specific parameter must be calibrated to your reality, not imported from someone else's.

Batching categories, not just timing

The subtlety that separates effective batching from ineffective batching is categorical coherence. It is not enough to group all small tasks into a single block. The tasks within the block must be similar enough to share cognitive context.

Consider two versions of a ninety-minute administrative block. In the first version, you handle tasks in the order they arrived: reply to an email, reconcile an expense report, make a phone call, update a project tracker, reply to another email, schedule a meeting, process an invoice, reply to a third email. Each transition between task types requires a context switch — not as severe as switching from deep work to shallow work, but real enough to accumulate. You shift between written communication, financial analysis, verbal interaction, project management, and scheduling six or seven times in ninety minutes.

In the second version, you organize the same tasks by category: first, all email replies in sequence (fifteen minutes). Then all financial tasks — expense report and invoice — in sequence (twenty minutes). Then all scheduling and project tracking tasks in sequence (fifteen minutes). Then the phone call (ten minutes). The total work is identical. The total time is shorter, because you paid fewer context-switching penalties. But more importantly, the quality of each category is higher. By the fourth email in a row, you are composing faster and more accurately. By the second financial item, your accounting context is fully loaded. The categorical coherence of the batch amplifies the efficiency that temporal batching alone provides.

This connects directly to Sequential versus parallel steps — sequential versus parallel steps. Batching is, at its core, a decision to process similar items in series rather than interleaving them with dissimilar items in a pseudo-parallel fashion. The lesson on sequential versus parallel steps established that some workflows benefit from parallel execution. Batch processing is the complementary insight: some workflows benefit from serial execution within categories. The interleaved pattern — email, expense, phone, email, project, email — looks parallel but performs worse than either pure serial or pure parallel, because it pays switching costs at every transition without gaining the throughput benefits of genuine parallelism.

The physical world already knew this

Before knowledge workers discovered batching, the physical world had been practicing it for millennia. A baker does not make one loaf, then one cake, then one loaf, then one pastry. The baker makes all the bread in the morning — same oven temperature, same tools, same dough-handling mindset — and then switches to pastries in the afternoon. A farmer does not plant one row, then harvest a different row, then plant a third row. Planting happens in planting season. Harvesting happens in harvest season. The setup costs are obvious: preheating ovens, preparing fields, configuring equipment. Interleaving would be absurd.

Errands provide the most intuitive personal example. You do not drive to the post office, return home, drive to the grocery store, return home, drive to the dry cleaner, return home, and drive to the hardware store. You make one trip and chain all the errands together. The setup cost — getting in the car, driving to the commercial district, finding parking — is paid once. Each subsequent errand is nearly free in terms of travel overhead. The batch is so obviously efficient that it requires no persuasion. Nobody needs to be convinced to batch errands. The physical cost of not batching is too visible to ignore.

The tragedy of knowledge work is that the setup costs are cognitive rather than physical, which makes them invisible. You do not feel yourself "driving home" between email and expense reconciliation. You do not notice the seven minutes of context reloading when you return to your analysis after checking Slack. The cost is real — it shows up in your total time, your error rate, your fatigue at the end of the day — but it does not look like driving across town and back. It looks like nothing. And so you pay it over and over, all day, every day, without recognizing that you are paying it at all.

The third brain: AI as batch processing accelerator

AI changes batch processing in two significant ways. First, it increases the throughput of each batch by handling the mechanical components of task execution. Second, it can serve as the sorting and categorization layer that organizes incoming tasks into batch-ready categories.

On the first point: during an email batching session, a significant fraction of your time is spent on replies that are routine — confirmations, acknowledgments, standard responses, information forwarding. AI can draft these responses in seconds, leaving you to review, adjust, and send. The effect is that your thirty-minute email batch now processes forty items instead of twenty, because the mechanical work of composing routine messages has been compressed. The setup cost is the same — you still open the inbox, load context, and enter communication mode once — but the throughput within the batch has doubled.

On the second point: one of the frictions that discourages batching is the sorting overhead. Incoming tasks arrive in a jumbled stream — an email here, a Slack message there, an administrative request, a scheduling query. Organizing these into batch-ready categories requires a triage step that many people skip because it feels like extra work. AI can perform this triage automatically. It can scan your accumulated inputs, classify them by category (communication, financial, scheduling, project management), and present them as pre-sorted batches ready for sequential processing. The barrier to batching drops because the organizational overhead that precedes the batch has been automated.

There is a third application that connects to the broader trajectory of this phase. AI can monitor your task-handling patterns and identify where you are failing to batch. If your digital tools show that you checked email thirty-eight times yesterday, each time processing one or two items, an AI can flag this pattern and suggest consolidation. It can calculate the approximate context-switching cost you incurred and contrast it with the cost you would have incurred under a three-times-per-day batch schedule. The feedback loop — seeing the actual cost of non-batching in concrete numbers — is often what convinces people to change a habit that abstract advice alone cannot shift.

From dispatch heuristic to scheduling architecture

The two-minute rule from The two-minute rule for small tasks tells you what to do with each individual task. Batch processing tells you when and how to create the conditions under which those decisions are made. The two-minute rule without batch processing becomes a license for reactive interruption — handling every small thing the moment it appears, fragmenting your day into a stream of micro-completions. Batch processing without the two-minute rule becomes an overly rigid administrative session where trivial items that should be dispatched in seconds are instead deliberated and deferred.

Together, they form the operational foundation of a time system that respects both efficiency and focus. You designate administrative windows. During those windows, you open a batch of similar tasks and process them sequentially. For each task, you apply the two-minute rule: if it takes less time to do than to manage, do it now. If it takes more, defer it to an appropriate time block. When the batch is complete, you close the window and return to deep work. The shallow work is contained. The deep work is protected. The setup costs are minimized. The context switches are bounded.

This is the architecture that the next lesson — Meeting hygiene, meeting hygiene — extends into collaborative territory. Meetings are the one category of work that resists batching on your own terms, because they involve other people whose schedules constrain yours. Meeting hygiene protocols address how to apply the same principles — minimize setup costs, protect context, create clear boundaries, ensure that the time spent in meetings produces outputs proportional to the time consumed. If batch processing is how you contain your own shallow work, meeting hygiene is how you contain the shallow work that other people's calendars impose on yours.

You have been paying a toll every time you switch. Now you know how to count the tolls. And once you count them, you will stop paying most of them — not by doing less work, but by doing the same work in a sequence that respects the economics of your own attention.