Here's a counterintuitive truth that kills efficiency in most organizations: larger batches feel productive but actually slow everything down.
You process 100 invoices at once. You manufacture parts in batches of 500. You deploy code every two weeks instead of daily. It feels efficient. Economies of scale, right?
Wrong. You're killing your flow.
Why Batching Feels Right (But Isn't)
Batching appeals to our intuition. If setup time is 30 minutes whether you process 10 units or 100, why not do 100? The math seems obvious.
But this calculation ignores the real costs:
- Wait time explodes. The first item in your batch waits for the last item to finish.
- WIP inventory skyrockets. Large batches mean more stuff sitting around.
- Defects multiply. Process 100 units wrong, and you've got 100 defective units.
- Flexibility dies. Can't respond to changes mid-batch.
The Math That Changes Everything
Let's say you have a three-step process, each taking 1 minute per unit:
Batch of 10:
- Step 1 processes all 10: 10 minutes
- Wait for batch to complete
- Step 2 processes all 10: 10 minutes
- Wait again
- Step 3 processes all 10: 10 minutes
- First unit complete: 30 minutes
- All units complete: 30 minutes
Single-piece flow:
- Unit 1 through all three steps: 3 minutes
- First unit complete: 3 minutes
- All 10 units complete: 12 minutes (overlapping)
The first customer gets their item in 3 minutes instead of 30. That's a 10x improvement in response time.
The Batch Size Sweet Spot
I'm not saying batch size should always be one. Sometimes setup costs genuinely require batching. The key is finding your optimal batch size — the point where setup efficiency and flow efficiency balance.
Here's the framework:
Optimal batch size decreases when:
- Setup times are low (or can be reduced)
- Holding costs are high
- Demand variability is high
- Quality feedback loops matter
- Customer response time is critical
Larger batches make sense when:
- Setup costs are truly unavoidable and massive
- Items have no individual identity (bulk commodities)
- Demand is perfectly stable and predictable
For most knowledge work and modern manufacturing? Smaller is better.
Real-World Impact
Toyota revolutionized manufacturing by obsessively reducing batch sizes. Their SMED (Single-Minute Exchange of Die) program focused on reducing setup times so smaller batches became economical.
Result? Faster response to demand, lower inventory costs, better quality, and competitive dominance.
In software, the same principle drives continuous deployment. Deploy daily (small batches) instead of monthly (large batches), and you get faster feedback, easier debugging, and quicker value delivery.
The Hidden Costs You're Not Counting
When evaluating batch sizes, most people only count:
- Setup time per batch
- Processing time per unit
What they miss:
- Wait time — inventory sitting between steps
- Space costs — storing work-in-progress
- Quality costs — defects found late in large batches
- Obsolescence risk — demand changes before batch completes
- Cash flow impact — money tied up in WIP
- Complexity costs — tracking and managing batches
Add these up, and "efficient" large batches suddenly look expensive.
Practical Steps to Reduce Batch Size
- Measure your current batch sizes. You can't improve what you don't measure.
- Calculate total cycle time — from first item in to last item out.
- Identify setup activities. What forces you to batch?
- Attack setup time. Often it's smaller than assumed.
- Test smaller batches. Pilot with half your current batch size.
- Measure again. Did lead time improve? Did throughput change?
The Question to Ask
Every time you see a batch, ask: "What's stopping us from making this smaller?"
The answer reveals improvement opportunities. High setup time? Focus there. Habit? Just try smaller. Transportation costs? Maybe batch for shipping but not processing.
Today's Action: Find one batch in your process. Calculate the wait time the first item experiences while the rest of the batch catches up. That wait time? It's pure waste. Start thinking about how to shrink it.
Ready to see how batch size affects your throughput? ProcessModel simulates your process with different batch configurations, showing you exactly where the sweet spot is. Try scenarios risk-free before changing your real process.