2.4 For managers

Book 1 · Your Next Job TitleChapter 2 · section 4 of 4

You may be reading this because you suspect you already have a Maya. This section is for you.

Do not try to identify orchestrators by counting their AI tools. The recognition signals from earlier in this chapter apply here too.

Then look at the risk of leaving that person alone. If managers do not recognize the orchestrator early and redirect resources to support the role, they may lose that person to burnout or frustration. The system may also remain dependent on one individual who is the only person who knows how it works.

Information technology has gone through inflection points before. The web was one of them. In the first decade of this century, people who knew how to deploy web applications and application servers often saw their careers accelerate because organizations were trying to understand a new way of working. Orchestration may create a similar moment.

Many candidates for the role will be capable engineers who are already ready for more responsibility. Some will be much further ahead of their peers than their age or title suggests. An emerging capability can require organizations to promote people before the usual career ladder says they are ready. That is part of the risk, but also part of the opportunity. Identify the people driving the change. Support them. Hire people to work with them and, when necessary, report to them. This is what the department will become.

2.4.1 If you discover an orchestrator

Do not get angry because the person is using tokens. A good orchestrator may use more inference and more powerful models than a developer using AI for occasional assistance. That is not automatically waste. It can be a sign that someone is using these systems to investigate, think, compare options, and automate work that used to occupy several teams.

There are wasteful ways to use generative AI, and managers should still ask whether the model, method, and amount of inference are appropriate. But cost alone is not evidence of waste. Orchestration consumes tokens at a scale ordinary AI-assisted development does not. Each agent loads context, reasons, acts, checks the work of other agents, and may keep operating after the human has moved on. In a one-hour Gas Town trial, DoltHub’s Tim Sehn reported burning about $100 in Claude tokens — roughly ten times his normal Claude Code rate — and the four pull requests it produced were not usable, which is exactly why token burn must not be confused with outcome.4 Steve Yegge has described running 50 to 60 agents across 21 Claude Max accounts, the equivalent of about $122,000 a month at API token prices.5 The emerging term for chasing consumption itself is tokenmaxxing, after the internal Meta leaderboard that ranked more than 85,000 employees by token burn — a status game, not a productivity metric.6 That is not what I am recommending: tokens are an input, not an outcome. But the people genuinely learning to orchestrate are discovering that they can productively direct an amount of machine cognition that would have looked absurd as an individual software budget only a year earlier. The cost report may be one of the first places management sees the people beginning to use orchestration effectively; the skill is telling that spending from tokenmaxxing, and the only reliable way to tell them apart is what the tokens produced.

The response is not to shut the work down. Ask what the systems produced, what decision they improved, and what authority they were given. Then help the orchestrator choose the right models and methods, set sensible spending limits, and build the review process around the work. The goal is not to minimize tokens. It is to spend them where they produce better decisions and better outcomes.

At 9:12 on Monday morning, Maya looks like an engineer running a few unapproved tools on her laptop. What she has actually built is a faster way for the company to understand its customers, make decisions, and act. The company can force that work back into Jira tickets, dashboards, and PowerPoint decks, making Maya translate execution into artifacts designed for approval — or it can recognize what has already happened and reorganize around it.

Maya is not preparing for the future of work. She is already operating inside it, and the company is the part that has not caught up.

HQ 8 — Authored. I wrote the argument, structure, examples, and prose. AI tools were used for research assistance and light editorial polish; the voice, ideas, and substance are mine.


  1. Tim Sehn, “A Day in Gas Town,” DoltHub blog, January 15, 2026, https://www.dolthub.com/blog/2026-01-15-a-day-in-gas-town/. First-person trial: about $100 in Claude tokens in roughly an hour, about ten times his normal Claude Code cost per unit time; the four resulting pull requests were closed as not usable.↩︎

  2. Steve Yegge, “Fences, not Sandboxes,” 2026, https://steve-yegge.medium.com/fences-not-sandboxes-5719cd9b04bd. Yegge describes running approximately 50–60 agents through 21 Claude Max accounts and estimates the workload at the equivalent of $122,000 per month at API token prices (about $4,000 per day). The figure is his API-equivalent estimate, not what he pays for the subscriptions.↩︎

  3. Gergely Orosz, “The Pulse: ‘Tokenmaxxing’ as a Weird New Trend,” The Pragmatic Engineer, 2026, https://blog.pragmaticengineer.com/the-pulse-tokenmaxxing-as-a-weird-new-trend/. Orosz’s reporting on the Meta internal token leaderboard covering more than 85,000 employees, and on engineers warning that it encouraged waste and code churn. Attributed as Orosz’s reporting; Meta has not published the data.↩︎