The Orchestrator

A developer does not become an orchestrator by being handed a more powerful coding assistant, because the surrounding work has to change too. A developer who receives a ticket, asks an agent to write the code, runs the tests, and opens a pull request is still working inside the old model: the tool is faster, and the person is still waiting for a specification and handing the result to the next stage.

Changing the habit means changing the assignment. Training should not be a generic course about writing prompts; it should happen on the systems the organization actually runs. Governance guidance from NIST treats documented roles, accountability, training, and ongoing review as part of the system lifecycle rather than paperwork added afterward, and the same logic applies to how people learn.⁸ Each person should finish with an artifact rather than a completed lesson, because a certificate records attendance while an artifact records understanding, and only one of the two can be reviewed by somebody else. Pair learners with specialists while they do it. A developer learning orchestration should work with a security professional on permissions, a database specialist on data state, an operations professional on recovery, and a customer-service representative on real consequences, which is how people develop breadth without anyone pretending that one person can be the expert in every domain. The path itself — the technical foundation, the supervised assignments, the residency, and the qualification at the end of it — is Chapter 12.