4.3 Solo Sovereign — and managing the executives who hear “orchestrator” as “headcount”

Book 1 · Your Next Job TitleChapter 4 · section 3 of 10

Solo Sovereign is the pattern in which a senior person discovers personal AI throughput and confuses that feeling with organizational capacity. Armed with a coding assistant, a document generator, and a summarizer, they begin preempting the team, shipping unfinished prototypes and specs that other people quietly repair. Each individual act looks like responsiveness, and in aggregate it is a slow replacement of the team’s agency with one person’s dopamine. The idea pipeline dries up, and the silence that follows gets read as agreement when it is usually withdrawal.

I have real sympathy for the Sovereign, which is part of why the pattern is dangerous. Many of these people were strong individual contributors before they managed, and the tools hand back something management took away — the feeling of finishing something before dinner. Completing a loop yourself, with no handoffs and no waiting, produces a hit that approving someone else’s work never will, and the Sovereign may genuinely not be able to distinguish “I am being effective” from “I am feeling effective.” The team can tell. The team is the one merging the broken assumptions at eleven at night and calling it supportiveness.

There is a neighboring executive failure that is worse for organizations, because it travels with budget authority. Senior leaders hear about orchestration, agents, and “intelligence companies,” and almost immediately equate the story with reducing headcount to bare minimums, so the business case leads with what can be stopped rather than what can be built. Token volume gets mistaken for labor: if a person processes fifty requests a day and a model processes five hundred, the arithmetic looks like a ten-to-one ratio and a layoff button. What that ratio does not capture is noticing, escalation, relationships, undocumented process ownership, and the quiet work of holding a fragile system together. Token volume is not labor. Labor is what happens between the tokens.

Which is where orchestrators have to manage up — not as politics for its own sake, but as part of keeping the system honest.

4.3.1 Managing executives

Executives are not the enemy of orchestration; bad framing is. A good executive funds experiments, blocks premature commitments, asks what a tool is for, and refuses to confuse a personal coding binge with management. A dangerous one does one of three things:

  1. Treats every AI initiative as replacement. The proposal never includes a capability section: if a function is removed, what replaces it? If a role is eliminated, what institutional knowledge walked out with it? Modernization that cannot name the trade is a euphemism with a timeline.
  2. Mandates adoption without funding the review load. The tools arrive and the people who must evaluate their output do not, so cognitive overload shows up as “productivity” in the slide deck and exhaustion in the hallway.7

A third failure is quieter: the executive who asks for dissent and rewards agreement. The room learns quickly, and so does the model, if it has been fed that executive’s preferences for a few weeks. Eventually every strategy document arrives sounding inevitable — a mirror with citations.

If you are the person being asked to “orchestrate” a headcount reduction, ask what capability is being purchased, who holds the exceptions, who reviews the evidence when the system is wrong, and who is on call when the customer’s problem is not in the training distribution. Orchestration without those answers is not lean; it is hope with a purchase order.. And if you are the executive reading this, the people pushing back on your agent plan are not necessarily afraid of the future. They may be the only ones still counting the humans who will have to carry the exceptions.

4.3.2 The funhouse version of “transformation”

A particular corporate comedy shows up whenever a technology wave arrives with a savings story attached. The slide says transformation, the spreadsheet says fewer lines, the all-hands says opportunity, and the hallway says who is safe?

Block’s public cuts and Klarna’s public correction are useful here not because every company will copy them but because they make the pattern visible at scale.8 One story treats a smaller team with better tools as the destination; the other treats cost as the measure of success and then discovers that judgment was never designed. Both can be narrated as AI success right up until the customers, the reviewers, or the regulators arrive with inconvenient specificity.

Some routine roles will shrink, and you should say so, fund the paths that remain, and not call a layoff an intelligence company while expecting trust to survive the next incident.


  1. Cognitive overload under AI-assisted work is discussed in Vahid Garousi, “Human Oversight and Overload: Two Hidden and Costly Burdens of AI-Assisted Software Engineering,” arXiv:2606.05770, June 2026, https://arxiv.org/abs/2606.05770, and in the mechanisms carried into Chapter 8 of this book (decision density, context switching, sustained evaluation of plausible alternatives). Cited for the existence of the overload complaint among practitioners, not for a single universal percentage.↩︎

  2. Kari Paul, “Jack Dorsey to cut 4,000 jobs due to AI advances at Square parent Block,” The Guardian, February 27, 2026, https://www.theguardian.com/technology/2026/feb/27/block-ai-layoffs-jack-dorsey, and Block Inc., letter to shareholders (SEC filing exhibit), https://www.sec.gov/Archives/edgar/data/1512673/000119312526076557/d108590dex991.htm. Block cut more than 4,000 roles — from over 10,000 employees to just under 6,000 — and Dorsey tied the decision to intelligence tools; Chapter 1 gives the fuller account. The AI explanation is the company’s own, not a settled causal finding.↩︎