← All episodes
Translated Strategy · · 8 min read

The Dependency Property

You've seen the Station Plan. You understand that it has three parts: a Chef at the center making judgment calls, an orchestrator routing work between agents, and agents doing labor.

You’ve seen the Station Plan. You understand that it has three parts — a Chef at the center making judgment calls, an orchestrator routing work between agents, and agents doing labor.

And you’re thinking — “do we really need all three?”

Every owner thinks this. I mean literally every owner. In the past month alone, I’ve heard:

  • “Can we skip the orchestrator? Isn’t that just middle management?”
  • “If we get the right AI, can we reduce headcount?”
  • “Can’t the owner just manage the agents directly?”
  • “Do we need people if we have good tools?”

Answer is the same every time. Yes, you need all three. And yes, every owner tries to skip one, and every owner hits the same wall.

Here’s the thing — there’s a structural reason why there’s no shortcut.

The three recipes, again

Quick recap.

The Chef. That’s you. Judgment calls that agents can’t make. Defining what done looks like. Owning relationships. Setting strategy. Making calls based on incomplete information and your taste.

The orchestrator. Translating direction from the Chef down to agents. Translating status from agents back up to the Chef. Routing work between agents. Sequencing dependencies. Motor that keeps the system turning.

The agents. Doing the work. Following specs. They don’t develop judgment. They don’t think around the edges. They execute.

That’s the Station Plan.

The dependency property

Here’s the principle that breaks all the shortcuts. Every role is required. Remove any role and the system fails.

Here’s why.

Remove the Chef (the owner). You’ve got an orchestrator and agents, but nobody setting strategy. Nobody making judgment calls that can’t be decided by rule. Nobody defining what done looks like for the specific context you’re in. Orchestrator becomes a firefighter, reacting to urgency instead of following strategy. Agents follow rules, but whose rules? Whose judgment? System drifts.

Remove the orchestrator. You’ve got a Chef and agents, but nobody routing work between them. Chef tries to manage agents directly. This works up to about eight or ten agents. Chef drowns in routing, translation, sequencing. Every routing decision goes to the Chef. Every question goes up. Every edge case stops at the Chef. Chef becomes a bottleneck again. Same jam you had in the pyramid, different shape.

Remove the agents. You’ve got a Chef and an orchestrator, but nobody doing the labor. You’ve designed the strategy and built the routing system, but there’s nobody to execute. No leverage. System never scales.

All three are required. This isn’t opinion. It’s architectural.

The specific mistakes

Let me walk you through what happens when each role is missing, because I see this pattern repeatedly.

The owner tries to manage agents directly (no orchestrator).

You’ve got your team doing work. You think “I can just decide who does what. I don’t need a middle layer.” You build it this way for six months. You’ve got six or eight agents. It’s workable. You’re in their calendars, you’re routing priorities, you’re deciding when to shift capacity.

Then you hire agent nine.

Suddenly you can’t fit it in your head anymore. You’re saying yes to new work before understanding the dependencies. You’ve routed a customer problem but didn’t realize it blocked three other things. You’re approving capacity you don’t have. You’re in meetings constantly. System jams.

This is always where the owner realizes “I need someone in the middle.” That someone is the orchestrator. Not management. Architecture.

The owner tries to have strategy without clarity (no Chef direction).

You’ve built a great team. You’ve got an operations manager coordinating. You’ve got agents executing. But you haven’t defined what strategy is. You haven’t been clear about what done looks like, what the priorities are, how to handle edge cases.

So the orchestrator becomes a firefighter. Every new situation requires a judgment call from above. She’s constantly calling up for direction. Or worse — she’s making judgment calls without clear guidance and you’re rewriting her decisions.

System doesn’t fail spectacularly. It just stays chaotic. Nobody knows what the standard is. Work quality varies. Team is confused about what matters.

This happens because the Chef (the owner) isn’t doing Chef work. They’re trying to manage or delegate judgment instead of making clear calls and setting clear standards.

The owner tries to scale without agents (or without enough agents).

You’ve built a great strategy. You’ve got perfect routing. You’ve got clear specs. And nobody to execute.

This sounds ridiculous until you realize that “agents” can be people, AI, tools, or hybrid. An owner will often build a perfect spec, build a perfect routing system, and then try to execute it all with the same team they had before. No new people. No new AI. Same labor as before, now with a design on top.

Nothing scales.

The owner tries to skip the whole architecture (just a Chef).

This is the pyramid. Owner is the essential node. Everyone else is subordinate. Works until about twenty or thirty people, then it seizes hard because the owner is drowning.

You can’t move forward by hiring more people into the pyramid. You have to change the shape.

Why the wall exists

Here’s the architectural reality — recipes don’t work alone. They work because they’re in relationship with other recipes.

Chef has power because the orchestrator is handling logistics. Take away the orchestrator and the Chef loses all leverage — they’re now handling logistics instead of making judgment calls.

Orchestrator has a role because the Chef is setting clear direction and the agents are following clear specs. Take away either one and the orchestrator becomes useless or drowns.

Agents have a role because they know what done looks like (from the Chef) and they know what to do (from the orchestrator). Take away either one and they’re confused about what to execute.

Right? It’s a system. A system only works when all the parts are present and aligned.

This is why “we’ll just use AI for this part” or “we’ll just hire for this part” doesn’t work as a shortcut. You can’t have half a Station Plan. You can’t have two recipes. System requires all three.

Diagnosing your system

Here’s the practical test. Map what you have right now.

Do you have a Chef? Is there a person making judgment calls, setting strategy, defining the standard? Is that person clear about it? Or are they flying by instinct?

Do you have an orchestrator? Is there a person or a system routing work, translating direction, sequencing dependencies? Is that function designed or accidental? Is the person drowning?

Do you have agents? Are there people or systems doing the labor? Are they clear about what they’re supposed to do? Do they have the specs they need?

If all three are present and functioning, your system should work. If you’re feeling jammed, find the missing role. That’s where the leverage is.

Most common gaps I see:

  • Overwhelmed Owner trying to be both Chef and orchestrator (missing the orchestrator function)
  • Undefined strategy (missing clear Chef direction)
  • Same team, new design (added orchestration without adding labor capacity)

The Monday Move

So. This week, do this.

Map your current system. Not in theory — in reality.

Chef work. Who makes judgment calls? Who defines the standard? Is it one person or distributed? Is it clear?

Orchestrator work. Who routes work between people? Who translates direction? Who sequences dependencies? Is it a person, a system, or hybrid? Is the function designed or accidental? Is anyone drowning?

Agent work. Who does labor? Do they know what done looks like? Do they know what to do? Are they clear on the specs?

You’re trying to find which recipes you have and which are missing.

Once you know, the diagnosis is clear. If you’re jammed, the solution isn’t “work harder.” It’s “man the empty station.”

The choice

Station Plan has three roles. Kitchen only runs when all three are present and aligned. There is no shortcut.

You can try to skip the orchestrator. You’ll hit a wall at about ten agents. You can try to skip clear direction from the Chef. You’ll get drift and chaos. You can try to scale without adding labor. You’ll get burnout.

Every owner tries at least one of these. Every owner hits the wall.

Owners who scale intentionally are the ones who accept the architecture and design for it. They step into the Chef role. They design the Pass. They staff the Line. Then the kitchen multiplies.

So. You already understand the Station Plan. Now understand that the Station Plan requires all the recipes.


Framework: The Station Plan — The Dependency Property as the foundational principle. Companion pieces: The Chef and The Pass — the specific roles that make the Station Plan run.

~ keep going up next
~ if you got value here

Reu talks about this stuff on stages too.

Keynotes, panels, workshops. For conferences, operating companies, and trade associations.

Book Reu to speak →