Menu Size vs Skill Reality

🎧 Beyond the Pass — Operator Podcast (1:53)

Oversized menus burnt out your chefs

Prefer reading? The full breakdown is below.

A 52-cover pub in Devon. Three head chefs in four years.

The owner blamed the talent market. Said good pub chefs were impossible to find. Said the industry was broken. Said he’d done everything right and the chefs kept leaving anyway.

When I sat down with him for the audit, the menu had 31 items. The kitchen team had four chefs. The senior chef had been at the pass on every single service for the last seven weeks.

The chefs weren’t leaving because the talent market was broken. They were leaving because the menu was structurally impossible to cook to standard with the team available. Each new head chef arrived, tried to hold the line for nine to fourteen months, burned out from carrying the spread, and quit.

The Devon owner thought he had a recruitment problem. He had a menu problem.

This is the most underdiagnosed pattern in UK pub kitchens. Operators benchmark cover counts, food costs, and labour percentages. They almost never benchmark the relationship between menu complexity and team capability. And when that relationship breaks, it doesn’t show up as a P&L issue. It shows up as a retention issue. Then as a quality issue. Then as a revenue issue, twelve months too late to react.

Every kitchen team has a maximum number of distinct dishes it can execute consistently at peak volume. Not theoretically. Operationally. The number where every plate goes out at the right temperature, with the right components, in the right time window, every service.

That ceiling isn’t set by talent. It’s set by technique bandwidth.

Technique bandwidth is the number of cooking methods the team has genuinely mastered. Not techniques they’ve seen, or trained in, or could do on a quiet Tuesday. Techniques they execute under pressure, to standard, without thinking. Sauté. Grill. Braise. Fry. Roast. Sous-vide. Bake. Smoke. Cure. Ferment.

Most pub teams genuinely own four to six of these. That’s not a criticism. That’s a realistic operational truth about a team of mixed-experience chefs working at pub volumes. The talented ones own more. The juniors own fewer. The team’s effective bandwidth is somewhere in the middle.

Here’s the working number I use when auditing:

Technique bandwidth × 2.5 = maximum useful menu size for that team.

A five-technique kitchen comfortably runs 12 to 13 items. A six-technique kitchen runs 14 to 16. A seven-technique kitchen runs 17 to 18. Push beyond that and the menu starts asking the team to operate outside its mastered range every service.

The Devon pub had a four-chef team with an effective technique bandwidth of about six. Their menu was 31 items. They were running roughly fourteen items above the ceiling.

That’s not a stretch. That’s a structural mismatch. Every chef on every service was being asked to execute techniques they hadn’t mastered, under time pressure, with no headspace to think. The senior chef was at the pass on every shift because nothing left the line at standard without his hands on it.

That isn’t sustainable for nine months, let alone four years.

Menus don’t get built oversized. They drift there over 18 to 24 months.

A new dish gets added for a specials night and stays because it sold well. A regular asks for an old favourite and it gets quietly added back. The owner takes a holiday in Spain and adds three Spanish-influenced dishes the following month. A supplier offers a deal on lamb so two new lamb dishes appear. A new chef brings a signature dish.

Each individual decision feels right at the time. Customers asked. The dish sold. Margin looked good. The menu as a whole has now drifted from 16 items to 28, and the kitchen team is the same size it was at 16.

The cost shows up as ticket time creep. Then spec drift. Then plates coming back. Then the head chef hovering at the pass on every service. Then the head chef leaving.

By the time the owner notices, the menu has been broken for six months, and the structural problem is being misdiagnosed as a people problem.

There’s a second number worth running alongside technique bandwidth. Distinct prep components.

Count every preparation that has to happen before service. Stocks, braises, reductions, pickles, doughs, sauces, garnishes, marinades, cures. Every preparation that takes labour time before plating. That’s your component count.

Then divide your menu items by your component count.

A 22-item menu built around 8 components has a leverage ratio of 2.75. Every component is doing real work across multiple dishes. That’s a menu built like a system.

A 22-item menu built around 18 separate components has a leverage ratio of 1.22. Almost every dish requires its own dedicated prep. That’s a menu built like a list. The kitchen has no leverage between dishes, and every new order is effectively a new build.

The Devon pub had 31 items running on 27 distinct components. Ratio of 1.15. Almost nothing shared. No leverage anywhere.

When we restructured around technique bandwidth, the menu came down to 18 items built on 6 components. Ratio of 3.0. Each component supported three dishes on average. Prep effort was now shared, not duplicated.

Same number of chefs. Same kitchen. Different system.

Before you run the numbers, here are the operational signals that almost always indicate menu overreach:

Ticket times stretch during regular service. Not peak. Regular. If a Wednesday with 30 covers produces 15-minute tickets, the menu is too complex for the team.

Plates come back to the pass. More than two or three returns per service is structural, not a one-off error.

Specials disappear. When there’s no prep capacity left for specials, the menu has consumed all available labour.

The head chef checks every plate. If quality assurance has to happen at the pass for every dish, the team can’t execute the menu independently. That’s a bandwidth overflow.

Three of these four happening on a regular basis means the menu is past the ceiling. You don’t have a team problem. You have a menu problem disguised as a team problem.

Three steps. Twenty minutes if you have a current menu and a notepad.

Step 1. Sit down with your head chef. Ask which cooking techniques the team can genuinely execute, under pressure, to standard, without supervision. Not techniques they know. Techniques they own. Count them honestly.

Step 2. Multiply by 2.5. That’s your maximum useful menu size. If your current menu is more than two or three items above that number, the structure is fighting the team.

Step 3. Count distinct prep components and divide your menu item count by the component count. Anything below 1.8 means almost no leverage. Anything above 2.5 means the menu is built like a system. The Devon pub started at 1.15 and ended at 3.0.

If your numbers come back over the ceiling, the question isn’t whether to cut the menu. It’s which dishes the kitchen can actually execute at standard, and which ones to retire so the rest can be cooked properly.

The Devon pub kept the same staff and the same supplier relationships. Ticket times dropped from 22 minutes to 12. Plate returns dropped to fewer than one per service. The head chef stopped working the pass on every shift, which freed him to develop seasonal specials instead of fighting the line.

Food cost moved from 34% to 31% because component leverage cut waste. Labour density moved from 1.9 to 2.6 covers per kitchen hour. Contribution margin per cover increased by £2.40 without raising a single price.

And the head chef who led the restructure is still there, eighteen months on. The first head chef to last more than fourteen months in the building.

Menu size isn’t a marketing decision. It’s a retention decision.

Next week in the pub series: The £12 to £15 pub main trap. Why price resistance at this threshold isn’t real, what customers actually respond to, and the pricing band where pub mains stop being structurally profitable.

Free 15-minute diagnostic that surfaces these numbers automatically here.