Developer’s Kitchen Nightmares: Restaurants don’t work like this, and neither does tech development.
Gordon Ramsey’s “Kitchen Nightmares” and how it relates to running a tech company. Especially a Startup.
This article contains insights from watching classic episodes of Gordon Ramsay’s Kitchen Nightmares (series 1–5) and how they relate to running a tech company. Please note this article is not perfectly applicable to self service SaaS companies unless you are still in the process of building your product and features. The main focus is on companies with B2B sales, possible integration work for each client, and a specialist sales team pushing the product.
For the lazy reader — the analogies made in this article are (in order of importance):
- Doing the prep work
- Good ingredients and small set menu
- Front-of-House and Back-of-House co-ordination.
- Deploying starters and pushing the specials
- Practice and innovation during downtime
- Hiring and Morale
The Premise
During Lockdown I managed to watch most of the first few seasons of Gordon Ramsey's Original series “Kitchen Nightmares”. For those who have not seen this I should immediately explain a few things:
- It is not a cooking show. It is a show about failing small businesses and trying to turn them around. Gordon is less a chef here than he is a specialist management consultant.
- Gordon goes into the business for a week, and starts implementing changes across the entire restaurant to not only improve the food quality, but the business as a whole.
- It is not the “junk tv” show that Ramsey would become more famous for later in the American remakes with dramatic music, cuts, and constant recaps (like many series… The UK original is a different flavour).
The premise is Gordon goes to a small business, which has poor financials, a poor product-market fit, and a finite cash runway. He then applies some basic rules to try and improve the company. These companies just happen to be restaurants.
My first thought was “What other small businesses do I know that have poor financials, poor product-market fit, and a finite cash runway. Oh yeah — almost every tech startup”.
The methods Gordon uses are, I believe, applicable to any company that does some amount of work for each client they serve. Furthermore, the industry verticals both have similar pitfalls — the average company does not make it past 2 years, and the majority go down in flames taking the lifetime dream of the founder and all investor’s money with them. This goes for both the bootstrapped companies on a shoestring budget and the lavishly well funded ones alike. Almost every month, there is news of another well funded tech startup going bust after they fail to convert their POCs and enterprise clients to recurring revenue for the business.
There are also many analogies that can be made between Chefs and Developers, and between restaurants and tech startups. For example, in both industries the staff treat it as a lifestyle and both the pressure, and the failure rates, are astronomically high.
So, somewhat lightheartedly, here are some takeaways from Gordon Ramsey's “Kitchen Nightmares” and how I believe they can apply to almost any tech startup:
Doing the prep work
The first major thing Gordon does is simplify the restaurants internal workings to increase efficiency and make sure customers are getting served. Most of the improvements made to the business are by simplifying the meal construction process, and ensuring that elements can all be delivered quickly. The staff are not magically better cooks in a week, but are instead actually doing a drastically simpler job.
The main ingredient here is doing as much prep work as possible before each dinner or lunch service. For Gordon that means the salads are already made and mixed, soups or stews are ready in the pot, dressings are made, and some dishes are completely ready to go. It’s not being built as and when the customer orders, it’s already made, and he’s just plating it (albeit nicely and with much finesse). This is the big thing that happens in restaurants that separates them from cooking at home.
This obvious change means that delivery of meals is fast, and a focus can be made on improving customer service. The jobs become simpler and repeatable, timing is easier, and results on the plate are consistent. It doesn’t mean a worse meal. It means a well made meal delivered on time.
In tech startups we often see things the opposite way round. Many times I see B2B companies who are trying to close a Seed round to Series A round simply fishing for POCs with large clients and then building when they get the contract. They do this because they need the money in the bank, and they need to show growth to investors, not because they particularly want the work. The work is often unrelated to the core focus of the business!
Taking projects like this is a bad move for so many reasons. Firstly POCs like this are not sustainable or repeatable revenue, and most experienced investors will recognise this. Also, they don’t really provide either the time or budget to do a good job. The build starts only when the POC is agreed, so it is likely that what arrives on the table will be rushed, buggy, and the ROI for the client won’t be what was on the menu. Afterwards the customer is not likely to be moving forward to a license, and the startup has probably lost money on the build process from its runway while also disappointing investors by not closing a sale they promised.
I get this. It’s REALLY tempting though for startups to try and jump at these deals. But beyond the Pre-Seed stage, large investors (the ones you want on your capitalisation table going for later rounds) rarely care about POC income as they know it is likely not repeatable.
Instead, go into the process having done the bulk of the prep work. For sales people, this means creating tailored slides, and preempting client/investor questions. It means having the bulk of your solution ready to go to as much as possible before the client orders.
But “Wait” I hear you say, “That doesn’t help me as a small company. We need the money. We have to make what the client wants! That’s product market fit!”. OK — here’s how Gordon deals with that.
Good ingredients and small set menu
The other thing Gordon (usually) does is DRASTICALLY REDUCE the number of services a restaurant offers, and shift focus on core products with wide appeal, good margins, simple preparation, and high quality. Preferably this should also be unique offerings (local cuisine). Often this means aggressively reducing the number of items on the menu, and making the contents very clear to understand, with just enough variance to cater to the clientele.
Tech companies can do the same here. This is the minimum viable product (MVP) and lean startup approach that everyone talks about. Often the MVP model is very hard to follow when making enterprise grade software and the enterprise needs a lot of features to justify its value. But always focus on the one core part of your tech which is repeatable, defensible and scalable. All your features and dressings come in later. Ensure you present a few key services and do them well. That’s the meat. Yes — you will have to build some other things to make the product pleasing to your customers, but don’t lose the focus and start selling your steaks by saying how many vegetables there are on the side, even though sometimes it sounds like this is what interest enterprise customers.
What counts as “MVP” can very from company to company. Those dealing with enterprises will need to build a lot more than a company selling a B2C iOS App for example. But remember that it if no one like your core product, then you can all the bells, whistles and integrations you want and it won’t count for shit.
You may think that by offering more services, you are creating more opportunities to add value and generate income. A bigger slice of the pie so to speak. But in terms of tech it’s just more opportunities to make an unpalatable product. Your margins won’t be as good on this bespoke work anyway, so leave it out if you can.
Then the core product needs prep work; this means it needs to be nicely prepared and ready to deploy at all times.
That means it is containerized, with docker images ready, and with Kubernetes pods and monitoring ready for health monitoring. It means logging in place to monitor those systems and backups where they are required. Use Jenkins for managing deployments, and use a staging server for testing new features. This is a lot of prep work, and sometimes it can feel like all this DevOps is distracting from new features, but what you are doing is making sure the main course is always ready. That’s the core product.
Connections to ERP/CRM/RPA flows/ client Databases etc. Those are dressings — try to have these made in advance too where possible. They are necessary — but it’s not the big ticket.
If you have this in place, and you focus here, then your core product will always be up to date/easy to maintain/scale/quick to deploy/etc. Then when it comes to POC you will only need to worry about those dressings.
Front-of-house and back-of-house co-ordination.
Another part Gordon focuses on is coordination between the staff sections. The restaurant staff is split across 2 distinct teams, and having them work together.
Head chef leads the kitchen (the back-of-house), which Gordon regularly calls the “Engine room”. The general manager leads the front-of-house which is the waiters and greeting staff.
Front-of-house is your sales and client facing team. The back-of-house is the Engineering department.
Often in Kitchen Nightmares, Gordon will exclaim from the kitchen that “THE FRONT-OF-HOUSE ARE FUCKING US”. This happens when the waiters are seating everyone but not taking orders. When they are mixing up the deployment orders in which food should go out. When they are taking all the orders at once, or out of order in which they should be served. When they are getting orders wrong.
The kitchen can’t handle it all at once and things quickly break down. The build priority keeps switching and things are being missed even with the simplified menu and all the prep work. Clients wait too long and go to another food vendor, the rush causes poor performance and mistakes, and this feeds back into the backlog of work. Then the front-of-house takes two orders from 2 tables of 14 people at the same time and a chef starts to cry. It’s a Kitchen Nightmare. Gordon swears at everyone and it makes great TV.
For the tech company I’ve experienced the same thing (minus crying chef). It’s rough trying to get things done when the build order gets messed up like this. The idea of having all these leads and new feature demands coming in from customers sounds great — but often the front of house needs to understand that some resources are still finite, and there is limit in how quickly features can be served. The solution is to manage the pipeline, be clear on the delivery times and priorities and DON’T MESS WITH THINGS in the build order when things are still cooking!
So, don’t open new features before finishing current ones and don’t put new features to the front of the build queue for a prospective client just because a customer seems desperate to close this month. This is basic Agile/Sprint software development.
Your CTO or Product Manager needs to be firm with the sales side and make sure they aren’t selling custom dishes and extra dressings to make their life easier. They also need to make sure the sales side understands there should be an order of work coming through, and that — once it goes to the kitchen, the order is fixed.
The engineering team has responsibilities here too in how they communicate. Once an order comes in it has to go in the queue, and the engine room has to keep moving predictably to send that order out. To use DevOps analogies, this means having monitoring and backpressure. If engineering can’t provide adequate backpressure on when they can’t do a good job on the things they have on hand, and management can’t monitor things to find out when employees are overworked or just rushing things, then you have problems.
But if your sales team thinks it’s fine to say to your 2 man team will do 7 on premise deployments, all with custom CRM integrations in the last week of this quarter, then CTO has also failed to communicate to the sales team what actually happens in your kitchen. Communication goes both ways, and you can’t blame sales for filling up the pipeline if your CTO/PM doesn’t push back.
If things ARE slowing down in the kitchen for some reason (and this will happen from time to time, for elements outside of the companies control), then the front of the house needs to know this immediately, and they should take the pressure off accordingly. They can do this first by timing the orders, but also by nudging the customer decisions. Once again, Gordon has methods for this.
Deploying starters and pushing the specials
This is what the front of the house has to do to make sure both your clients and your kitchen are happy.
Step one — seat the customer immediately, get them water and take a drink and ASAP get some food (of any kind) in front of them. Preferably starters/antipasti order but breadsticks are fine. You need to get something in front of the customer ASAP to firstly lock them into the process, and also make sure they don’t get impatient.
Then, front of house needs to charm customers and push the specials. These are items the kitchen has ready to go now for deployments, with good margins, or are deals which are available for a limited time.
Lets translate that to your tech. That means from the customer turning up, you want to get that first meeting/consultation/coffee/onsite as fast as possible to keep them engaged and motivated. Then you want to get them on the trial, or towards a POC/low tier license. That’s your starter. The customer must be quickly attended to, otherwise they will continue to consider if they want to order from somewhere else.
This moves them through the process while you establish where that customer is in your deployment pipeline (depending on the scale of work, when they are planning to make a purchasing decision, and the go live date). Everyone is now happy and engaged as the client is being warmed and pushed through the sales pipeline. The front of house is organizing the timelines and feeding this appropriately to the tech team which should have the product ready to plate up.
Now you push your specials. These are the “15% off if you can sign before end of the month”, and “Additional users at no extra cost if we can set the kickoff date as this quarter”. Limited time deals to create urgency. Or attractive croutons like “If you connect to your ERP system, we will add connections to your email system for free”. You can make these offers because the kitchen already has these prepped.
Your sales teams should have done the prep work prior to these meetings too. Possible client questions should be rehearsed, and objection handling scenarios should be played out in advance so you are ready to try and win the client over.
Practice and innovation during downtime
OK last few points.
Some of the more heartfelt parts of the show is where Gordon teaches the kitchen staff how to cook a few simple dishes. These are usually followed by the staff doing quite well and experiencing the initial ray of sunshine as they first see some hope that they can, in fact, salvage their business and cook a kidney and ale pie. Occasionally though they completely screw it up while Gordon facepalms and he wonders how he can possibly help these people.
When it goes right, these are the human moments of the show, where people start to believe they can make things work and begin to understand the process that is being implemented.
What Gordon is doing here, apart from making heartwarming and binge worthy TV, is using the business downtime (which isn’t used for prep work) for teaching, innovating and teambuilding.
This is one of the best things about working in both a restaurant, or any small company; the opportunity to learn at every level and bring friendship into the business.
This is also so easy to implement in tech company. For example, by just having one an afternoon once a month for everyone in your team to give a 10 minute presentation on a tech topic of their choice tech (“What are the pros and cons of GraphQL? Why should we consider migrating from MySQL to PostgreSQL?”), we improve communication in the team, we learn, and to improve our services. This goes for sales as well. Do some client sales role play over lunch and try to run the possible objections some clients have. You will be surprised how difficult objection handling is if you’ve never done it before.
Hiring and Morale
This brings us to the last point. This one was a fairly obvious analogy — but there are multiple occasions on the show where Gordon hires new staff.
The hiring is simple — he shows them the kitchen, gives them some ingredients, and asks them to cook something within a time limit.
This is obvious, but you should be properly testing all of your potential hires before onboarding them. Never trust the CV, and don’t just rely on some questions. Give them a small problem, and ask them to code the solution using the same techstack your company uses. Let them use stack overflow as much as they want during the process. Roleplay a sales meeting. After they are done, review the answers with them. This is a hard process. It’s much more time consuming than looking at a CV or relying on a recruiter.
But if you do this you will get great staff. It is the only way I have found for consistently hiring good staff who will be writing code on the day to day, or sales people who will be talking to clients. On the other hand, I have hired staff with good CVs and recommended by recruiters, and got developers who, in equivalent terms of code, couldn’t make an omelette.
The final part was morale. No matter how busy the kitchen is, or how many orders get burnt, the team needs to keep communicating, and keep trying to work on the build order in the order it comes in. If all of the above have been implemented, it usually works.
There are a lot more analogies with the show that can be made here; regarding work ethic, workplace candor, market differentiation, assigning staff correctly to specific tasks, workspace, and advertising… but I will stop here.
The three major takeaways are this:
- Firstly, running a tech startup does follow many of the same rules as running a successful restaurant. There are multiple lessons to be learned by applying the logic of running a successful dinner service to technical product delivery. One merely the slowed down version of the other, with longer sales cycles, and software as the service. None of this is rocket science. These are all simple, common-sense rules that clearly need to be applied but for some reason just aren’t in so many tech companies.
- Secondly, it is not hard to see why, with his work ethic and clear business acumen, Gordon is an incredibly successful entrepreneur, restaurateur and businessman.
- Finally, there is a great opportunity for a UK TV show where someone goes in and consults failing tech startups and tries to get them on their feet. Preferably the protagonist should also swear prolifically. For TV execs reading, contact me.
FIN
Josh Kettlewell is CTO at Staple AI.
Staple is a platform for extracting data from documents — regardless of layout or language. No templates. English, Spanish, Korean, Japanese — you name it, we scan it. Do you want to automate your invoice processing? E-KYC processing? Dealing with PDFS/photos/word docs/etc. of varying formats or layouts? Use Staple!
Contact Staple today to start a free trial to cut mundane data extraction and processing work out of your business. Email hello@staple.io or go to www.staple.io
