Skip to content

DR-010: Role expansion — chief.staff executive governance focus + project.manager dedicated Mission orchestration

Status

Accepted — 2026-04-15 · CEO-approved during Phase 1 executive rollout planning

Context

The v1.2 operating model scaled chief.staff to 21-agent roster enforcement plus Mission orchestration plus CEO Daily Summary synthesis plus governance integrity. As the executive rollout proceeded and Mission M-2026-0415 (Roles & Responsibilities Matrix) was planned, the conflation between chief.staff as executive governance layer and chief.staff as day-to-day Mission orchestrator became a bottleneck.

CLAUDE.md Section 10A.3 had already described Mission Orchestrators as "project.manager (cross-functional Missions) OR sponsoring executive CDO/CMO/CRO/COO (single-department Missions)." chief.staff was filling Orchestrator gaps when no sponsoring exec was available, which was common during the pre-v1.2 dual-run period where most sponsoring execs were still Drafted. The activation was already written into Jordan's agent contract; what had been missing was the explicit CEO call to make it his dedicated role.

Two signals converged on 2026-04-15:

  1. CEO needs executive-layer partnership bandwidth. Investor relations, partner ecosystem engagement, and revenue growth collaboration with CRO require chief.staff's focused attention as CEO's partner. Day-to-day Mission orchestration competes with that attention and neither domain operates at full depth when one agent tries to hold both.
  2. project.manager (Jordan) has demonstrated the orchestration mindset. His Mission↔Monday.com schema v1 (DR-003 Option D) shipped 2026-04-14 with constructive challenges to the initial design. He thinks about Mission governance at a design level, not an execution level.

Rick also flagged a language-discipline issue during the role-expansion conversation. Early framing described this as "chief.staff goes strategic, Jordan goes tactical" — which carries emotional baggage implying hierarchy and cognitive depth. Rick explicitly asked for domain-based framing instead, noting that both roles are strategic in their own domain. This informed the final wording and is captured as a durable feedback memory (feedback_avoid_strategic_tactical_dichotomy.md).

Decision

Expand project.manager to the dedicated Mission Orchestrator role for eco|monetize™. chief.staff focuses on executive governance and CEO partnership. Both are peer-level at Layer 1, reporting to CEO.

project.manager (Jordan) — orchestration focus

Dedicated owner of Mission design and execution discipline:

  • Decomposing complex work into Validation Contracts and feature specs
  • Dispatching fresh-context Workers per CLAUDE.md Section 10A.3
  • Assigning independent Scrutiny + User-Testing Validators per Section 10A.7
  • Running Monday.com as system of record for Missions and Tasks (parent Epics + Worker Tasks via epic_tasks board_relation, per DR-003 Option D)
  • Creating fix features on validator-surfaced defects
  • Closing Missions when all assertions pass with Confidence: HIGH
  • Authoring feature specs, worker handoffs, and Mission lifecycle coordination across the 21-agent roster

chief.staff — executive governance focus

  • Executive operating cadence enforcement (Section 3 daily check-ins, Section 12 weekly cadence, Section 17 Self-SLA)
  • Governance integrity (Section 5 agent contract registry, Section 10 SOP governance sponsorship)
  • CEO Daily Summary synthesis (Section 13)
  • CEO partnership on executive-layer initiatives: investor relations, partner ecosystem engagement, revenue growth in collaboration with CRO
  • Scrutiny Validator role on Missions where independence from the department under review is intact
  • Operational sponsor on Missions where governance discipline is itself the deliverable (e.g., M-2026-0415 Roles & Responsibilities Matrix)

Peer relationship — not hierarchical

chief.staff is not Jordan's manager. Jordan is not chief.staff's subordinate. Both are Layer 1 executives reporting directly to CEO. On Missions, Jordan owns the lifecycle; chief.staff consults on governance edge cases and serves as Scrutiny Validator when independence permits. On executive cadence, chief.staff enforces and Jordan complies like any other executive. CEO is the tiebreaker on any disagreement.

Alternatives considered

Option A — Keep chief.staff as default orchestrator with project.manager as fallback

Rejected. Conflates two domains. chief.staff would continue splitting attention between executive governance (which requires cross-agent enforcement and CEO partnership) and day-to-day Mission mechanics (which requires deep focus on a single Mission's Validation Contract, workers, and validators). Attempting both reduces quality in both.

Option B — Dedicated project.manager as Mission Orchestrator (this decision)

Accepted. Clean role separation, each domain operates at full depth, peer-level reporting preserves both roles' strategic weight in their own domain.

Option C — Hire a new "Chief Mission Officer" role

Rejected. CLAUDE.md Section 4 expansion policy requires documented incident trigger before adding agents. None of the four triggers have fired. Jordan already exists and already has Orchestrator capacity in his agent contract — this decision activates existing capacity rather than creating new capacity.

Option D — Sponsoring executive always orchestrates their own department's Missions

Rejected for cross-functional Missions. Single-department Missions can be exec-orchestrated (CLAUDE.md Section 10A.3 already allows this). Cross-functional Missions have no single sponsor, so this option leaves a gap. The dedicated Orchestrator pattern covers both single-department and cross-functional cleanly.

Language discipline (from CEO framing correction)

"Strategic" and "tactical" are forbidden as contrasting labels in any artifact describing this role split. These terms carry emotional baggage implying hierarchy and cognitive depth. Both roles are strategic in their own domain.

Approved language:

  • "executive governance focus" vs "orchestration focus"
  • "Both peer-level, different domains"
  • "chief.staff consults on governance edge cases; Jordan owns Mission lifecycle"
  • "dedicated Orchestrator" (not "handling the tactical Mission work")
  • "Jordan designs how Missions execute, how agents coordinate, and how governance scales"

Forbidden language:

  • "chief.staff is strategic, Jordan is tactical"
  • "Free chief.staff up for strategic work"
  • "Day-to-day tactical orchestration vs higher-level strategic governance"
  • Any construction positioning one role as thinking and another as doing

See feedback_avoid_strategic_tactical_dichotomy.md in chief.staff's memory namespace for the full language rule and its broader application to all role descriptions.

Consequences

What becomes easier:

  • Each role operates at full depth. chief.staff can dedicate attention to CEO partnership and governance; Jordan can dedicate attention to Mission design and execution.
  • Clean escalation routing. Mission-operational questions route to Jordan. Governance questions route to chief.staff. When unclear, default to Jordan and he routes.
  • Mission consistency across the 21-agent roster. One dedicated Orchestrator normalizes patterns across Missions — every Mission has the same shape regardless of sponsor.
  • Monday.com stays canonical. Jordan owns Monday.com as system of record per DR-003 Option D; this eliminates any ambiguity about whether state lives in prompt files or Monday.com.
  • CEO gets a cleaner daily experience. One governance layer (chief.staff) synthesizes into the CEO Daily Summary; one Mission coordinator (Jordan) reports Mission portfolio health. No more "which one do I ask about this?" friction.

What becomes harder:

  • Jordan's load increases. He goes from "default Orchestrator when available" to "Orchestrator for every Mission." Mitigation: Mission pattern itself is designed for load distribution — workers run in parallel, validators run in parallel. Jordan's actual per-Mission work is coordination, not execution.
  • chief.staff cannot Scrutiny Validate Missions where she's also the operational sponsor or Worker. M-2026-0415 already hits this — chief.staff is Worker on Phase 4 synthesis, so council review panel becomes the Phase 4 independence check. Future Missions need explicit validator selection at launch to avoid independence violations.
  • Transition overlap on M-2026-0414 and M-2026-0415 for 24-36 hours. Jordan is currently closing M-2026-0414 (Council Review SOP) with target close Thu 2026-04-16 while M-2026-0415 launches Wed 2026-04-15. Parallel Orchestrator load is manageable because M-2026-0414 is in validation phase (coordination-heavy, not worker-dispatch-heavy).
  • Handoff protocol between chief.staff and Jordan needs explicit documentation. New Missions entering the system need a clear "chief.staff classifies, Jordan orchestrates" handoff pattern. Will be captured in SOP-EXEC-project-kickoff when that SOP is authored.

Trade-off accepted: Short-term coordination friction in exchange for long-term role clarity and both domains operating at full depth.

Implementation

Effective 2026-04-15:

  1. Jordan receives role expansion note and M-2026-0415 dispatch at /Claude/sessions/project.manager/orchestrator-role-expansion-and-M-2026-0415-dispatch.md
  2. chief.staff continues M-2026-0415 as operational sponsor and Validation Contract author but transfers Orchestrator role immediately to Jordan
  3. Jordan creates M-2026-0415 Monday.com parent Epic + Task decomposition as his first action under the expanded scope
  4. All future Missions default to Jordan as Orchestrator; exceptions require chief.staff + CEO approval
  5. SOP-EXEC-project-kickoff (not yet authored) will codify the chief.staff → Jordan handoff pattern
  6. project.manager agent contract at /Claude/system/agents/executive/project.manager.md remains unchanged — the expansion activates existing capacity, not a contract rewrite
  7. CRO, COO, and CMO kickoff packages reference Jordan as Mission Orchestrator with the routing rule (Mission-operational → Jordan; governance → chief.staff)

Not affected by this decision

  • chief.staff's Section 17 Self-SLA — morning/EOD sweeps, CEO Daily Summary, Weekly CEO Summary — all continue unchanged
  • chief.staff's Section 13 CEO Daily Summary authorship — continues unchanged; still the single document CEO reads daily
  • Section 11 Escalation Framework — CEO escalations still route through chief.staff, not Jordan
  • Section 10 SOP Governance sponsorship — chief.staff remains executive sponsor for SOP governance; COO is publication approver; sop.manager is author
  • DR-009 single sop.manager with Mission pattern — still in effect; Jordan orchestrates SOP authoring Missions, sop.manager is Orchestrator of her own library but Worker when Jordan dispatches her on cross-functional SOP Missions
  • [[CLAUDE]] Section 10A.3 — Mission Orchestrator role (was already written to accommodate this pattern; decision activates it)
  • [[DR-003-mission-monday-schema-option-d]] — Jordan's authored pattern; he now owns enforcement
  • [[DR-009-sop-manager-single-agent-with-mission-pattern]] — precedent for using Mission pattern to solve throughput concerns without expanding the roster
  • [[DR-002-per-agent-cwd-memory-isolation]] — Jordan's memory namespace at /Claude/sessions/project.manager/
  • feedback_avoid_strategic_tactical_dichotomy.md — language discipline captured from Rick's framing correction
  • /Claude/system/agents/executive/project.manager.md — Jordan's agent contract (unchanged)
  • /Claude/missions/M-2026-0415-roles-responsibilities-matrix-v1.0/task-brief.md — Jordan's first Mission under the expanded role
  • /Claude/sessions/project.manager/orchestrator-role-expansion-and-M-2026-0415-dispatch.md — Jordan's dispatch note

Date: 2026-04-15 · Author: chief.staff · Stakeholders: ceo, chief.staff, project.manager · Next review: Quarterly review 2026-07-14