The Gordon Ramsey Theory of Software Engineering Management
Why running a kitchen and running a software engineering team aren't all that different.
I just recently finished season two of the superb show The Bear. In the final episode of season two (minor spoiler), Ritchie has to take over “the pass” and orchestrate the entire kitchen to help them successfully pull through a tough dinner service.
It’s a great scene, and it reminded me of an analogy I developed back when I first watched Hell’s Kitchen. Running a software team is a lot like running a kitchen. So, in honor of my favorite celebrity chef who first inspired it, I call this the Gordon Ramsey Theory of Software Engineering Management.
Let’s walk through a chef’s responsibilities and see how they related to a software development manager.
Create the Menu
The first responsibility of a chef is to develop a menu for the restaurant. Chefs will leverage their experience to create and test many different recipes and ingredients before settling on the best ones for the menu. The menu is the framework that the restaurant is built on.
As a software engineering manager, you need to create a similar menu for your team. The ingredients are the architectural choices that you make for your software. The team will combine those ingredients when creating features. You also need to leverage your experience to create recipes. Should you use a document or relational database? What frontend framework are you using? Are you building native or hybrid mobile apps? Which tools make the most sense for the software you are building.
Define the Process
The second item a chef needs to define is a process to ensure efficient operation of the kitchen and wait staff. How are orders communicated? How are courses sequenced? How should the team communicate timing updates?
A manager also needs to clearly define the development teams process. Are you following Scrum or Kanban? How are issues selected for sprints? Are peer code reviews required? How do we document the API?
Process also includes handling emergent issues outside of the normal development workflow. How do you handle outages? How are support tickets processed? How do you handle tasks needed to maintain your SOC2 compliance? And it goes without saying that these processes definitions all need to be written down.
Train the Staff
After developing the recipes and processes, the chef needs to train the staff. This includes training the cooks how to prepare each dish and training the entire staff how to follow the processes. The goal is to create a well orchestrated service for the customers.
Software engineering managers overlook training. The assumption is there’s plenty ways to learn be reading the Internet. But you need to train your staff what specific patterns you want followed when building the software. The goal is to keep a lid on complexity. It’s not a free for all, otherwise technical debt will accumulate.
Our dishes are features, and you need to train the team how to best use the frameworks (ingredients) from the first step, to create new features. How should the API be designed from a given set of requirements? How are we using message queues? What patterns are we using for client side state management?
Communicate & Time Orders
Once service starts, it’s the chef’s responsibility to communicate and properly time customer orders to deliver a successful service. The chef needs to communicate each order to stations so that courses are properly spaced and that all dishes for a single course are completed at the same time for optimal delivery. That communication needs to clearly convey the expected outcome and timing. The chef also needs to listen to feedback and status updates from cooks and adjust the timing of other dishes accordingly.
As a software engineering manager, you have the same responsibility. Orders from the customer (or in our case, product management) need to be sequenced for optimal delivery. It’s your responsibility to know which order should route to which station (engineer), and get estimates from engineers about effort and timing. You then use that information to create an optimal execution order. You need to understand when building feature X then feature Y is more expensive than building feature Y then feature X. If a feature is delayed, you need to adjust the delivery of other work to compensate. You are orchestrating the team to deliver completed, timely, and high quality features.
Review Completed Orders and Give Feedback
Once dishes are completed and delivered to the pass, it’s the chef’s responsibility to review the completed dishes before they are delivered to the customer. This ensures that the dish was prepared properly, looks great, and is being sent to the customer at the optimal time. The chef also needs to give feedback to the cooks, good or bad, about the delivered dishes. In the worst case, the chef has to ask for a refire (a.k.a. a complete redo).
Reviewing the team’s work is a critical component of being a good software engineering manager. You should review completed work before it is delivered to the customer. This doesn’t mean you need to do detailed code reviews of every change. But it does mean reviewing and testing the implementation to make sure the ingredients were properly used and the presentation is correct. Like a chef, you need to give feedback, positive and negative. That’s the best way to improve the performance of the team. Also, don’t shy away from asking for the work to be redone if it doesn’t meet your standards.
Receive Feedback from the Customers
Finally, a chef needs to listen to customer feedback and adjust the recipes or process to create a better experience for the diners. Was the service slow? Were the flavors disappointing? Was the quality not up to expectations?
It’s critical you listen directly to feedback from product management, business leadership, and customers for feedback on the team's work. Incorporate that feedback back into your technology choices, training, and process to ensure that you are constantly improving the performance of the team.
You are No Longer a Cook
One final thought. One thing you’ll never see Gordon Ramsey do when his kitchen is struggling is leave his spot on the pass and start cooking dishes at the underperforming station. He continues to do his job, not the job of the cook. He knows that solution doesn’t scale and doesn’t help improve his team in the long run.
As a manager, especially a new one, it will be tempting to jump into the fray and start writing code when the team is behind. But oftentimes this is counterproductive. You’ll squash any intrinsic motivation from the team to learn and grow. They’ll will learn to rely on you for the hard parts. Instead spend your days ensuring you are using the right frameworks, training, communicating your expectations, organizing the work, reviewing work, giving feedback, and receiving feedback. You are the chef, you are no longer a cook.