I don't write about food much, but I spent a weekend helping a friend coordinate catering for a 150-person event, and it turned out to be a capacity-planning problem in a chef's jacket. If you've ever sized a worker pool or argued about batch sizes, a lot of this will feel familiar.
Throughput is set by your slowest station, not your headcount
The naive assumption is "more cooks equals more food." But a kitchen has fixed stations: so many burners, so much oven space, one rice cooker of a given size. Past a point, extra people just contend for the same resources. It's Amdahl's law with steam. The real question is what your bottleneck station can push per hour.
Lead time is the real constraint
Some dishes are effectively precomputable — batch them ahead and hold them warm. Others degrade fast and have to be finished just-in-time or they're mush by service. Good caterers schedule backward from serving time, staging the make-ahead items and reserving scarce station-minutes for the things that can't wait. When I looked at how one small halal kitchen lays out its catering options across Toronto it read like a dependency graph: prep tasks with different shelf lives, scheduled so the critical path lands exactly at service.
Overprovision the cheap things, not the expensive ones
Rice, bread, and salad are your cheap horizontal scaling. Running out is embarrassing and easily avoided, so you overprovision. The expensive protein is where you forecast carefully, because waste there is real money. Same instinct as caching cheap computed results while staying stingy with costly external calls.
Failure modes are degradation, not crashes
A kitchen rarely goes down. It degrades: service slows, quality drops, the line backs up. The equivalent of graceful degradation is keeping a couple of dishes that hold well as a buffer, so one slow station doesn't stall the whole event. Plan the fallback before you need it.
None of this is groundbreaking if you do systems work. But it was a good reminder that capacity planning, batching, lead time, and failure modes aren't software ideas — they're just how any constrained system under a deadline behaves. Food is only the version you can eat.
Top comments (0)