A recipe card is a small thing. A dozen lines, some quantities, an oven temperature, and a note in the margin that says "less salt than you think." Follow it once, carefully, and you can prove a dish is good.
Now cook it two hundred times on a Saturday. Hot, the same every time, out in under ten minutes, made by people who didn't write the card. The card hasn't changed. Everything around it has to.
That's the gap between proving an idea and building the organization that delivers it. People who are great at the first job tend to treat the second as a bigger version of the first, and some of the instincts that got them through the first one work against them in the second.
The executive who stayed at the stove
The clearest case I've seen was an executive inside a larger organization, someone who had personally built the latest generation of its product. He knew the industry cold. He was extremely smart and talented. And he couldn't stop building.
He threw himself into the new product, as the executive, and let the rest of the organization flounder. He wasn't leading the leaders under him or giving them feedback. He dropped in to say what he didn't like, or when something wasn't exactly what he wanted, and then went back to the stove.
You can guess the rest. Morale fell. People on the older products left in numbers. He couldn't keep leaders underneath him, and the seat below him kept turning over. Last I checked, the organization was badly missing its financial targets, and its relationships with other parts of the company had gone sour.
Think of it as a restaurant. He stayed the line cook on the one dish he was personally interested in, and nobody was running the rest of the place. Nobody was managing the front of house. Nobody was handling the money or buying the ingredients. All he was focused on was cooking.
What the dish proves
Zero-to-one is the recipe test. You find out whether people want the thing and will pay for it. That's hard, most ideas fail it, and passing deserves a celebration.
But look at what passing proved. One cook made the dish for a handful of patient customers, every plate got the cook's full attention, and when something went wrong the cook fixed it by hand and probably didn't write down how. Nobody knows yet whether the dish works when someone else makes it, on a busy night, for a customer who has no idea who's cooking. Your next fifty customers will ask exactly that.
Why great cooks struggle to build kitchens
Great cooks improvise. They can rescue a broken sauce in thirty seconds, and most of them would rather do that than explain how.
A kitchen needs the dull version: the same steps every time, done by people who didn't invent them, checked against a standard that lives outside one person's head. When the cook in charge steps in to fix a plate, the line learns the real recipe is whatever that person does tonight. So the line waits, and the organization can cook exactly as much as one person can.
And kitchens are boring to build. Writing a prep list is less fun than inventing a dish. That's the trap the executive fell into, and it's a close cousin of the founder who stays the roadmap. ("The founder is still the roadmap" is about who decides. This one is about who can do the work.)
Kitchen work
Two pieces of my own work were mostly kitchen-building.
At Gannett I was one of five people on the Design Innovation Group, which reported to the CEO. One of our mandates was a process for enterprise-level innovation that other people could reuse. We built it with IDEO, and IDEO went on to use it in their own practice to build something similar for outside organizations. That's the real test of a recipe: it works in someone else's kitchen. I also co-authored the group's 120-page innovation manual, which combined Agile, human-centered design, UI/UX and disruptive innovation, for the same reason. A way of working has to get out of the heads of the people who invented it.
At Personify I led the UX, design and engineering practice and introduced a design system. It cut development cost and time by 30%, in the next version of the core product and in the customizations customers paid for. A design for handling a certification could move to another customer instead of being built from scratch, and things built for one customer could come back into the core. A design system is about as close as software gets to a prep station. Components get made once, made well, and every team cooks with them instead of chopping its own onions.
Years later, when I evolved Guidehouse's innovation lab into an incubator, the line I kept coming back to was that we wanted to be a great incubator, not just a great innovator. Getting good at coaching teams to find what mattered and build it beat getting good at cooking everything ourselves.
Five things a kitchen has
A working kitchen has five things a recipe card doesn't. Build them roughly in this order.
A menu small enough to cook well. Every product, plan, custom variant and integration you sell is a dish the kitchen has to make on a bad night. Most young companies have a menu built one customer yes at a time. Cut it until the people you have can cook everything on it well.
Written recipes. Put what the builder knows on paper at a level a new hire could follow in their second week: the steps, the judgment calls, the customers who get handled differently and why. Keep it short enough that people open it. Fix it every time it's wrong.
Stations. One named owner for each part of the work customers pay for. Nobody in a kitchen wonders who's doing the steaks. If two people own onboarding, nobody does. ("From pickup game to team" covers who to put at the first stations.)
Prep. Kitchens do most of their work before service starts. Prep is your operating rhythm: the hour on Monday when the team sets up the week so Thursday doesn't turn into improvisation.
The pass. The counter between the kitchen and the dining room, where every plate gets checked before it goes out. For you, that's a written definition of done and a person whose job is to check against it. On a busy night, the head chef stands at the pass. Calling tickets, tasting, telling a cook what's off. That's where the executive in this story belonged, and he was at a burner instead.
The test of a kitchen is a full Saturday with the chef at home.
Where the metaphor breaks
A restaurant cooks roughly the same dishes every night. Products don't sit still. You'll change the recipe constantly as customers teach you things, and a kitchen built around one dish breaks the first time the menu changes. Build around stations and skills instead. A good grill cook can cook whatever comes off the grill.
And sometimes a leader should be at the stove for a while. A brand-new product may really need its builder's hands. The mistake is staying there with nobody else running the restaurant. If you're going to cook, name who's running the kitchen while you do, and set a date to hand back the apron.
Try this
- Pick the one workflow customers pay you for most. Go by revenue. It may not be the one you're proudest of.
- Ask: if the person who built it left tomorrow, who could make it tonight? Write down a name. If you can't, you have your answer.
- Write down everything that person would need: the steps, the judgment calls, the accounts and tools, the customers who get special handling, and what finished looks like.
- Hand the page to the person you named and have them run the workflow once while the builder watches and stays quiet. Every time they get stuck, add a line.
- If you lead other leaders, look at last week's calendar. Mark the hours you spent cooking and the hours you spent running the kitchen.
Where do you land?



