The Orchestrator

The home-goods company this book has followed from the opening chapter has a returns problem. Customers start returns and never finish them, then contact support to ask whether the return was accepted and where the refund is. The product team wants to fix it. Here is what fixing it costs before orchestration.

Monday morning is sprint planning: eight people, two hours, estimating the next two weeks of human attention in story points. Every day there is a fifteen-minute standup in which each person reports status that is already written down somewhere, for the benefit of people who did not read it. Wednesday is backlog grooming: arguing about the order of work that has not started. Thursday is the meeting about the returns problem, and it runs like this.

Ten people. Sixty minutes. Someone from support says customers complain the photo upload is broken. Someone from design proposes a new returns page. Someone suggests a chatbot. Someone asks whether Canada is different from the United States, and nobody knows, because the answer is in a database none of them has open. An engineer — who suspects the trouble is the shipping-label step, because she handled two tickets about it last month — does not have the data to prove it, so she says nothing. The product manager writes action items in a shared document. The meeting ends with homework: engineering will inspect the returns API, support will pull examples, finance will check the refund data, design will sketch a page. Everyone will reconvene next Thursday.

Count what that hour produced. Ten person-hours of salaried time, spent to produce a to-do list. The investigation — the actual work — starts afterward, in fragments, around everyone’s other assignments. The decision arrives two weeks later in a second meeting, consuming another hour of the same ten people.

And the deepest cost is not the calendar. It is the delay. Customers are failing to complete returns, and support is absorbing the contacts, for two extra weeks because that is how long the institution takes to route a question through its only investigation mechanism: assign humans, wait for Thursday.

The rituals around that meeting are not stupid; each one compensates for a real human limit. Sprint planning exists because human attention is scarce and has to be rationed. Story points exist because human throughput has to be estimated before it can be promised. Standups exist because humans forget what they agreed to yesterday. Backlog grooming exists because work accumulates faster than humans finish it. Every ceremony is capacity arithmetic for beings who can do one thing at a time, forget things, and need reminding.

None of those limits describe an orchestrated system. The system does not need its attention rationed; it works while the humans sleep. It does not need its throughput estimated; you can measure it directly. It does not forget across a weekend, and it does not need a Wednesday meeting to decide what to do next. The ceremonies persist anyway, because the institution’s process was built around them, and nobody has asked which meetings exist because the work needs them, and which exist because the work used to.