Why Most Restaurant Consulting Makes It Worse

You hired somebody. Maybe more than once. They came in, they looked at the numbers, they ran a menu pass or built a scorecard or rewrote the training, they presented something bound, and for a quarter or two things moved. Then it settled back, or it settled somewhere worse, and you were left holding a binder and the suspicion that you had paid to be told what you already knew.

The industry has its explanation ready. You picked the wrong one. There are a lot of amateurs in this trade, credentials are self-issued, and the person with the biggest following is not necessarily the one who has built anything. All of that is true, and I have written about it elsewhere at length, and it is not what this piece is about.

This piece is about the other case, which is more common and much harder to see. The consultant was good. The craft was real. The menu work was competent, the labor model was sound, the systems were well built, and the operation came out worse anyway.

That happens for a reason, and the reason is not the consultant’s ability. It is what the work was installed on top of, and what nothing in the structure of a normal engagement requires anybody to examine.

Why That Is Not Sour Grapes

The obvious read on a consultant criticizing consulting is that he is clearing the field. So take my incentive out of it and test the claim on your own history instead.

Think about the best advisory work anybody ever did in your operation. Not the worst — the best. The engagement where the person clearly knew the craft, the deliverable was genuinely good, and you would recommend them. Now ask what your operation is capable of today that it was not capable of before they arrived. Not what improved for a period. What it can now do that it could not do before, without them, and without the dose being repeated.

For most operators the honest answer is nothing, and that answer has nothing to do with whether the consultant was any good. It has to do with the fact that the engagement was never scoped to produce capability. It was scoped to produce a deliverable. Those are different products, and only one of them survives the invoice.

That is why I do not scope engagements to deliverables. I scope them to what your operation can do when I leave.

The Deliverable Gets Chosen Before The Diagnosis

Here is the sequence in an ordinary engagement. You notice a problem. You form a theory about what would fix it. You go looking for someone who does that thing. You describe the problem in the vocabulary of the fix you already picked. They scope the work to the thing they do. Then they do it, competently.

Every step of that is reasonable and the whole sequence is upside down. The diagnosis was made by the person with the least distance from the problem, before any diagnostic work happened, and then everybody downstream was hired to execute it. The consultant did not diagnose your operation. He confirmed the scope you wrote, because the scope you wrote is what the proposal had to answer to win.

Watch how it shows up in the language. Labor is high, so you look for someone who does labor optimization. The menu feels tired, so you look for menu engineering. People keep quitting, so you look for a retention program. In each case the noun in your search is the intervention, not the symptom, and definitely not the cause. By the time anyone qualified is in the room, the answer has already been decided by the least-informed read in the process, which is the one taken from inside the problem.

The competent consultant then does exactly what he was hired to do. Labor comes down. The menu gets re-engineered. The retention program goes in. And the mechanism that produced the symptom is untouched, because nobody was paid to go looking for it.

That is why I will not accept a scope written as a deliverable. The first thing I do is refuse the frame you arrived with, which is an uncomfortable way to start and the only honest one.

Discovery Is Priced As Overhead

There is a structural reason diagnosis loses, and it is not that consultants are lazy. It is that discovery is the part of the engagement nobody wants to pay for.

You have seen the proposals. Discovery is phase one, it is two weeks, it is the cheapest line on the page, and it exists mostly to justify the phases after it. Both parties have an incentive to compress it. You want to get to the work. The consultant wants to get to the billable build. Discovery is the only phase that might conclude that the rest of the proposal should not happen, which makes it the phase with negative expected value for the person who wrote the proposal.

So the trade prices its most important work as its cheapest, and then everybody acts surprised when engagements solve the wrong problem with real skill.

Notice what that does to the shape of the answer. A two-week discovery can find symptoms, read a P&L, walk a shift, and interview a handful of people. It cannot find an architecture. Architecture shows up in the seams between layers, in what the reward structure pays for versus what the Guest contract promises, in the workarounds people have built to make a wrong system function. Those are visible over periods, not in a fortnight, and they are invisible entirely to anyone who came in already holding the deliverable.

That is why my discovery is not a phase. It is the engagement, and everything after it is a consequence rather than a plan.

Competence Is An Accelerant, Not A Correction

This is the mechanism underneath all of it and it is worth stating plainly. Skill applied inside a wrong architecture does not correct the architecture. It completes it.

A well-built system installed on a transactional architecture makes that architecture more efficient at producing the outcome it was always going to produce. The labor model that works as designed removes the capability that was absorbing your service failures. The scorecard that works as designed tells your cast, unambiguously and every single shift, that throughput is what gets measured. The retention program that works as designed pays people to stay in a role that was never going to develop them. Nothing failed. Everything worked, and the working is the problem.

Which means the quality of the consultant is not a safety mechanism. It is a multiplier on whatever the architecture already was. A mediocre engagement is a small dose of the wrong thing. An excellent engagement is a large dose, well distributed, across every station, on schedule. The operator who hires the best people and implements their advice completely gets to the destination faster than the one who half-implements advice from someone ordinary.

I know how that sounds coming from someone in this trade, and I am not going to soften it. It indicts most of what my industry sells. Systems, standards, scorecards, dashboards, playbooks, training modules, technology stacks, brand refreshes, culture programs. All real craft. All accelerant when installed on an architecture nobody chose.

That is why I gate every piece of execution work behind the architectural question, which means I will sometimes refuse to sell you the thing you called me to buy, and I will lose the engagement over it.

Somebody Else’s Answer Arrives Without Its Reasons

The second mechanism is transfer. Most advice in this business is a solution that worked somewhere else, moved without the conditions that made it work.

The pattern is easy to spot once you know the shape. A large operator with capital, scale, data infrastructure, and a purpose-built organization does something. It works, for them, because of everything underneath it that never gets mentioned. The move gets written up. It becomes counsel. It arrives in your operation as a best practice, stripped of the architecture that produced it, and you are handed the visible part and none of the load-bearing part.

The loyalty program is the cleanest example. So is the delivery strategy, the limited-time offer calendar, the tiered pricing move, the technology stack, and every culture program that came out of an organization with a full training department. None of those are frauds. They are answers to questions your operation is not asking, built on foundations your operation does not have.

The vocabulary transfers even more easily than the tactic, which is worse. You get relational language installed on a transactional engine, hospitality words attached to a throughput reward structure, and community used as a marketing register rather than as an obligation. The words arrive intact and the obligations do not come with them.

That is why I test any recommendation against your operation’s architecture before I care whether it worked elsewhere. If it needs a foundation you do not have, it is not advice, it is a story about somebody else.

Benchmarks Import The Scorecard You Are Trying To Escape

Almost every engagement in this business is measured against industry norms, and almost nobody asks what those norms are norms of.

Every benchmark table in this trade was built out of transactional operations reporting transactional metrics. Cost percentages, turn times, average check, labor as a percentage of sales, sales per square foot, cover counts. Real numbers, all of them, and every single one measures accumulation. There is no line in any standard reporting format for capability built, trust accrued, capability retained, or the Guest’s willingness to forgive a mistake.

So when a consultant benchmarks you, the definition of success arrives with the spreadsheet. A relational operation reads as an underperforming transactional operation on every instrument, permanently, even while it is winning, because the instruments cannot see what it is producing. And the recommendation that follows from a benchmark gap is always the same recommendation: close the gap. Which means recalibrate toward the norm. Which means recalibrate toward Road 1, monthly, forever.

An engagement that imports the transactional scorecard has decided the architecture question before the first meeting, and neither party notices, because a benchmark does not feel like a philosophical position. It feels like arithmetic.

That is why I establish what your operation is built to produce before I will look at a comparison, and why I will tell you when a number that reads badly is the correct number for the architecture you chose.

The Retainer Pays For Dependence

Look at what a standing engagement rewards. Monthly fee, ongoing advisory, quarterly reviews, a call whenever you need one. The consultant is paid for continuing to be needed. Nothing in that structure pays for the moment you stop needing him, and quite a lot in it argues against that moment arriving.

I am not accusing anyone of running that deliberately. Incentives do not require intent. If your revenue depends on being in the room, you will build engagements that require you in the room, and you will experience that as thoroughness. The operator experiences it as support. Both readings are sincere and the outcome is the same: capability that lives in the advisor instead of in the operation.

That is the same mechanism as everything else in my work, run on you instead of on your Guest. Something arrives carrying value, gets converted into a monthly position, and the spread is the profit. It is arbitrage with the operator as the counterparty.

So my engagements end. Not because I am generous — because an engagement that does not end has installed dependence rather than capacity, and dependence is the thing I am supposed to be treating. If I have to stay, I failed, and I would rather say that out loud in advance than discover we both quietly preferred the alternative.

You Cannot Outsource The Read

The last one is the operator’s half, and it is the part no consultant can fix for you.

When you hire someone to tell you what to do about your operation, you are not buying labor. You are handing over the read — the judgment about what is actually happening and why. That is the one part of the job that cannot be delegated, because it is the part that decides everything else. A schedule can be delegated. A menu pass can be delegated. Your read cannot, because whoever holds it holds the architecture, and if it is not you then your operation is being architected by someone whose engagement has an end date.

This is why the same advice produces opposite results in two operations. The operator who holds his own read receives a recommendation as input, tests it against what he knows the operation is built to produce, and takes the part that fits. The operator who has handed the read over receives a recommendation as an instruction, implements it faithfully, and has no way to detect that it was wrong for him until the period closes.

That is why every engagement I take ends with your read stronger rather than my recommendations installed, and why I would rather leave you with a question you can run yourself than an answer you have to trust me for.

The Diagnostic

Run these on anybody you are about to hire, including me. Each has a specific move and a plain read.

Test one — the refusal test. Ask what they have refused to sell in the last year and to whom. If nothing comes back, or it comes back as a story about a client who was not a good fit, they have never gated execution behind diagnosis. Everybody who does gets fired for it occasionally and can name the occasion.

Test two — the exit test. Ask what the operation will be able to do without them when the engagement ends, in specific terms, and ask what would make them recommend ending it early. An engagement with no described end has already answered the dependence question.

Test three — the diagnosis-order test. Notice whether the proposal names your problem or their product. If the scope you wrote came back as the scope they proposed, you have hired an executor of your own diagnosis and you are paying consultant rates for it.

Test four — the transfer test. For every recommendation, ask what has to be true in the operation for it to work, and whether those things are true here. Any advice that cannot answer that question is a story about another operation.

Test five — the scorecard test. Ask how success will be measured and where the measures come from. If every one of them is an industry norm, the engagement has decided your architecture before it started.

Test six — the seam test. Ask them what your reward structure pays your cast for and whether that matches what your Guest contract promises. If they cannot answer after discovery, discovery did not reach the architecture.

Test seven — the read test. At the end, ask yourself whether you understand your operation better or simply have more instructions. More instructions and no better understanding is a transfer of the read, and you paid for it.

How the score sorts. Fail one or two and you have a manageable engagement that needs tighter scoping from your side. Fail four or more and the engagement will make the operation worse in direct proportion to how good the consultant is. Pass all seven and you have found someone rare, and you should expect the first phase to be uncomfortable, because the discomfort is the diagnosis.

What You Do Monday Morning

Pull the last engagement you paid for. The binder, the deck, the spreadsheet, whatever came out of it. Sit down with it and write two columns.

In the first column, list every recommendation it made. In the second, next to each one, write what had to already be true in your operation for that recommendation to produce its intended result. Not whether it worked. What it assumed. A labor recommendation assumes a certain level of cast capability. A menu recommendation assumes execution capacity in the kitchen at volume. A retention recommendation assumes there is something to be retained into.

Then mark each row true or false as of the day the advice was given.

Every false row is a recommendation that was installed on a foundation you did not have, which means its failure was designed in before anyone executed it. Count them. If most of the rows are false, the engagement did not underperform, it was mis-scoped from the first meeting, and the same thing will happen to the next one unless you change what you ask for.

That exercise costs you an hour and no money, and it will tell you more about why the last engagement failed than the engagement itself did.

The Closer

The advice was not the problem. Most of it was competent, some of it was excellent, and that is exactly why it did the damage it did. Skill is a multiplier, and a multiplier does not care about the sign of what it is multiplying.

What was missing was the question nobody in the transaction had an incentive to ask: what is this operation built to produce, and does this work serve that or fight it. That question is not a deliverable, it does not benchmark, and it cannot be scoped in a two-week phase, which is why it almost never gets asked and why the engagements keep ending the same way.

You do not need better vendors. You need to stop buying answers before you own the diagnosis, and the diagnosis was always yours to hold.

Digging Deeper

Every term used above is defined in my Knowledge Base: https://kb.jeffreysummers.com/

Terms used: Framework Arbitrage, Vocabulary Theft, Hacksterism, Two Roads, Transactional Architecture, Relational Architecture, Restaurant Architecture, By Design Or By Default, Reward Structure Architecture, The Operator’s Read, The Credibility Test, Transactional Instrumentation

The architecture taught in full, fundamental by fundamental: https://physics.jeffreysummers.com/

The Road 1 arbitrage prosecuted where it lives in the wild: https://hacksterism.jeffreysummers.com/