The Systems Club sells operators the fourth Fundamental as the first, and every system it sells writes down an operation nobody designed, because a system can only execute a decision and nobody in the building has made the decisions yet.
The cry is everywhere. The operator’s biggest problem, the coaches say, is that he doesn’t have systems. A restaurant coach who bills himself as a restaurant systems expert tells him to video himself doing his job and have someone type it up. A template library sold through state restaurant associations hands him a labor schedule built for virtually any type of establishment and training manuals for every major position. A kitchen systems kit sells him a frame for pars, a prep list and a labor schedule, built from somebody else’s kitchen. It runs on the independent operator, who has no corporate design team behind him and is being told the binder is what he is missing. What it costs him is the restaurant he could have designed. He gets the one he already has, written down and made repeatable, or the one somebody else built, dropped into his building. Then the cast gets blamed when it doesn’t work. What is at stake is the order of his business. In my framework the order is causal, and [The Five Fundamentals] sets it: Perspective, Product, People, Performance, Profit. Systems live in Performance, which is where [Systems Architecture] sits. They come fourth because they execute what the first three decided, and when the first three were never decided, the systems have nothing to execute but the default.
That is Systems Slop: systems made in bulk for no restaurant in particular and sold as the fix for an operation nobody designed. It is the restaurant version of AI slop. Produced fast, produced everywhere, and produced for no one.
Their Own Words Give It Away
The strongest evidence comes from the people selling it, in their own words.
The coach. He tells operators what a system is: “everything you do that somebody else could be doing.” His method is to video yourself doing those tasks and have someone type it up. “BAM! Systems documented.” In another post he says to pick a pain point, write down the steps, then “record it and use a tool like ChatGPT to create a training document.” His book runs in this order: Do Less, Lead More, then Delegate and Trust, then Lead With Systems. His blog says to build systems first, then grow.
Look at what that method actually produces. A video of the owner doing his job records the operation as it already runs. Whatever was decided, whatever was never decided, and whatever the owner does out of habit all go on the tape. Typing it up doesn’t design anything. It makes the default repeatable. In my framework that is [Default Architecture]: the architecture an operation ends up with when its parts were never ruled from inside the building against what it is built to produce. The coach’s method is [Default Architecture] with a training document attached.
His homepage has moved partway. It now says the owner’s wall is “not a knowledge gap, not a market problem, not a team problem” but “a decision they’ve been avoiding,” and then: “Then we build the system around it. Not the other way around.” Read the decisions he gives as examples: “a menu that’s been slowly bleeding your numbers, a GM or KM who keeps promising and not delivering, or a walk-in full of product you’re never going to use.” Every one of them is a symptom. The decision is framed as the one that “would change the next ninety days.” Nothing on the page reads the value market or decides the experience, and it rules the market out as the problem before anyone has looked at it. Picking which symptom to build a system around is not deciding what the restaurant is.
The template library. It promises to help independent restaurants find success “without having to start from scratch.” Its labor scheduling template is for creating schedules and labor budgets “for virtually any type of food and beverage establishment, including full service, counter service, fine dining, bars, quick service, and banquet rooms.” Its systems page says “proven operational systems promote consistent, predictable guest experiences.” Its management training template links to “the most current best practices.” Through the state association listings, it sells employee training manual templates “for all major positions in tableservice and limited service restaurants.”
Starting from scratch is the job. The operator who never starts from scratch never decides what he is building. A labor schedule that works for a bar, a fine dining room and a quick service counter was built for none of them, because those three have nothing in common at seven o’clock on a Friday. And read the systems line again. It has the order backward. It says the systems produce the experience. In a restaurant the experience comes first, and the systems exist to execute it.
The kit. A kitchen systems kit sells recipe and plate costing alongside a frame for order guide pars, a prep list and a labor schedule. The costing will work in any kitchen. Enter the price once and every plate updates. That is math, and math travels. But costing only tells you what each plate costs. It doesn’t tell you which plates to keep, reprice, rework or cut. That’s menu engineering, and most of the tools in these kits are plate cost tools that stop before it. Even menu engineering is only math. Which plates stay is a Product decision, made against the read of who is ordering them, or the operator cuts the plate his Guests came for. The pars, the prep list and the labor schedule don’t travel. They were built against one kitchen’s menu, volume and cast. Put them in another kitchen and the pars are wrong, the prep is wrong, and the labor schedule doesn’t know where that kitchen gets stuck.
That is the line the whole Systems Club misses. A tool works the same in any kitchen because it is math. A system only works in the kitchen it was built for, because it executes decisions that kitchen made.
The Diagnosis Was Borrowed
Start with Perspective, because that is where the slop starts.
Perspective is the read of the value market: who this restaurant is for, what they value, and what experience will win with them. Nothing about “lack of systems” comes from that read. It is a diagnosis made before anyone looked at the operator’s market, his Guests or his building, and it is the same diagnosis for every operator the coach talks to. It can’t be wrong for any of them, which is how you know it wasn’t made for any of them.
The operator who accepts it never runs his own read. He is told his problem is the binder, so he never asks the questions that would tell him what the binder should say. Who is coming in? What are they choosing us for? What experience do we have to deliver to keep them? When the diagnosis arrives before the read, the read never happens.
Nobody Designed The Experience
Product is the experience, the concept that delivers it, and the volume design: how that concept operates at 40 covers, at 400 and with three servers instead of six. Product is decided by the operator, against the read. It is never decided by a video of what the restaurant already does.
The coach’s method skips Product completely. The video doesn’t ask what the experience should be. It records what it is. If the experience was never designed, the tape captures the default, and the training document teaches the cast to repeat it. If the owner happens to have good instincts, the document captures some of them along with every habit he never questioned.
The template library replaces Product with someone else’s. “Consistent, predictable guest experiences” is an experience. It is the right one for some concepts and the wrong one for others. When it comes in a template, the operator gets that experience without ever choosing it. Every restaurant that buys the same template gets the same experience, which is how the template works as a [Sameness Machine]: built outside the building, distributed identically into every building that buys it, producing the same operation everywhere it runs.
Volume design gets skipped too. The template has no idea what happens to this concept when the room is full and the kitchen is a cook short, because nobody asked. It can’t tell the operator where he should lose Guests when he can’t serve them all. That is a Product decision, and nobody made it.
The Roles Were Written Before Anyone Was Hired
People comes before Performance for a reason. If you are building an experience, only a certain type of person can give a Guest the experiential feeling that experience depends on. In People, the operator designs the experiential roles for the experience he decided on, then hires the best person to fill each one.
The Systems Club does it backward. Training manual templates for all major positions are roles somebody else designed, for an experience that isn’t yours, before you have hired anyone. The coach’s definition goes further. A system is “everything you do that somebody else could be doing.” That treats the person as the interchangeable part. Procedures written before the hire assume interchangeable people, and in a restaurant whose experience depends on who is delivering it, nobody is interchangeable.
That is how the cast ends up blamed. The procedure was written for a generic server in a generic restaurant. The server you hired is a specific person working a specific room. When the procedure doesn’t fit the room, the gap shows up as the server not following it.
Even Where Systems Belong, These Fail
Performance is where systems live: the procedures, standards, pars, prep lists, labor schedules and checklists that organize how the cast executes the experience. Performance also holds the tools, and the calibration of each shift to how the concept is supposed to be executed. This is the one Fundamental where the Systems Club is selling the right category of thing. It still fails, because it arrives without the three decisions it was supposed to execute.
That is the problem with a best practice. A best practice is a common practice in restaurants that has to be calibrated to the concept it is applied in. Applied as-is, it fails three ways. It delivers someone else’s experience. It breaks at volumes it was never built for. And when it doesn’t work, the cast gets blamed for not following it.
The template labor schedule shows all three. It was built for virtually any type of establishment, so it delivers whatever experience its averages assume. It doesn’t know your Friday volume or the hour your kitchen backs up, so it breaks the first time the room fills. And when the shift falls apart, the operator looks at the schedule, sees that it was followed, and decides the cast is the problem.
“Build systems first, then grow” makes it worse. Growth multiplies whatever the systems encode. If they encode the default, growth spreads the default to every new room.
Some operators will say the system worked. Food cost came down, the opening checklist got done, and the owner finally got a night off. That’s real. But look at where it came from. If food cost came down, the costing didn’t do that. It showed him what each plate really cost, and he changed the price or the portion. That was a tool and a decision, not a system. If the owner’s instincts happen to fit his market, the video wrote down habits that happen to work, and the coach got the credit for them. If the restaurant was running with nothing written down at all, writing anything down stops some of the waste and rework. In every case the gain shows up as cost recovered, not Guests coming back. The restaurant gets better at being what it already is, including everything wrong with it. The numbers improve, but not enough. The operator takes the improvement as proof the diagnosis was right, so instead of going back to read his market and decide his experience, he buys the next system. So ask what moved. If it was cost, the system did its job. If the Guests still aren’t coming back, the problem was never the system.
Three Tests For Any System You Are Sold
The Design Step Test. Open the seller’s site and look for the step where he reads your value market and helps you decide your experience before he sells you a system. If there isn’t one, he is selling Performance to an operation that hasn’t decided Perspective, Product or People. If the first step is picking a pain point, that is a symptom, not a design step.
The Any-Type Test. Read who the system is for. If it says any type of restaurant, every position, or virtually any establishment, it was built for no restaurant in particular. It is a tool if it is math. If it isn’t math, it is Systems Slop.
The Hire Test. Ask whether the role was written before or after the person was hired, and for whose experience. A position template written for every restaurant fails before it starts.
The Kingdom For A System
Shakespeare’s Richard III offers his kingdom for a horse, and the horse never comes. The operator in the Systems Club makes the same trade. He hands over the design of his restaurant for a system, and he gets one that executes nothing he decided. On the scorecard it shows up as labor that doesn’t fit the volume, food cost that drifts because the pars were somebody else’s, and Guests who don’t come back for an experience nobody chose. Profit holds no decisions. It reads what the first four Fundamentals decided or left to default, and whatever isn’t good enough there sends the operator back to re-read the Fundamental that produced it. The Systems Club sends him to the fourth one every time, so the default stays in place and the Guests still don’t come back. The hard work isn’t building systems. It’s the read, the concept design and the cast. Systems are what make that work pay off every shift. That’s also why the Systems Club sells systems. It’s the easy part to package, and the hard work can’t be put in a binder. A system is not the kingdom. It is how you run the kingdom once you have decided what it is.
What You Do Monday Morning
Pull three systems you bought, borrowed or typed up from a video: the labor schedule template, a position training manual and an opening checklist. Next to each one, write the decision it executes and the Fundamental that made it, in your building. The labor schedule executes a volume decision: how this concept runs at Friday’s covers. The training manual executes a role you designed for your experience. The checklist executes a standard you set for the experience. If the answer for any of them is that it came with the template, or that it is what you were already doing, the system is executing a decision nobody made. Don’t fix the system. Go upstream, make the decision, and then rewrite the system to execute it.
To understand the ideal state, go to Restaurant Physics.
Digging Deeper
Positions on the record:
- The First Rule Of Systems Club Is You Don’t Talk About Systems First! — https://physics.jeffreysummers.com/the-first-rule-of-systems-club-is-you-dont-talk-about-systems-first/
- Forms, Templates & Other Nonsense — https://jeffreysummers.com/forms-templates-other-nonsense/
- Best Practices Usually Aren’t — https://physics.jeffreysummers.com/best-practices-usually-arent/
- The Counsel Class Cannot Read The Template — https://hacksterism.jeffreysummers.com/the-counsel-class-cannot-read-the-template/
- Why Most Restaurant Consulting Makes It Worse — https://jeffreysummers.com/why-most-restaurant-consulting-makes-it-worse/
- Systems Architecture — https://kb.jeffreysummers.com/
- The Five Fundamentals — https://kb.jeffreysummers.com/
Terms used in this piece: Default Architecture, Sameness Machine, Systems Architecture, The Five Fundamentals. Definitions in the Knowledge Base.
Discover more from Hacksterism
Subscribe to get the latest posts sent to your email.
