Context:
A high productivity design/implementation process or low-latency service process. The scheduling problem is to be addressed on a small scale (i.e., this is not scheduling entire departments, but the work of cooperating individuals).
Forces:
Complete scheduling insight is impossible.
The programmers with the longest development schedules will benefit if more of others' code is done before they try integrating or testing later code, and their interval can't otherwise be shortened (see Code Ownership).
Solution:
If the overhead is small enough, it doesn't affect throughput. It will always improve local latency.
Resulting Context:
The process should have a higher throughput, again, at the expense of higher coupling. Coupling may have already been facilitated by earlier patterns, such as Work Flows Inward, Move Responsibilities, Buffalo Mountain, and Coupling Decreases Latency.
Design Rationale:
See the forces. The intent is that this pattern will apply most frequently between cooperating developers working on a single project. This is supported empirically from a high productivity process in AT&T. There are strong software engineering (operating system) principles as well.
It may be useful to prioritize interrupts, and service the ones that would optimize the productivity of the organization as a whole. That is, it is better to unblock 4 people who are currently blocked than to unblock a single squeaky wheel. The decision-making process should be fast: Most of the time, it should be distributed. Where arbitration is needed, apply Patron. The Patron and Manager can help the team audit the project for blocked progress, but should defer to the Developers (or other directly impacted roles) to resolve the blockage when ever possible.
Maranzano notes a corollary to this pattern is another pattern: Don't put too many critical tasks on one person.
Next: Don't Interrupt an Interrupt