The Orchestrator

A company can test all of this without reorganizing everything first.

2.9.1 Days 1–15: choose one outcome

Select a bounded workflow with a measurable customer or business result. Write the orchestration brief.

2.9.2 Days 16–30: assess and recruit

Map the existing people and skills with the markers from section 11.4.1, and name the responsibilities listed in section 11.7. Identify who needs training, who has expertise that must be preserved, and which roles may shrink.

2.9.3 Days 31–45: build the safe boundary

Give the system read-only access first, as in the tryout in section 11.4.1. Add test environments, scoped credentials, telemetry, evaluation cases, rollback, and Chapter 10’s approval map.

2.9.4 Days 46–70: run the project

Have the people review the evidence and the system’s recommendations. Track review backlog, errors, customer outcomes, specialist workload, and decisions waiting for approval.

2.9.5 Days 71–90: change the surrounding interfaces

Fix the organizational problems the pilot exposes. Create a shared evidence format. Publish security and audit requirements. Add the missing dashboards. Change the release or support process where it is blocking safe action.

At the end of ninety days, ask whether another qualified team could understand and operate the system. If not, the organization has created a dependency on private knowledge rather than a repeatable operating model.