Orchestrator Guide
Operator Fluency at scale
A guide for Orchestrators ready to build a fluent team.
You’ve already won the personal game.
You run multiple agents in parallel. Your CLAUDE.md updates itself. Your slash commands eliminate everything you used to do twice. You’re operating at the leverage of a small team, alone.
The personal game is over. You’re at the ceiling of what one person can extract from this technology.
So the question shifts.
If your output is no longer the bottleneck, what is?
The answer, for almost every Orchestrator, is the same: the operators around you. Your direct reports. Your peers. The teams you depend on. They’re stuck at Tourist or Builder level. They’re hitting limits you don’t hit. They’re asking for help with problems you’ve already solved. They’re slowing you down by being slower than you.
Personal leverage compounds in months. Organizational leverage compounds in quarters.
This guide is the bridge.
The shift in what you’re optimizing
For the last twelve weeks (or twelve months, depending on how fast you climbed), your job was to become more fluent.
That job is done.
Your new job is to make the operators around you more fluent. Not by teaching them everything you know. By building the conditions where they can climb the ladder you already climbed.
This is a different skill.
The personal game rewards depth. The organizational game rewards transfer. You can be the most fluent operator in the world and still produce zero organizational leverage if nobody around you can use what you’ve built.
Three patterns separate Orchestrators who scale fluency from Orchestrators who plateau alone.
Pattern 1: The codified CLAUDE.md as team artifact
Your personal CLAUDE.md is a competitive moat. Every mistake the agent has made over the past six months is captured as a rule. Every preference you’ve expressed is encoded. Every shortcut you’ve discovered lives in that file.
Most Orchestrators treat it as personal property. Don’t.
The compounding play is publishing it.
Take your project-level CLAUDE.md and split it into two files. Personal preferences and project-specific decisions stay private. The patterns, conventions, and codified mistakes go into a team CLAUDE.md that lives in the repo.
Now every operator on your team starts smart. They don’t reinvent the rules you already learned. The agent doesn’t make the mistakes you already trained it out of. The team’s collective fluency compounds in your CLAUDE.md the way your personal fluency compounded in your private one.
The discipline is the same as before. When the agent makes the same mistake twice, somebody updates the team CLAUDE.md. First time is a one-off. Second time is a pattern. Patterns get rules.
The difference is that “somebody” is no longer just you.
The block: Most teams who try this fail at governance. Everyone edits CLAUDE.md. Conflicts pile up. Nobody owns it. It becomes stale within a month and people stop trusting it.
The fix is treating CLAUDE.md like any other piece of production infrastructure. One owner. Pull requests for changes. A monthly review pass to cut what’s stale. Treat it as a living document with the same discipline you’d apply to a config file in your codebase.
After six months, your team CLAUDE.md is a competitive asset. New hires onboard onto it in a day. Existing operators stop making whole categories of mistakes. The agent gets smarter while you sleep.
Pattern 2: Fluency mentorship over fluency training
The instinct, when you have a team of Tourists and Builders, is to train them. Run a workshop. Build a course. Buy them a book. Set up office hours.
This doesn’t work.
Fluency is not a knowledge transfer problem. It’s a habit problem. Operators don’t become Builders by learning what /clear does. They become Builders by /clear-ing reflexively, twenty times a day, for two weeks.
You can’t train a habit. You can only model one.
The pattern that works: pair an Orchestrator with a Builder for one week. Pair a Builder with a Tourist for one week. The senior operator doesn’t teach. They work alongside. The junior operator watches and copies.
This is the pattern Anthropic’s own engineering team uses internally. It’s also how YC startups onboard new hires onto agentic coding workflows. The senior person doesn’t lecture. They share their screen, run their normal workflow, and let the junior person see the reflexes.
A Tourist watching an Orchestrator work for one hour learns more than they would in a week of self-study. Not because the Orchestrator is teaching. Because the patterns are visible.
The block: Most Orchestrators don’t think their workflow is teachable. They’ve internalized the patterns so deeply that they can’t see them anymore. They underestimate how much value a Tourist gets from just watching.
The fix is volunteering yourself. Once a week, share your screen for an hour while you work. Don’t perform. Don’t slow down to explain. Just work normally and let people watch. The next week, ask one of the operators on your team to do the same with a Tourist on theirs.
After a quarter of this, fluency cascades. You’re not teaching. You’re modeling. The patterns spread because they’re visible.
Pattern 3: The fluency assessment as a performance signal
Most teams measuring AI adoption look at consumption. Seats deployed. Tokens used. Plan caps hit.
You already know this is wrong. The framework page makes the case. The chart in Section 04 shows the math.
The Orchestrator move is replacing the consumption metric with a fluency metric.
Run the Operator Fluency Assessment across your team once a quarter. Capture the persona distribution. Track movement over time. Tourists becoming Builders is the leading indicator of organizational AI leverage. Builders becoming Orchestrators is the multiplier.
This is not a performance review tool. Don’t use it to rank people. Don’t tie it to compensation. The moment fluency becomes a stack-rank metric, operators game it instead of building it.
What it is: a diagnostic for the operators themselves and for you as the leader. Tourists who don’t move to Builder in a quarter signal a coaching opportunity. Builders who don’t move to Orchestrator in two quarters signal a mentorship gap. Distributions that don’t shift over time signal a team-level cultural problem with how your organization treats AI work.
The block: Most leaders treat “AI adoption” as a binary. Either someone uses Claude Code or they don’t. The assessment forces a more honest reading: how well are they using it.
The fix is committing to the cadence. Quarterly assessment. Persona distribution at the team level. One-on-one conversations with operators who don’t move between assessments. Public celebration when someone climbs a rung.
The metric is leading. Builders ship more than Tourists. Orchestrators ship more than Builders. If your team’s persona distribution is shifting toward fluency over time, your organizational output is shifting in lockstep. The assessment is the early signal.
The realistic timeline
You’re not going to have a fluent team next month.
Personal fluency compounds in twelve weeks. Organizational fluency compounds in a quarter, minimum, and usually two.
A realistic ramp.
Month 1: Publish the team CLAUDE.md. Establish the governance. Run the assessment baseline across your team and capture the persona distribution.
Month 2: Start the mentorship pairings. Once a week, one hour. Senior operator works, junior operator watches. Rotate pairings monthly so different operators see different fluency levels.
Month 3: Run the assessment again. Compare distribution to baseline. Have one-on-ones with operators who didn’t move. Celebrate operators who did.
Months 4 through 6: Maintain the cadence. Update CLAUDE.md weekly. Run mentorship monthly. Re-assess quarterly. The compounding kicks in around month four. Before that, it feels like overhead. After that, the team’s collective output starts to climb in a way that’s visible in your shipping data.
By month six, you have a different team. Not because anyone got hired. Because the team you already had became more fluent in the technology you’re already paying for.
What’s on the other side
The personal game capped your output at the leverage of a small team.
The organizational game uncaps it.
A team of five Builders, with one Orchestrator pulling them up the ladder, ships more than a team of fifteen Tourists. Your headcount didn’t change. Your output multiplied because the operators got better.
This is the move most Orchestrators never make. They get to native fluency, plateau alone, and watch the team around them stay stuck. The output gap between them and the rest of the team becomes a personal liability instead of an organizational asset.
The ones who scale fluency don’t do it by being heroes. They do it by treating their CLAUDE.md as team infrastructure, modeling their workflow once a week, and measuring the persona distribution like any other operational metric.
If you’ve made it this far, you have everything you need to start.