Too Many Chefs, One Kitchen
How software structure shapes speed, ownership, and learning Most teams don’t start with architecture problems. They start by building. Fast. A small product, a tight team, a system that does just enough. And for a while, that’s the right choice. You’re shipping. You’re learning. You’re moving. But at some point, usually when the business starts to grow, something shifts. Releases become slower. Teams start stepping on each other. And what once felt nimble now feels stuck. Why? The instinctive answer is technical debt — maybe the system just needs refactoring. Or maybe it’s a process problem. But often, the real issue is more structural. Your architecture no longer matches your organization’s needs. A common sign of this mismatch is deployment friction. One team wants to ship a small feature. But they have to wait. Wait for another team to finish testing. Wait for someone else’s changes to stabilize. Wait because even a tiny change means releasing everything. The system works — technically. But it’s like sharing one kitchen with five different chefs. This is what monoliths often feel like: centralized, coupled, and fragile under pressure. Microservices don’t solve everything, but they restructure the problem. By giving each team their own “station,” they reduce the coordination tax. Teams can deploy independently. They can fail independently. They can learn faster, without always waiting for the rest of the kitchen to finish cooking. That doesn’t mean microservices are always better. Just that at a certain scale — of product, of people, of change — they become a way to align architecture with the shape of the organization. What follows is a simple example — not to show how to “do microservices,” but to make clear what kind of friction they solve, and why it starts to matter more as teams grow. Think of it as a zoom-in on what happens when structure starts slowing teams down — not because of failure, but because of how things are bundled. ⸻ Imagine a SaaS platform offering payment processing and loyalty features for small businesses. It’s been growing steadily, and the codebase — a monolith — has carried the company through its early traction. Releases are coordinated, large, and slow, but manageable. Then a new opportunity arises. The product team identifies a small pricing optimization — tweaking loyalty point accrual rules to encourage repeat purchases. It only affects existing users. Forecast models suggest it could increase annual revenue by 2%. It’s a focused change, with minimal risk, and the team wants to run a fast A/B test to validate it. But it can’t ship. It’s bundled into the same release as a compliance update — one that applies exclusively to new customer onboarding and affects shared reporting logic. The loyalty change, meanwhile, is for existing users. The two have nothing to do with each other, but because they live in the same monolith, they move together. You just want to add a bit of seasoning and send the plate out. But the kitchen won’t let anything leave until the whole menu is rewritten. So the loyalty experiment waits. And each day of delay costs more than just projected revenue — it delays validation. No test runs. No feedback arrives. The team can’t iterate. Momentum slows. The problem isn’t the work. It’s the structure that forces unrelated changes to move together. Microservices would let the loyalty team ship on their own terms. They could release early, run the test, learn what works, and improve the feature before the week’s over. And perhaps more importantly — they’d own the outcome from end to end. Architecture changes behavior. When teams can move without waiting, they start testing more, listening sooner, and improving faster. Not because of a mandate — but because the system allows it. ⸻ It’s easy to see microservices as the fix: split the kitchen, give each team their own space, and let them move fast. And when done right, it works. But it also comes with a new kind of burden. Every kitchen now needs its own tools, its own cleanup, its own supply of ingredients. And to make something great, those ingredients need to be fresh, high-quality, and well-managed — and that adds not just effort, but real operational cost. Microservices give you autonomy — but only if you’re mature enough to handle it. That means good testing. Clear ownership. Reliable observability. Solid deployment pipelines. If any of those fall short, the service breaks — or worse, breaks others silently. Monoliths concentrate complexity in one place. Microservices distribute it. If the teams aren’t ready — if the ingredients aren’t right — you won’t get autonomy. You’ll get inconsistency. Drift. And a lot of mess to clean up. And so the question becomes: when do you make the shift? You don’t need five kitchens on day one. Microservices aren’t a milestone to reach. But when the line to cook is longer than the cooking itself — when teams spend more time waiting than building — it’s worth asking whether the kitchen still fits. Structure should serve the pace and shape of your product. If it starts slowing you down, it’s time to reshape it. The best teams aren’t just fast. Architecture is just one part of that system. But it’s powerful.
One team’s baking. Another’s cleaning fish. Someone else just spilled oil on the floor.
You can coordinate. You can take turns. But you can’t move freely. And eventually, the kitchen becomes the bottleneck.
But that freedom doesn’t come for free.
Which means you don’t reduce complexity — you just move it.
A single shared space works just fine — until it doesn’t.
They’re a response to something felt: friction, delays, coordination overhead that’s no longer manageable. If your teams are shipping smoothly, if ownership is clear, if feedback loops are tight — stay where you are.
They’re intentional about the systems they build around them — not just in code, but in how they move.
Because when it’s right, it doesn’t just unblock delivery.
It unlocks behavior.