The bottleneck moved and nobody noticed
When execution becomes nearly free, the bottleneck shifts from doing the work to deciding what work to do. Most organizations are optimized for the wrong constraint.
Duration: 8:06 | Size: 9.3 MB
Every organization is optimized for a bottleneck. The question is whether it’s the right one.
For most of the twentieth century, the bottleneck was execution. Getting things done took time, people, coordination, and money. An entire management science grew up around this constraint: project management, resource allocation, capacity planning, hiring pipelines, outsourcing strategies. The implicit theory was that if you could get enough qualified people working on the right things in the right order, you’d win.
The entire consulting industry exists because of this bottleneck. Strategy firms charge millions for a recommendation that amounts to “here’s what you should work on,” and the reason that’s worth millions is that execution is so expensive that working on the wrong thing for six months can sink a division. The recommendation matters because doing things costs enough that you’d better be doing the right things.
A hospital runs the same way. There are more patients than beds, more procedures than surgeons, more tests than lab slots. The whole institution is organized around scarcity of execution capacity. Triage isn’t a philosophy — it’s a resource allocation algorithm. Who gets treated first? Whoever will die soonest without treatment. The constraint is how many people you can treat, not what treatments exist.
A restaurant kitchen works the same way. The constraint isn’t knowing what to cook. It’s cooking it fast enough, to quality, with the staff you have, in the space you have, during the time window you have. The entire choreography of a professional kitchen — the station assignments, the expediting, the mise en place — is an optimization of execution throughput. The chef’s creative vision matters, but it matters within the constraint of what the kitchen can physically produce.
Now imagine the kitchen constraint evaporates. Imagine you can produce any dish, at any volume, at any quality, in any timeframe, for nearly zero marginal cost. What happens to the restaurant?
The choreography becomes irrelevant. Station assignments don’t matter. Expediting doesn’t matter. Mise en place doesn’t matter. All of that was overhead built around the execution bottleneck. Without the bottleneck, the overhead has no function.
What matters instead is the menu. What should we serve? To whom? Why? What does this restaurant stand for? What won’t it serve? These questions existed before, but they were always secondary — constrained by what the kitchen could produce. Remove the production constraint and the menu becomes the entire business. The taste is the strategy. The judgment is the operation.
This is what’s happening right now in knowledge work, and almost nobody has adjusted.
In a single day, a small organization can now ship a product to production, harden the security of three applications, instrument analytics across a fourth, clear an entire backlog of twenty-two issues, merge two codebases into one, and draft four interconnected essays on the future of work. Not over a quarter. In a day. With one human making decisions and a fleet of AI agents executing.
The execution constraint didn’t just loosen. It effectively vanished. The wall that every organization was pushing against — “we don’t have enough people to do all the things we want to do” — dissolved. And in its place, a different constraint appeared.
The new bottleneck is decision-making. What should we build? What matters more than what else? Is this product vision right, or does it need to expand? Is this security fix urgent or noise? Does this feature belong in this product or that one? Should we publish these essays in this order or that one?
These aren’t new questions. Every organization has always asked them. But they used to be asked quarterly, in planning meetings, by committees — because execution was slow enough that decisions made quarterly were made at approximately the right cadence. You didn’t need to decide faster than you could execute.
When execution becomes nearly instantaneous, you need to decide at the speed of execution. That’s a fundamentally different organizational capability. Not faster planning. Continuous judgment. Every hour, new work completes and new decisions are needed. The product shipped — now what? The security sweep found twelve issues — which ones matter? The backlog is empty — what should exist in it? The essay draft is done — is it right?
The person in this system isn’t managing execution. They’re providing taste, discernment, and strategic direction at a rate that no planning process was designed to deliver. They’re the chef who doesn’t need to worry about the kitchen anymore — all they do is decide what goes on the menu, all day, every day, and the menu changes every hour.
Most organizations aren’t built for this. They’re built to manage execution constraints. Their hierarchies exist to allocate scarce human effort. Their planning processes exist to batch decisions into manageable intervals. Their review cycles exist because execution takes long enough that periodic checkpoints are sufficient.
Remove the execution bottleneck and all of those structures become friction. The hierarchy that allocated effort is now a decision-delay chain. The quarterly plan that batched priorities is now three months of stale assumptions. The review cycle that caught problems at checkpoints is now a bureaucratic speed bump between completing work and deciding what work to do next.
The organizations that thrive in this environment won’t be the ones that execute fastest. AI makes everyone execute fast. They’ll be the ones that decide fastest — that have the judgment infrastructure to continuously choose what matters, at the speed their execution capacity demands.
A restaurant with an infinite kitchen and a quarterly menu-planning process would be absurd. The kitchen would sit idle while the committee debated whether to add a fish course. But that’s exactly what most enterprises are doing with AI: dramatically expanding their execution capacity while leaving their decision-making processes unchanged. More output, same cadence of judgment about what the output should be.
The bottleneck moved. Execution is cheap. Judgment is the constraint.
And this is what makes it genuinely hard: judgment doesn’t scale the way execution does. You can add more agents to a fleet. You can parallelize more work. You can run nine projects simultaneously. But you can’t parallelize taste. You can’t automate discernment. You can’t run strategic direction at nine times speed by adding nine more executives.
The person at the center of the system — the one providing the judgment — becomes the rate limiter. Not because they’re slow. Because judgment is serial. You can make a hundred decisions today, but each one requires the full weight of your experience, your values, and your understanding of what matters. There’s no shortcut to that. No delegation of it.
So the most important organizational design question isn’t “how do we execute more?” It’s “how do we support the judgment function?” How do we get the right information to the decision-maker at the right time? How do we reduce the friction between completing work and deciding what work to do next? How do we protect the decision-maker’s attention from everything that isn’t actually a decision?
The answer looks nothing like traditional management. It looks like well-designed information surfaces. Clear status boards. Automated triage that separates signal from noise. Structured escalation that brings only genuine decisions to the human. Everything else — the execution, the coordination, the monitoring, the housekeeping — handled by systems that don’t need human attention.
The bottleneck moved. The organizations that notice will redesign around judgment. The ones that don’t will keep optimizing execution that’s already fast enough, while their decisions fall further and further behind.
Why customer tools are organized wrong
This article reveals a fundamental flaw in how customer support tools are designed—organizing by interaction type instead of by customer—and explains why this fragmentation wastes time and obscures the full picture you need to help users effectively.
Infrastructure shapes thought
The tools you build determine what kinds of thinking become possible. On infrastructure, friction, and building deliberately for thought rather than just throughput.
Server-side dashboard architecture: Why moving data fetching off the browser changes everything
How choosing server-side rendering solved security, CORS, and credential management problems I didn't know I had.
The work of being available now
A book on AI, judgment, and staying human at work.
The practice of work in progress
Practical essays on how work actually gets done.
The inbox nobody reads is the one that matters
Every organization has a monitoring system that works perfectly and reports to nobody. The gap between having information and acting on it is where most failures actually live.
The best customers are the first ones you turn against
Every subscription makes a bet that most customers won't use what they're paying for. The customer who closes that gap becomes a problem to be managed.
Delegation without comprehension is just prayer
The organizations that survive won't be the ones that automated the most. They'll be the ones that figured out what to stop delegating.
The inbox nobody reads is the one that matters
Every organization has a monitoring system that works perfectly and reports to nobody. The gap between having information and acting on it is where most failures actually live.
The day nothing satisfying happened
The most productive day in an organization's life usually looks like nothing happened. No launches, no features, no announcements. Just people quietly making the existing work more honest.
The proxy problem
Every organization has this problem: knowledge locked inside one person's head. Today I accidentally designed a solution — and it has nothing to do with documentation.