From Kitchen to Codebase: Why Systems Thinking Transfers
I've been a systems engineer my whole career. I just didn't know that's what it was called.
The first systems I designed were prep lists. A legal pad that evolved into a structured document: station assignments, par levels, prep timelines, quality checks, and a communication protocol for when we fell behind. Every cook got a copy relevant to their station. Every shift ran the same way. When a new hire joined, they didn't shadow someone for a week — they read the list and started producing.
I was nineteen. I didn't know the word "systems." I just knew that without structure, 600 covers becomes chaos. With it, 600 covers becomes a pipeline.
Fourteen months ago, I brought that same thinking to software. The canvas is different. The discipline is the same.
Mise en Place → Dev Environment
In a professional kitchen, mise en place — everything in its place — isn't a suggestion. It's the foundation of the entire operation. Before the first ticket fires, every ingredient is prepped, every tool is positioned, every station is organized. The mental model of the menu is loaded and rehearsed.
In software, the equivalent is a configured dev environment. Dependencies installed. Project context loaded. Build system verified. Your team and AI partners briefed on the current state — what stage the project is in, what the conventions are, what was decided last week.
Dev Context Methodology is my mise en place for development. The .tracker/ structure, the session state, the context layers that load at the start of every session — they exist for the same reason a line cook's station setup exists: to reduce cognitive load during execution by front-loading preparation.
The parallel isn't cute. It's structural. Both create the conditions where real work happens without constant interruption to find things, remember things, or figure out what to do next. A cook who preps well looks effortless on the line. A developer who sets up context well looks effortless in a session.
Service Flow → CI/CD
A dinner service is a pipeline. Tickets come in from the floor, flow through stations (grill, sauté, garde manger, pastry), get quality-checked at the pass by the expeditor, and go out to the dining room. If any station falls behind, the whole pipeline backs up. The expeditor's job isn't cooking — it's managing flow. Expediting has always been my favorite position in any pipeline — it's where creative problem-solving and abstract thinking have the most room to operate.
CI/CD is the same pattern with different materials. Code commits flow through build → test → deploy. If any stage fails, the pipeline blocks. The CI dashboard is the pass — you're monitoring throughput, catching failures before they cascade, keeping the line moving.
Running expo means massive throughput through a multi-station pipeline with real-time quality gates, all in a six-hour service window. The mental model — bottleneck identification, resource reallocation, graceful degradation when a station goes down — is identical to managing a deployment pipeline. The materials are different. The physics are the same.
The communication protocols map too. In a kitchen: "Behind!" "Corner!" "Heard!" Structured signals designed to prevent collisions in a shared workspace. In code: commit messages, PR reviews, incident alerts. Different vocabulary, same purpose — coordination under pressure in a shared environment where one person's actions affect everyone else.
Menu Engineering → API Design
This is the parallel that surprises people.
Menu engineering is the discipline of designing a menu around cost margins, prep complexity, station load, and guest psychology. A great menu isn't a list of things the chef can cook — it's a system optimized for execution and margin. Every dish has a food cost target (typically 28-32%). Every menu section is balanced so that popular items don't overwhelm a single station. High-margin items are placed where the eye goes first.
API design has the same constraints. Which endpoints to expose. How to balance flexibility with simplicity. What operations to make easy and which to deliberately make difficult. Where to invest engineering time for maximum user value.
The 80/20 rule operates in both domains. In a restaurant, 80% of orders come from 20% of the menu — design for the common case, handle the rest gracefully. In an API, 80% of calls hit 20% of endpoints. The distribution is the same because the underlying dynamic is the same: users (diners, developers) have preferences, and a well-designed system optimizes for the actual usage pattern, not the theoretical one.
Menu costing — tracking food cost percentage per dish, adjusting portions and prep methods to hit margin targets — translates directly to thinking about resource costs in software. Token usage in AI development, compute costs in cloud deployments, bundle sizes in frontend work. Both are about understanding the cost of each unit of output and designing systems that stay within budget without compromising quality.
Team Leadership → Collaborative Development
Running a kitchen team means hiring, training, delegating, giving feedback, managing burnout, and maintaining standards when you're not standing behind someone. I've managed teams of six and teams of forty, and been part of organizations with ninety.
The sous chef role is the one that maps most directly to software work. You're the translator between the chef's vision and the line cooks' execution. You take abstract goals ("I want this dish to feel like autumn") and break them into actionable station assignments ("roast the squash at 400, sweat the shallots with thyme, mount the sauce with brown butter"). You review output. You adjust when the results drift from the intent.
This is, in a real sense, what working with an AI development partner looks like. Translating intent into structured instructions. Breaking complex goals into executable tasks. Reviewing output against quality standards. Adjusting the system when results don't match the vision.
The specific skill: training a new line cook and writing a CLAUDE.md file are the same exercise. Both require you to externalize your standards, conventions, and decision-making frameworks into a format someone — or something — else can follow without you standing over them. The cooks who struggle are the ones who can't articulate their process. The AI sessions that struggle are the ones with vague or absent context.
Why This Matters
The tech industry's emphasis on CS degrees as a credential misses something important: systems thinking doesn't come from a curriculum. It comes from building and operating systems under real constraints.
A professional kitchen is one of the most demanding systems environments that exists. Real-time throughput requirements. Zero tolerance for downtime during service. Human factors everywhere — fatigue, ego, skill gaps, communication failures. The feedback loop is immediate and unforgiving: if the food is late or wrong, you know in minutes, not sprint cycles.
The transferable skill isn't "I can follow a recipe." It's "I can design a system that performs reliably when everything is moving fast and the stakes are high." It's the ability to see a bottleneck before it cascades. To know when a process needs more structure versus when structure has become overhead. To train someone effectively by externalizing your thinking rather than just demonstrating it.
Career changers from operational backgrounds often bring something that's hard to teach in a computer science program: the instinct for systems under pressure. They already understand throughput, feedback loops, graceful degradation, and the difference between a system that works in testing and one that works on a Saturday night with a full dining room. They just need the syntax.
This isn't a defense. It's an argument that operational experience is an asset in engineering — not despite the career change, but because of what the first career taught.
The best engineers I've met in kitchens never called themselves engineers. They called themselves chefs, managers, owners. But they were designing systems every day — allocation systems, quality systems, communication systems, training systems. The vocabulary was different. The discipline was the same.
I didn't leave the kitchen because I was done with systems. I left because I found a bigger kitchen.
About My Background Read Post 1: Building DCM