Last Saturday I made laksa for eight people. Not a complicated dish, coconut milk, spice paste, rice noodles, prawns, tofu, bean sprouts, coriander, lime, but a dish with a lot of moving parts that all need to come together at the same time.
I started at 2.00pm. Service was at 7.00pm. Five hours for a dish that takes thirty minutes to cook.
The first four and a half hours were prep. Prawns shelled and deveined, shells reserved for the stock. Tofu pressed, cubed, and fried until golden. Noodles soaked. Bean sprouts washed and drained. Coriander picked, stems set aside for the paste. Limes cut. Chilli sliced. Stock made from the prawn shells and the coriander stems and a piece of galangal that was hiding in the back of the freezer. Spice paste ground, lemongrass, garlic, shallots, dried chillies, shrimp paste, turmeric, in the old granite mortar and pestle that takes twice as long as a blender and produces something twice as good.
By 6.30pm, every ingredient was prepped and arranged in bowls on the bench. The stock was strained and simmering. The spice paste was ready. The wok was clean and dry. I looked at the bench, thirteen bowls, each containing exactly what I needed, in the order I needed it, and felt the specific calm that comes from being completely ready.
At 6.45pm I lit the burner. Fifteen minutes later, eight bowls of laksa. Not because I’m a fast cook. Because the cooking was the easy part. The prep was the work.
The French have a name for this: mise en place. Everything in its place. It’s the most important principle in professional cooking, and it’s the one I keep finding in every software project that goes well.
What mise en place actually is
Mise en place is not just “being organised.” It’s a philosophy of preparation that separates the thinking from the doing.
In a professional kitchen, mise en place means that before service begins, before a single ticket comes in, before the first plate leaves the pass, every ingredient is prepped, every tool is in position, every station is clean and ready. The chef has thought through every dish on the menu, identified every ingredient and every step, and ensured that when the time comes to cook, there is nothing left to figure out.
Service in a professional kitchen is intense. Orders come in continuously. Multiple dishes need to land on the pass at the same time. The chef calls, the cooks respond, and there is no time, zero time, to stop and dice an onion. If the onion isn’t diced before service, the dish that needs it will be late, the table’s order will be delayed, and the cascade of lateness will ripple through the next hour of service.
The prep is the work. The cooking is the performance. You can’t perform what you haven’t prepared.
This isn’t optional in a professional kitchen. It’s not a nice-to-have. It’s the difference between a kitchen that runs smoothly and one that’s in the weeds by 7.30pm, with a chef screaming, tickets piling up, and a waiter explaining to table twelve that their entrees will be another twenty minutes.
What prep looks like in consulting
I spent ten years in consulting before I started writing about it, and the pattern I saw in every successful engagement was the same: the good ones invested heavily in preparation before the work started. The bad ones started immediately and scrambled from day one.
Discovery before delivery. Stakeholder alignment before kickoff. Environment setup before sprint one. Tooling configured, access provisioned, documentation located, team introductions made, domain language learned, all before the first line of code.
This is not popular advice. Clients want to see activity. They’re paying by the day, and a day spent “setting up” feels like a day wasted. The pressure to start building on day one is enormous. “We’ve already done the discovery,” they say. “The requirements are in Confluence. Just start.”
The requirements are never in Confluence. Or rather, they’re in Confluence the way ingredients are in a supermarket, present, technically, but not prepped. Not organised. Not thought through. The requirements document from three months ago was written by someone who’s since left the project. The architecture diagram is from last year’s proposal and doesn’t reflect what was actually built. The development environment takes two days to set up because the wiki instructions are four versions behind.
Every hour spent in prep saves three hours during delivery. I’ve seen this ratio hold so consistently across projects that I’d bet money on it. The team that spends a week on setup before sprint one finishes the project faster than the team that starts coding on Monday. Not because prep is magic, but because the team that skips prep spends its first sprint doing the prep anyway, plus fighting the bugs and misunderstandings that come from doing prep under pressure.
The cost of not prepping
The worst kitchen service I ever witnessed, as a diner, thankfully, not as a cook, was at a restaurant in Fremantle on a busy Friday night. We waited forty-five minutes for entrees. The mains arrived at different times, my wife’s lamb came ten minutes before my fish. The waiter apologised twice. Through the open kitchen pass, I could see the chef cutting herbs to order, something that should have been done four hours earlier.
They hadn’t prepped. Or they’d under-prepped, which amounts to the same thing. The kitchen wasn’t bad, the food, when it arrived, was good. The chef clearly knew what she was doing. But she was doing prep and cooking simultaneously, which meant both were done badly. The herbs were cut roughly because there wasn’t time to do them properly. The lamb was overcooked because it sat under the heat lamp while she prepped the fish. Everything cascaded.
The consulting equivalent is the project that starts sprinting on day one without setting up the CI pipeline, the test framework, the deployment process, or the shared understanding of what they’re building. Sprint one looks productive: features get built. Sprint two reveals that the features don’t integrate because nobody agreed on the API contracts. Sprint three is spent fixing the integration problems. Sprint four is the sprint that sprint one should have been.
I’ve lost count of the projects I’ve joined where the team says “we’re behind schedule” and the reason is always the same: they started too early. They skipped the prep because it felt slow, and now they’re doing the prep at the same time as the work, and both are suffering.
Mise en place for your tools
One of the prep tasks I’ve come to value most is tool setup. Not just “install the IDE”, configuring the entire working environment so that when you sit down to work, there’s nothing between you and the problem.
In the kitchen, this means my knives are sharp, the board is clean, the bin is within arm’s reach, and the oven is at temperature before I start. Every second spent looking for a peeler or waiting for the oven is a second I’m not cooking. The prep includes the tools, not just the ingredients.
In software, this means your editor is configured, your shortcuts are set up, your test suite runs in one command, your deployment pipeline works end to end, and your documentation is findable. Every minute spent fighting your tools is a minute you’re not solving the problem.
I’ve been thinking about this in the context of working with AI assistants, because the principle of mise en place applies there too. The CLAUDE.md file in a project, the one that tells the AI what the project is, how it’s structured, what conventions to follow, is mise en place for your AI tool. The more carefully you prep that context, the less time you spend correcting, redirecting, and re-explaining during the work.
A well-prepped AI context includes: what the project does, how it’s structured, what the coding conventions are, what the domain language is, what the testing approach is, and what the common pitfalls are. It’s the same information you’d give a new team member on their first day. The prep is the same, it just goes into a file instead of a conversation.
The teams I’ve seen get the most value from AI tools are the ones that prep the most. They curate the context. They write the brief carefully. They set up the project structure and conventions before they start generating code. The teams that get the least value are the ones that open a chat window and type “build me a web app.” Same tool, same capability, wildly different results, because one team did the mise en place and the other tried to cook and prep at the same time.
The thirteen bowls
Back to the laksa. Thirteen bowls on the bench, arranged in the order I’d use them. This ordering matters. The spice paste goes in first, so it’s closest to the wok. Then the stock. Then the coconut milk. Then the proteins, the noodles, the garnishes, each one in the order the recipe requires, positioned so I can reach them without thinking.
This is the part of mise en place that’s easy to underestimate. It’s not just about having everything ready. It’s about having everything ready in the right order. The prep anticipates the flow.
In a project, this means sequencing the setup work so that each piece supports the next. You can’t set up the CI pipeline until you’ve chosen the test framework. You can’t choose the test framework until you’ve agreed on the language. You can’t write the first test until you understand what the first feature does. Each prep task has dependencies, and doing them in the wrong order creates rework.
I’ve watched teams parallelise their prep work and end up with a CI pipeline configured for a framework they decided to change, a database schema that doesn’t match the domain model, and an API design that nobody reviewed. They did the prep, but they didn’t sequence it. The bowls were on the bench, but not in the right order, and when service started everything tangled.
When over-prepping is waste
There’s a limit to mise en place. It’s possible to over-prep, and it’s a trap that anxious cooks and anxious project managers both fall into.
If I’m making scrambled eggs for breakfast, I don’t need thirteen bowls on the bench. I need eggs, butter, salt, and a pan. Prepping for ten minutes to cook for two minutes is not mise en place, it’s procrastination dressed up as professionalism.
The amount of prep should be proportional to the complexity of the service. A simple dinner for two needs less prep than a dinner party for eight. A two-week internal tool needs less discovery than a twelve-month enterprise platform. The principle scales, but it’s a principle, not a rule. Over-prepping is a way of avoiding the uncomfortable moment when you light the burner and start cooking for real.
I’ve seen teams spend so long in discovery that they never start building. The requirements are never refined enough. The architecture is never finalised. The risk register is never complete. The prep becomes the work, and the work never happens. This isn’t mise en place. This is fear of cooking.
The test is simple: can you start? If you lit the burner right now, do you have everything you need for the first dish? Not every dish, the first dish. If yes, start. If no, prep what’s missing and then start. Don’t prep for the tenth dish when you haven’t served the first.
The calm before service
The moment I value most in cooking is the gap between the end of prep and the start of cooking. Everything is ready. The bench is clean. The bowls are arranged. The stock is simmering. There’s nothing left to do except begin.
In that moment, I feel a specific kind of confidence that has nothing to do with talent. It’s the confidence of preparation. I know where everything is. I know the order of operations. I know what the dish should taste like, because I’ve tasted the stock and the paste and adjusted them already. When I light the burner, I’m not guessing. I’m executing.
That feeling, the calm of readiness, is what good project setup produces. When the team has done the discovery, set up the tools, agreed on the conventions, and understood the first slice of work, they start the first sprint with the confidence that comes from preparation. They’re not guessing what to build. They’re not fighting their tools. They’re not discovering mid-sprint that the test framework doesn’t support the thing they need. They’re cooking.
The teams I’ve seen deliver the best work are not the ones with the best developers or the best tools. They’re the ones that arrive at the start of delivery with everything in its place. The ones who did the prep. The ones who sequenced it. The ones who know the difference between preparation and procrastination, and have the discipline to do one without falling into the other.
Mise en place. Everything in its place, before the first flame.
The prep is the work. The cooking is the performance. And the performance is always better when you’ve done the prep.