The Orchestrator

It would be convenient to say meetings were waste and orchestration deletes them. That is not true, and organizations that pretend it is true will do something stupid. The meetings were doing seven distinguishable jobs, and orchestration only ends three of them.

Three jobs disappear.

First, meetings described the current system to the people in the room — here is what the returns flow does, here is where we think it breaks. A system with read access can describe the current system more accurately than a roundtable can, and it can do it before anyone books a room. Second, meetings guessed what the data says — is Canada different, do customers abandon at the photo upload. That question is now an overnight query, and holding a meeting to guess at it is a delegation failure, not a discussion. Third, meetings assigned the investigation — the action items, the homework, the reconvene-next-Thursday. When investigation is cheap, assignment meetings are just slow queues.

Four jobs remain, and they are the reason humans stay in the loop.

1. Adding context. The support manager’s oversized-furniture fact, the contract terms, the customer relationship, the thing everyone knows and no database contains. A system cannot add this because it is not in the data; the room exists partly to inject it.
2. Reviewing work. Somebody has to judge the pack — the prototypes, the estimates, the failures. Review is a skill and a job, and Chapter 9’s warning about cognitive load applies directly: evaluating almost-right work all day is exhausting, and it has to be staffed like the real job it is.
3. Challenging work. Finance questioning the estimate is not an interruption of the meeting; it is the meeting. A room that approves every pack is a rubber stamp, and a rubber stamp with better input is still a rubber stamp. Chapter 9 described the sycophancy spectrum, and its distributed form is the organizational version of the same failure: a room full of people, each of them polished all week by agreeable assistants, will agree with whatever arrives unless disagreement is part of the design. The challenge has to be assigned, or the pack will pass unexamined.
4. Deciding and accepting responsibility. Somebody chooses, and somebody’s name goes on the choice. This is the part that cannot be delegated, and it is the part people underrate: a recorded verdict in a system is evidence of a decision, while a room full of people who watched the decision happen is accountability. Some meetings survive orchestration precisely because the institution needs its important decisions made in the open, in front of the people who will live with the consequences.

One more honesty note. Brainstorming is still allowed. A conversation is sometimes the fastest way to find out what the real question is, and nothing in this chapter is against thinking out loud. The failure is not brainstorming; it is using a room to answer questions the data can answer, and then calling the guess a decision.