A good kitchen is invisible.
The food arrives hot. The timing is right. The table doesn’t wait between courses. From the dining room, the experience is seamless, apparently effortless.
What the customer doesn’t see: ten minutes ago, the main course station was three dishes behind. Someone called it. Another station covered. A dish got plated in the wrong order and was reset in thirty seconds. The expediter absorbed two problems that never left the kitchen.
The customer got his food on time. He has no idea anything happened. That’s the point — in a well-run kitchen, the customer never knows what it cost to serve him.
What happens when the kitchen falls apart
From the dining room you can tell. The entrees come out unevenly — some hot, some clearly plated ten minutes ago and kept waiting. The server starts apologizing with a look that says she’s been apologizing since service started. The bread basket gets refilled twice in five minutes and then not at all for half an hour.
Nobody in the dining room saw the kitchen. But everyone felt that something broke.
I think about this constantly when I audit an information system.
The executive team is the dining room. They see what reaches the table. Deliveries, reports, incidents, release notes. They have opinions about team velocity, product quality, technical decisions. All of those opinions are formed from what arrives in front of them.
They almost never see the kitchen.
And this is not a metaphor. It’s a structural description of how most technical organizations operate. The people who make technical decisions at the organizational level do so from a position of almost complete information asymmetry. They know what they’re served. They don’t know what it cost to produce it, what was absorbed invisibly, what problem was routed around without being fixed, what the person who made it work has been doing for the last three sprints that isn’t on any roadmap.
The kitchen that runs on heroism
The worst technical kitchens I’ve encountered aren’t the ones with bad engineers. They’re the ones with excellent engineers running a system that only works because of them personally.
One person who knows where everything is. One person who gets called at 3am when the production system breaks. One person whose departure would create an immediate crisis that nobody in management has modeled or prepared for, because as long as he’s there, the crisis doesn’t materialize and nobody needs to confront what his presence is actually hiding.
The system works. Food comes out. Executives are satisfied with the delivery rate. The kitchen is invisible because one person is making it invisible, every single day, at a personal cost that isn’t on any dashboard.
Then he leaves. Or burns out. Or gets an offer from a company that pays him what he’s actually worth. And the entire kitchen is exposed at once.
This is where I find myself being brutally direct with CEOs: your senior engineer’s availability is not a performance indicator. It’s a risk indicator. The fact that he solves every crisis is evidence that the crises are structural and recurring — not that the system is healthy.
A fire department that puts out fires efficiently is not proof that your building is safe. It’s proof that you have good firefighters. The building is still on fire.
The brigade structure and why nobody implements it
Escoffier’s brigade de cuisine wasn’t invented because restaurants got complicated. It was invented because the model where one head chef does everything by memory while helpers execute blindly doesn’t survive scale.
Every role defined. Every station autonomous. Every hand-off explicit. The expediter at the pass ensures that timing aligns across stations before anything leaves the kitchen. When it works, a problem at the patissier station doesn’t cascade to the entremettier, because dessert is downstream and isolated from what’s happening at other stations.
The IS equivalent is obvious and almost universally absent.
Clear ownership of each technical domain. Explicit interfaces between systems. Defined decision authority. An architecture where a problem in the billing module doesn’t corrupt the delivery pipeline because the coupling was designed out at the start, not discovered during an incident at 2am.
What I find instead, in almost every engagement: a kitchen where every station is connected to every other station. A change in one place requires three people to coordinate on two other things before anything can deploy. The expediter — usually the CTO or the senior engineer — spends his day managing dependencies rather than ensuring quality.
You can hire better engineers into that structure. You can run sprints, ceremonies, retrospectives. You will improve the output rate at the margins. You will not solve the architecture.
The kitchen is badly designed. You’re optimizing the chefs.
The question the CEO doesn’t ask
I ask executives one question at the start of every engagement: describe a time in the last six months when a technical project took significantly longer than you expected.
Every answer has the same shape. We thought it would take three weeks. It took four months. We kept discovering dependencies we didn’t know existed. Every time we fixed one thing, three other things needed attention.
The CEO tasted a late dish. What he experienced as a delivery problem was a kitchen architecture problem. And he’d been solving it by apologizing to the dining room.
You can’t fix what you can’t see. You can’t restructure a kitchen you’ve never walked through. Status meetings and sprint reviews are the equivalent of reading the menu — they tell you what’s supposed to arrive, not what’s actually happening between the stations.
The plates tell you the symptom. The kitchen shows you the cause. And until you’ve been in the kitchen — not for a tour, but to understand how it actually runs, where the dependencies live, what the known structural weaknesses are, who is the single point of failure — you’re making decisions about performance based on incomplete information.
Most executives haven’t been in the kitchen. Because the kitchen is the engineers’ domain. The food is the CEO’s concern.
This separation is expensive. More expensive than the four-month project that took eighteen months. Because the same structural cause will produce the same structural effect, in the next project, and the one after that, until someone walks through the kitchen and decides to redesign it.
The IS equivalent of a kitchen running on heroism is described in Looking Inside the Walls. The decision paralysis that keeps bad kitchens running is Pekin Express.
