Every project is made up for three ingredients: (1) a deadline (2) a finite amount of engineering resource, (3) a set of requirements. When you are deciding on the quality of the project, you are making serious choices about the ingredients.
A feature team operates in a similar way as a Chinese restaurant kitchen, and a project is very much like cooking a dish at a Chinese restaurant. There is a customer who orders chicken chow mien and expects the noodle to be ready in a reasonable amount of time, hence there is a deadline. If you deliver the food early, you exceed expectations. If you deliver the food late, customers get angry, and well…you let the manager deal with the customer.
There is also a finite amount of resource to make a dish. Orders come in from all the servers. The head chef looks at all the orders, group some orders together whenever possible. This happens for example when two tables both order sweet and sour pork, or when one table ordered dish A with no spicy and another table ordered dish A with spicy. In this situation you cook both dishes together without spicy. When the dish is ready, you take out half the food and serve as the no spicy dish, and then throw in some spice for the remaining half and cook that a bit longer. Here, the head chef is constantly making choices to save his resource (chefs’ time), and perhaps sacrifice quality a bit, being the spicy dish is a bit overdone in order to save time. Overcooked pork is not all that uncommon, and it’s usually undetected with enough use of MSG.
In addition to grouping orders together, the head chef takes each order and assemble the raw ingredients in a plate, writes the name of the dish on a piece of paper, and assign the dish to a cook to crank. If things are done right, the cook just have to execute with the given ingredients and deliver the dish with an acceptable quality.
The kitchen dynamics gets interesting when communication breaks down, mistakes made, or external factors come into play.
When things get busy or when the head chef is a bit out of his elements, he might miss to assemble the green onions occasionally, or when the customer specifically asked to have it left out, it was accidentally added to the dish, usually out of old habits. This creates the wrong order, and the kitchen has to remake the dish (or hope for another table who orders it can live with it). The cook might also make mistakes using the wrong sauce, added too much salt, etc… Their job is more difficult than a software engineer because nobody does a “cook review” over the food they cook, so whatever food they produce go straight to production.
External factors come into play as well, usually when you least expect it. A VIP orders lemon chicken and wants it ASAP, and this becomes a P0 item for the cook. Now the cook has to drop everything he’s cooking and and start pan-frying some chicken and prepare the lemon sauce. Cooks are trained to multitask, but they too hate to be randomized as well.
When a cook makes a mistake and a food order is delayed, the whole queue of orders is delayed. First the customers gets angry and complains to the server. The server reluctantly smiles at the customer, offers an apology, turns back, walks to the kitchen, curses the cooks, and then yells as the head chef and demand a status update. The head chef, having worked his way up from a lowly busboy, have seen it all and have dealt with the nastiest of all servers, wouldn’t take shit from him and yells back, protecting his army of troops so they can focus on the next dish and get it out ASAP.
In the Chinese restaurant kitchen analogy, the head chef is your super PM. From here on, let’s call him Dan for short.
Dan goes about his job everyday sitting in meetings fielding asks (orders) from partner teams (customers). Dan takes notes and group the work together and assign TFS work items (order notes) to his ICs (chefs) to cook. Dan also creates specs (assemble the ingredients, and spells out the exceptions), and expects the work to be done on time. If the work is not done on time, you let Dan know, and he’ll re-prioritize.
Dan goes to even more meetings to provide status updates for the projects that he owns. Some meetings are less intense, and they are called regular sync meetings. Some more intense, especially when projects are on the verge of being delayed, they are called “war”. Dan goes to war from time to time, defending his team so that they can focus on writing/testing code.
Having said that, since both disciplines are very similar, I believe a feature team can take inspirations from a Chinese restaurant kitchen in how it operates, and learn from the best practices. After all, the software industry has only around for about 20 years. Chinese food has been around much, much longer.
Observation #1 - There is only one head chef.
As far as I know, there is no co-head chefs in the kitchen. There is an assistant head chef that takes on head chef duties when the head chef has to do PR work by going out of the kitchen shaking his greesy hand with some VIPs. The truth is, the assistant head chef manages a distinct category of food than the head chef - such as desserts. That way, food orders either go to the head chef or the assistant head chef. The two never gets involved deciding on the priorities and logistics of the food orders that come in. This is simply not efficient when the kitchen is busy.
Similarly, PMs can shouldn’t overlap on co-owning projects. Every PM drives his project as if the project is his baby. You don’t need validation of the decisions you made, because your decision is the only decision, right or wrong. Remember, a wrong decision is not always a bad decision. A wrong decision might lead to sup-optimal work or mistakes, but at least you can learn from a mistake, so there is always value there. A bad decision is one when no decisions are made. This way, there are no data points, and nothing can be extracted from an indecision.
Observation #2 - The head chef’s decision is the final decision.
It is a luxury to get different viewpoints in a problem, because the best solution is one that comes out of heated arguments after serious thoughts were put into thinking about a problem. The PM needs to gather that feedback as input before making a decision. Once a decision is made, the team needs to follow the decision, otherwise it creates chaos downstream. This is because when a decision is made, it impacts the schedule and resource allocation of other projects in the queue, changing a decision or the execution plan can affect the other projects.
This is true even if you are gung-ho and complete your task early. You may want to deploy it to Production so that users get to enjoy a new feature early, but this is detrimental to the team’s greater goals because it affects other people’s priorities and timing of other projects.
Observation #3 - The head chef does not let the server get into the face of the cooks.
When the server kicks open the kitchen door, curses the whole kitchen staff for making the world’s most salty Gong Bao Chicken, the head chef never lets the server know who made that dish (although the server knows). The head chef either blames the raw ingredient for bad quality, customer not having a good day, or even the weather. The head chef doesn’t let the noise affect his staff, because that doesn’t help make the food less salty.
Likewise, a PM protects his feature team from the noise.That includes partner teams making requests directly to the devs to get things done. Work should be filtered and proxied through the PM. One way to make sure it happens is to create an email templete where the PM is always in in the CC line.