I was at a client site last month — insurance agency, thirty-some people. Smart leader, promoted to Director of Operations about two years ago.
She was drowning.
Not because the work was too much. Because she was in the middle of everything. Owner made a decision, she translated it down to the team. Team had a question, she ran it back up to the owner. Agent had a case that didn’t fit the normal routing, she decided where it went. New priority came in, she resequenced everything.
She was translating constantly. Every direction down, every status back up, every edge case, every handoff.
I asked her how much of her day was routing decisions versus her own judgment work. She looked at the ceiling for a long time.
“Probably 70-30. And that’s not how this job is supposed to be, is it?”
No. It’s not.
Here’s the thing — you’re already the orchestrator of your system. Question is whether you’re going to design the orchestrator role intentionally, or keep drowning in it accidentally.
The architecture you’re already running
Quick context. We’ve been talking about the Station Plan — the shift from a pyramid (boss at top, decisions push down, work pushes up) to a Station Plan (Chef at center, orchestrator as the Pass, agents as stations on the Line).
Chef is the owner making judgment calls. Agents are the people (or AI) doing labor. Orchestrator is the Pass.
But here’s what most businesses don’t name — they already have an orchestrator. Usually the person in the middle. Usually drowning. And usually not designed — it just happened.
That’s the Director of Operations. That’s the Operations Manager. That’s the person who said “yes, I can translate, I can route, I can decide where ambiguous things go.” That’s you, if you’re in that seat.
Right? You’re the Pass. You’ve always been the Pass. Question is — is the Pass designed, or is it just holding the system together through personal exhaustion?
What the Pass actually does
Let’s name it precisely, because the word “orchestrator” can sound theoretical.
Orchestrator does four specific things.
One — routes work between agents. Takes an input, decides which agent owns it based on the spec, gets it there. Simple if the spec is clear. Chaotic if it’s not. About 30% of the orchestrator’s time in a well-designed system. In a poorly designed system, 70%.
Two — translates direction from the Chef down. Owner says “we’re prioritizing renewal retention this quarter” — orchestrator translates that into specific instructions for each agent. Priority weights. Decision rules. What to do if you hit an edge case. This happens constantly. Most orchestrators spend half their time on this and call it “communication” instead of “architecture.”
Three — translates status from agents back up. Owner wants to know if things are working. Orchestrator sees every piece of work flowing through the system. She knows where the rework is, where the bottlenecks are, where agents are confused about the spec. She translates that upward — “here’s what’s working, here’s where we’re jamming.”
Four — sequences dependencies. This job depends on that job being done first. This customer needs service A before they can use service B. This priority has a deadline that affects the schedule for three other priorities. Orchestrator holds all the dependencies in her head and decides what goes in what order. This is the part that looks like “just scheduling,” until you realize that bad sequencing cascades across the whole system.
That’s the Pass. Route, translate down, translate up, sequence.
Why it’s critical
Here’s the thing that’s not obvious — the orchestrator is the reason the Chef can exist.
If there were no orchestrator, every routing decision would go to the Chef. Every agent question would go to the Chef. Every edge case would stop at the Chef. Chef would be in every transaction.
Only reason the Chef can make judgment calls instead of handling logistics is because the orchestrator is handling logistics. Orchestrator is the reason the Chef has leverage.
Flip it — the orchestrator has no power without the Chef. Without clear direction from above, the orchestrator becomes a firefighter, reacting to urgency instead of following strategy. Without agents that are well-specified, the orchestrator drowns in exception-handling.
So the three pieces of the Station Plan are literally interdependent. Remove the orchestrator and the Chef becomes the bottleneck. Whole system seizes.
This is why treating the orchestrator as “middle management” misses the point entirely. Middle management is a rung on the org chart. The Pass is a station. A critical, designable station that makes the kitchen work.
The design function
Here’s where it gets sharp — the orchestrator isn’t a job title. It’s a function. A function that can be a person (the director in the middle), but doesn’t have to be.
In a well-designed system, some orchestration is a person. Some is a system — a workflow that routes jobs automatically. Some is hybrid.
A hospital operating room has an orchestrator — the charge nurse. She’s routing, translating, sequencing. But she’s also got systems supporting her — scheduling software, equipment checkout procedures, handoff protocols. Hybrid.
An HVAC contractor has an orchestrator — the dispatcher. But they also have a system — the routing software that suggests which technician gets which job, the work-order system that specifies what service goes in what order. Hybrid.
Here’s the thing — most small businesses are 100% person because nobody designed the function. The right thing is usually hybrid. Some of the routing is obvious enough to be automated. Some of the scheduling is rule-based enough to be specified. Some of the translation is clear enough to be written down. Person orchestrator handles the exceptions and the judgment calls. System handles the routine.
This is important because the person orchestrator can’t grow past a certain point. You can have one person coordinating 10 people. You can maybe have one person coordinating 30 if the system helps. You can’t have one person coordinating 100 without the system doing most of the work.
So the question isn’t “hire a better orchestrator.” It’s “design the orchestration function so a person can orchestrate at scale.”
Why yours is broken now
If you’re reading this and thinking “yes, I’m the orchestrator and I’m drowning” — you’re not failing. Your function isn’t designed.
You’ve got routing decisions that should be rules, so you’re deciding every time. You’ve got translation that happens in your head instead of in documentation, so you’re explaining the same thing repeatedly. You’ve got sequences that depend on your judgment instead of dependency maps, so you’re resequencing constantly.
None of that is your failure. That’s design work that hasn’t happened yet.
Most orchestrators are accidental. They emerged because someone was smart enough to see the gaps and filled them. That person became essential. That person is drowning. And the business thinks the solution is “hire better middle management” when the actual solution is “design the orchestrator function.” Does that make sense?
Designing yours
Start here — document what you’re already doing.
This week, do this exercise. For three days, keep a log of your routing decisions. Every time you decide “this job goes to this person” or “this customer gets this priority,” log it. Note the decision rule if there is one. Note the edge cases where you’re making a judgment call.
Same with translation. Every time you take direction from above and translate it for the team. Every time you take a question from the team and translate it upward.
Same with sequencing. Every dependency that determines what goes in what order.
At the end of three days, you’ve got a map of what the orchestrator function actually looks like in your system.
That map is the design spec. It’s what you hand to your team. It’s what you hand to a system designer. It’s what you use to decide “which of these decisions should be rules? Which should be documented? Which should stay judgment?”
The Monday Move
So. You’re already the orchestrator. This week, become a documentarian.
Spend two hours writing down —
- What are the routing decisions I make? (What’s the rule? Where does it break down?)
- What are the translations I do? (What does the owner say? What do I translate to the team? What gets lost?)
- What sequences do I hold in my head? (What dependencies exist? How do I decide priority?)
That’s it. Documentation. Not a project. Not a redesign. Just write down what you’re already doing.
Once you’ve got that documented, you’ve got options. You can automate some of it. You can delegate parts. You can build systems around it. You can train the team on the decision rules you’ve been holding solo.
But you can’t design what you haven’t named.
The shift
You came into this role because you were good at holding complexity. Someone noticed you could route work, translate between layers, keep everything sequenced. They said “we need someone in the middle” and you said yes.
You’ve been doing the work for years. You’ve been the Pass of the system. Only question is whether you keep drowning in the Pass or whether you design the Pass so it runs without your personal exhaustion.
You don’t disappear. You move upward. You stop being the person in every routing decision and you become the architect who designs the routing system. You stop translating on the fly and you create the translation protocols. You stop holding sequences in your head and you map the dependencies so the team sees them.
You become the person who orchestrates orchestration.
Most businesses that scale figure this out. They have a moment where the orchestrator says “I can’t keep doing this by hand” and they start designing. That’s the difference between a business that plateaus and a business that multiplies.
So. You’ve been the Pass. Question is whether you’re going to design it.
Framework: The Station Plan — The Orchestrator as the Pass. Companion piece: The Chef — understanding why the Pass is critical to the Chef’s leverage.
