Pull beats push when the downstream step knows more
💎CORE ARGUMENT
When the next step in a process knows better than I do what it needs, I should wait to be asked.
Push means producing on my own schedule and sending the result downstream, ready or not. Pull means the downstream step signals what it needs and I produce that. Ohno's argument for pull is about stock: push fills the factory with parts nobody has asked for yet, and that pile hides every other problem. Mine is narrower, and about knowledge.
Whoever is closest to the need knows the most about it. A dispatcher at ten to nine knows which three customers will ring if a lorry is late. I do not, and neither does the system. So when the Exceptions Inbox pushed every exception it could detect, 214 per dispatcher before nine, it was overruling the best-informed person in the chain with the output of the worst-informed. Completeness felt like service to us, and for them it was work.
They had told us what they wanted: five things, at 07:00. That is a pull signal, and it had been sitting in my Rotterdam notes since February. I wrote the issue about it in August. I did not write this note until October, in bed with a cold and a book about a car factory, which says something about how long I can know a thing before I believe it.
The rule has a condition, and the condition is in the title. Pull wins when downstream knows more. It loses when downstream cannot know what to ask for: a new kind of failure, a recall, anything the dispatcher has never seen. Those have to be pushed, and loudly. Without pull the dispatcher drowns in the routine. Without any push she misses the one thing that was new.
🧱BUILT FROM
🌍WHY IT MATTERS
For every notification, report or digest I now ask who asked for this, and in what words. If nobody did, it has to justify itself as an alarm. Calling it information is not enough. I have started applying the same question to my own status updates, and they have got shorter.
☑️NEXT STEPS
- Find the Rotterdam notes and quote the dispatchers' own request in the digest proposal
- List which exception types must stay pushed
📖 Ohno on waste and pull: making what nobody has asked for yet is the worst of the wastes, because it hides all the others.
💎 An exception is information about the process and not a nuisance in it: an exception is information, and information has a recipient who decides whether it is worth anything. 💎 Demand swings grow as they travel away from the customer: every stage that pushes on a guess adds its own margin, and the guesses compound.
Information about real need sits at the point of use. Push ignores it, so it produces confidently and in volume from the place that knows least. Pull lets that knowledge set the rate and the mix. The upstream step gives up control and gets relevance in return.
Nobody pulled the Exceptions Inbox itself into existence. Customers did not ask for it, and we pushed it at them. For anything really new, the upstream step knows something the downstream one does not, and waiting to be asked means waiting for good.
Said to readers in 📝 Issue 45 - Pull, do not push. Proposed at work as 🔍 Exceptions digest by e-mail.