Process management is over. Manage protocols.

For thirty years, managers have been told that the process is the business. Map it, measure it, redesign it. In 1990 Michael Hammer told them not to automate their old processes but to obliterate them. Business Process Management made the discipline permanent.

It worked, because one premise held: someone could specify the steps.

Agents break that premise. A small team can now run hundreds of thousands of them, around the clock. No one can draw that swimlane, and no approval queue keeps up.

Consider Amazon. In 2002 it did not redesign its teams' processes. It issued one rule: teams work with each other only through published interfaces. Behind the interface, each team built however it liked. One hard rule did what no process map could.

That is Business Protocol Management. It doesn't specify the work. It specifies the few rules at the seams, and leaves the work inside them free.

The practice starts with different questions. Here are six pairs, and where to read more on each.

1. The work
   • Process: What are the steps, and who performs each one?
   • Protocol: Which few rules must hold every time, and where do they live?
   • Read: Hammer, "Reengineering Work: Don't Automate, Obliterate" · BPM guide: key terms
2. Speed
   • Process: How do we make this step faster?
   • Protocol: Which strict rule would let everyone move without asking?
   • Read: Davenport, Process Innovation · Saltzer, Reed and Clark, "End-to-End Arguments in System Design" (Theme V)
3. Ownership
   • Process: Who owns the process?
   • Protocol: Who may change this rule, and who may stop the work?
   • Read: Toyota Production System (Theme VI) · BPM guide: roles
4. Compliance
   • Process: Is everyone following the procedure?
   • Protocol: What could anyone, person or agent, do within this rule's letter that defeats its purpose?
   • Read: OpenAI, "The Hugging Face incident and the road ahead" (Theme I) · BPM guide: protocols are not products
5. Results
   • Process: Did we hit the target?
   • Protocol: What didn't go wrong, and which targets are being gamed?
   • Read: Google SRE, "Postmortem Culture: Learning from Failure" (Theme IV) · BPM guide: measures
6. The future
   • Process: What is the to-be process?
   • Protocol: What could others build on this that nobody planned?
   • Read: McDowell-Sweet on protocol and product thinking · BPM guide: earlier approaches

The lesson of re-engineering still stands: new technology calls for reinvention, not automation. What has changed is what you reinvent. Stop redrawing the process. Find the few rules everything relies on, make them hard, and leave the rest free.

Asking the protocol questions takes practice, because good protocols are invisible until they fail. The protocol watching guide is where the group trains that eye, and the sessions are open.