For most of my career, building software felt a lot like being the only cook in a small kitchen.
You take the order, prepare the ingredients, cook the meal, plate it, and clean up afterward. Every dish depends on your hands, and the number of dishes that can leave the kitchen is constrained by how much work one person can physically perform. You may become faster over time, develop better techniques, and learn how to organize your workspace, but there is still a limit. Eventually, the kitchen itself becomes the bottleneck.
Software projects often worked the same way.
Every new application brought its own architecture decisions, implementation work, testing, documentation, deployment concerns, bug fixes, and operational overhead. Even relatively small projects accumulated far more work than initially appeared. The challenge was rarely coming up with ideas. Most people I know in technology have more ideas than they could ever pursue. The challenge was finding enough time and attention to transform those ideas into something real.
For years, execution was the primary constraint. Many ideas never failed because they were bad ideas. They simply never received enough sustained effort to become working products.
Lately, while building several products alongside my main job, I’ve been thinking about a different kind of kitchen.
In a professional restaurant, the head chef is not necessarily the person chopping every vegetable or standing over every pan. In fact, if the restaurant is busy enough, that would be an inefficient use of the chef’s time. The kitchen is divided into stations. Different people focus on different responsibilities. Several dishes are being prepared simultaneously. Orders arrive continuously, priorities shift throughout the evening, and yet the restaurant is expected to deliver a consistent experience to every customer who walks through the door.
The head chef designs the menu. The head chef decides what gets served. The head chef establishes standards, checks quality, and coordinates the flow of work across the kitchen. Individual dishes may be prepared by different people, but responsibility for the overall experience still belongs to the chef.
That distinction feels increasingly relevant to software development.
For a long time, building software meant personally producing almost every artifact involved in creating a product. The work was deeply hands-on because there was often no alternative. If something needed to be written, tested, documented, researched, or implemented, chances were that you would be the one doing it.
Today, a growing portion of that effort can be delegated. Ownership cannot be delegated. Judgment cannot be delegated. Product decisions cannot be delegated. But many of the activities that consume time during the development process can be accelerated, distributed, or assisted. Drafts can be generated. Documentation can be prepared. Alternative implementations can be explored. Tests can be created. Research that once required hours can often be completed in minutes.
The interesting consequence is that the builder’s role begins to shift.
Instead of spending all available time executing tasks, more time is spent reviewing, refining, coordinating, and deciding. The work remains deeply involved, but the nature of the involvement changes. Increasingly, the challenge is not producing every component yourself. The challenge is ensuring that all the components contribute to a coherent whole.
I’ve noticed this while working on products such as Founder, a game inspired by the stories behind great companies, AppGrid, a platform for publishing and distributing applications, and several smaller experiments. Progress is rarely blocked by implementation alone anymore. More often, the question is where attention should be invested next.
At first glance, this sounds easier. I’m not sure it is.
A poorly run kitchen does not improve simply because it has more cooks. In many cases, the opposite is true. Additional capacity introduces additional complexity. Coordination becomes part of the job. The head chef needs to understand how every station contributes to the final dish. They need to know what deserves immediate attention, what can wait until tomorrow, what should be improved, and what should never leave the kitchen.
I’ve discovered something similar while working on multiple products at once.
The challenge is no longer whether progress can be made. Progress is usually possible. The challenge is deciding where attention should go. Every project can generate another idea. Every application can justify another week of work. Every feature can be refined a little further.
The difficulty is that all of them compete for the same finite resource: attention.
The more capacity becomes available, the more important prioritization becomes. In a strange way, the bottleneck moves up the stack. Technical obstacles still exist, but they are no longer the thing that stops most projects from moving forward. More often, the limiting factor becomes deciding which opportunities deserve continued investment and which should be left alone.
Years ago I often found myself asking:
“Can I build this?”
Now I find myself asking a different question:
“Should I build this?”
Those are not the same problem.
The first is primarily an execution challenge. The second is a judgment challenge.
And if there is one lesson I’ve taken from running several projects in parallel, it is that judgment becomes more valuable as execution becomes easier.
The head chef is still responsible for the menu.
The challenge is no longer finding enough hands to cook.
It’s deciding which dishes deserve a place on the menu at all.