"We shouldn't PULL information, we should PUSH information."

Two systems push information at me every morning and I built one of them.

The one I built starts at 4:55. Lights up on a curve, the song, then the handoff to the radio, and at some point Jeff Thomas is telling me what happened to the Browns. I did not ask. There is no moment where I query a system about the state of the world. The state of the world arrives, in a fixed order, at a fixed time, while I am doing something else.

That system is very good. I know the score, the weather, and roughly what the day looks like before I am fully upright, and I spent no attention acquiring any of it, because the acquiring happened to me.

The other system is the phone.

It also pushes. It pushes considerably more, with better engineering behind it, and it produces the opposite result. Not because pushing is wrong. Because the decision about what merits a push was made by somebody whose interests are not mine, and because the volume is set by what the sender wants delivered rather than by what I need to act on.

Same mechanism. Opposite outcomes. And the variable that separates them is not push versus pull at all. It is who decided what gets pushed, and against what standard.

We shouldn't pull information, we should push information. I have believed that for a long time and built systems on it, and the morning is the case that proves it. The phone is the case that shows the sentence is missing its governing clause.

Stated as a rule:

The variables are a fact, a person who needs it, and a moment. Pull means the person has to know the fact might exist and go get it. Push means it arrives.

The quantity minimized is the opportunity for oversight, which is the word I have always used and which means something specific. Every pull is a chance not to pull. Information that must be requested is information that gets missed by exactly the people who do not know to ask, which is the people who most need it. That is the real argument and it is a good one.

The failure signal for a pull system is the thing everybody finds out about late, where the information was sitting in the system the whole time and nobody had a reason to look.

The failure signal for a push system is different and the original does not name it: the notification nobody reads. A push system that has exceeded its recipients' capacity produces the identical outcome to a pull system, which is that the information does not reach anyone, and it produces it while looking like it is working.

The domain of validity is where the recipient's attention exceeds the volume of pushes, and that is a budget rather than a principle.

The word should in the original is doing something I did not intend. It reads as a preference for one architecture over another. What I meant, and what survives, is narrower: the burden of discovery should not sit on the person who does not know what they do not know.

The design case for pushing is old, well established, and stronger than the rule as I stated it.

Donald Norman's version is the most useful because it is about where knowledge sits rather than about notifications. He distinguishes knowledge in the head from knowledge in the world. Knowledge in the head has to be learned, retained, and recalled at the right moment; knowledge in the world is present in the situation, so that the thing you need to know is visible at the moment you need it and requires no memory at all. A door that shows you which side to push does not need a sign, and the sign itself is a weak version of the same move.

Read against we shouldn't pull information, we should push information, that is the same claim with the emphasis in a better place. A pull system requires the user to hold, in their head, a model of what information exists and when to go check it. That model is expensive to maintain, decays, and varies enormously between people. Pushing moves it into the world.

Jakob Nielsen's usability heuristics make one piece of it explicit and it is the first on his list: visibility of system status. A system should keep users informed about what is going on, through appropriate feedback, within reasonable time. Not available on request. Informed.

In operations the same idea has been running for a century under the name management by exception. The principle is that a manager should not be reviewing everything; they should be reviewing the things that departed from plan, and those should come to them. Nobody pulls a report to find out whether all two hundred jobs are on schedule. The eleven that are not arrive.

Toyota's andon is the physical version and the most instructive one, because of what it costs. A worker who sees a problem pulls a cord and the line's status becomes visible to everyone, immediately, including to the people who will have to respond. The information is pushed at the moment it is generated by the person who generated it, rather than surfacing later in a report. What makes andon work is not the cord. It is that pulling it is expected, that a response is guaranteed, and that the signal is rare enough to mean something.

And in software architecture the distinction is now a design axis. A system can be built so that components ask each other for state on a schedule, or so that a change in state emits an event that interested parties already subscribed to. The second is push, it scales better, and it removes an entire class of bug where somebody polls at the wrong interval and misses a transition.

There is a vocabulary problem here that I need to deal with directly, because in the tradition I draw most heavily on, pull is the virtue. Lean production is built on pull: nothing is made until the next station signals it is needed, and pushing work into a process that is not ready for it is the cardinal sin. On the surface we shouldn't pull information, we should push information reads as a repudiation of that.

It is not, and the reconciliation is clean. Lean's pull governs work, and its argument is that work should not be pushed onto a station that has not asked, because the result is inventory, queues, and overload. Mine governs information, and its argument is that a person should not have to ask for what they need to act. Those are the same principle. Both say the system should be arranged so that nobody is overwhelmed by material they did not request and nobody has to go hunting for what they need. Push the signal, pull the work.

The evidence is where we shouldn't pull information, we should push information takes its damage, and the damage is severe.

The best-measured push system in the world is the clinical alert. When a physician prescribes a drug that interacts with something else the patient is taking, the system pushes a warning. It is a textbook implementation of the rule: the information reaches the decision-maker at the moment of the decision, without anyone having to ask.

A systematic review and meta-analysis published in 2024 pooled eleven studies covering more than five hundred and seventy thousand prescriptions and found a physician override rate of ninety percent, with a confidence interval running from roughly eighty-six to ninety-five percent. Individual studies ranged from sixty-five percent to almost ninety-eight, with most clustering above eighty.

Ninety percent of the warnings are dismissed. Not ignored through carelessness, mostly, but dismissed because the great majority are not relevant to this patient, and a clinician who stopped to evaluate each one seriously would not be able to see patients. The system is functioning exactly as designed, pushing information to the person who needs it at the moment they need it, and the information is not arriving.

Two caveats belong on that figure and both matter. The heterogeneity statistic in that analysis is one hundred percent, which is as high as it goes and which means the studies are not measuring a single underlying quantity. Alert rules differ, institutions choose different interactions to flag, and collection periods vary. The pooled ninety percent is therefore a summary of a very scattered field rather than an estimate of a stable parameter. And the authors report no systematic assessment of publication bias. So the direction of the finding is solid and the precision is not, and anyone quoting ninety percent as though it were a constant is doing what I warned against in an earlier chapter.

On the cost of the interruption itself, I have to report a correction rather than a finding. The figure everybody cites is that it takes twenty-three minutes and fifteen seconds to recover from an interruption. I went looking for the study. There is no peer-reviewed paper containing that number. It appears to come from interviews with the researcher whose work the claim is attached to, repeated through media and then through everything downstream, and the primary papers do not contain it. It is out of this book on that basis.

What the published work does say is more modest and more interesting. One study reports eleven to sixteen minutes to resolve an interruption before returning to the original task. Another found that interrupted work was completed faster than uninterrupted work, with the cost showing up as significantly higher stress rather than as lost time. That is a genuinely surprising result and it complicates the simple story in both directions: the interruption did not cost what everyone assumes, and it cost something nobody was measuring.

The design problem where I had to price all of this was a notification system on a work queue.

The starting condition was a pure pull system and it failed exactly as the rule predicts. Information about requests lived in a database. Finding out that something needed attention required somebody to open the system and look, which required them to remember, which meant that things sat. The people who missed the most were not the least diligent. They were the ones whose other work took them out of the system for a day.

So we pushed. Every meaningful state change generated a notification to the person responsible.

Within about three weeks it was worse than before.

The volume was the obvious problem and it was not the real one. The real one was that a notification meaning this needs you to do something and a notification meaning this happened, for your awareness looked identical on arrival and had been given the same delivery channel. Once a person has been trained by forty low-value pushes that arriving messages do not require action, the high-value push arrives into that trained indifference. The system had manufactured its own alert fatigue in under a month, at a scale a hundred times smaller than a hospital.

The fix was not volume reduction, though volume came down. It was a split. One channel carries things that require a decision from the specific person receiving them, and that channel is kept deliberately scarce and is expected to be acted on. Everything else is available and goes into a place a person can look at when they choose, which is a pull system, deliberately, for the material that does not merit a claim on attention.

Which means the design that worked is a hybrid, and we shouldn't pull information, we should push information does not describe it.

The boundary is the recipient's attention, and it is a hard budget rather than a soft one.

Everything in the first half of this chapter treats attention as free. Norman's knowledge in the world, Nielsen's visibility of system status, management by exception, andon: every one of them improves a system by moving something into the recipient's awareness, and every one of them is written as though awareness were unbounded. It is not. It is the most sharply bounded resource a person has, and unlike money it cannot be borrowed or saved.

So there is a budget, it is small, and it is spent by every push whether or not the push is useful. A system that pushes information the recipient does not act on has not been neutral. It has withdrawn from an account it cannot repay, and it has also spent something worse, which is the recipient's default assumption that arriving information is worth reading.

That second cost is the one the original never accounted for. Attention regenerates overnight. Credibility does not.

The asymmetry determines what you can and cannot fix. A channel earns credibility slowly, one useful message at a time, and spends it quickly, because the learning runs on a different schedule in each direction. Ten useful notifications do not teach a person that a channel is worth reading; they teach nothing in particular, because the useful ones simply get acted on and leave no lesson behind. Ten useless ones in a row teach a durable lesson in about a week.

Which means a spent channel cannot be repaired by fixing it. Cut the volume by ninety percent and the messages still arrive into a trained response, and that response was learned from a version of the channel that no longer exists, and nothing about the new version announces itself. The recipient has no way to discover the improvement, because discovering it would require attending to the channel, which is the behavior that was extinguished.

What works is worse than a fix, and I have had to do it twice. Retire the channel. Open a new one with a different name, a different delivery path, and a narrow published rule about what will ever appear on it. The new channel starts with no credit and no debt. The old one gets turned off rather than left running quietly, because a channel that still emits is still teaching.

That is expensive, it looks like an admission of failure, and it is the only move I know that works. The prevention is cheaper by an enormous margin, and the prevention is to never put a low-value message on a high-value channel, once, at the beginning, when the volume is small and the temptation is to let one through because it seems harmless.

Three things this rule cannot see.

It cannot see that pushing is a claim on somebody else's time made unilaterally by the sender. Every push is a small transfer: the sender saves the cost of the recipient discovering the information, and the recipient pays the cost of receiving it whether or not it turns out to matter. When the sender is a system that the sender's author does not have to answer to, that transfer has no natural limit, and I have built systems where the limit was my own restraint and nothing else.

It cannot distinguish information from decisions. Those need completely different handling and the original treats them as one thing. A fact that changes what somebody does is worth an interruption. A fact that does not is worth being available.

And it has no theory of the recipient. Push information says nothing about to whom. The most common failure I have seen is not too many notifications; it is notifications sent to a group when only one person can act, which produces the diffusion of responsibility that makes everyone assume somebody else has it.

That failure is worth separating from volume because the fix is different and cheaper. Cutting volume requires deciding what matters, which is hard. Routing to an individual requires only deciding who, which is usually already known and simply was not asked, because a distribution list is the path of least resistance and nobody has to be told they are responsible. A group notification is the sender declining to make a decision and calling it transparency.

Here is the case against, and it was made in 1971 by somebody who was not arguing about notifications.

Herbert Simon, writing about designing organizations for a world that was about to be flooded with information, pointed out the thing everybody designing information systems then and now manages to forget. In an information-rich world, what information consumes is the attention of its recipients. And therefore, in his own words, a wealth of information creates a poverty of attention and a need to allocate that attention efficiently among the overabundance of information sources that might consume it.

Information and attention are in a conservation relationship. They are not two goods you can have more of. Every increase in the first draws down the second, and the second is fixed. Which makes we shouldn't pull information, we should push information, read literally, an instruction to consume more of the scarce resource in order to deliver more of the abundant one.

And the design problem Simon identifies is the exact inverse of the one I have been solving. I have spent a career asking how to get information to people. His claim is that in an information-rich environment the binding problem is not distribution but filtering: the system's job is to withhold, and the valuable design work is deciding what not to send. An organization that succeeds at pushing information has not solved its problem. It has changed a scarcity of information into a scarcity of attention, and the second scarcity is worse, because information can be manufactured and attention cannot.

The clinical evidence is what this looks like when it runs to completion. Ninety percent override is not a system being ignored. It is a system that has spent the entire attention budget of its recipients and is therefore delivering nothing, and the tragedy of it is that the ten percent it should have delivered is in there, indistinguishable, arriving into a population trained to dismiss.

The strongest form of the objection: pushing information is what you do when you have not done the harder work of deciding what matters. It is the easy half of the problem, it feels like service, it is measurable in a way that makes it look like progress, and every unit of it spends a resource belonging to somebody else. We shouldn't pull information, we should push information is a designer's rule written from the sender's chair.

Simon's poverty of attention wins, and the rule has to be rewritten rather than qualified. It is the largest revision in this book.

What I was right about survives. Requiring a person to know that information exists before they can get it is a real defect, it concentrates failure on exactly the people least equipped to avoid it, and it is the failure mode of every system that has ever said it was in the report. The diagnosis was correct.

The prescription was wrong, and it was wrong in a specific way: I treated delivery as the solution to a discovery problem, and delivery is a different thing with its own price. The correct response to people cannot find what they need is not send them everything. It is to decide what would change an action, send that, and make the rest findable.

So the rule becomes a test rather than an architecture, and the test has three parts. Does this fact change what somebody does? If not, it is available, not sent. Does it change what this specific person does? If not, it goes to the person whose action it changes and to nobody else, because a push to five people is four interruptions and a diffusion of responsibility. And is the channel it arrives on reserved for things of that kind? If a channel carries both decisions and awareness, it carries neither, because the recipient cannot triage on arrival and will eventually stop trying.

That last condition is the andon insight and I had not understood it as a condition. The cord works because pulling it is rare and a response is guaranteed. A cord that was pulled forty times a shift would be a cord nobody looked at, and the fix would not be a better cord.

Where Simon does not get the last word: his framing treats filtering as the design problem and leaves open who does the filtering, and that is exactly where the original diagnosis returns. If filtering is pushed onto the recipient, we are back to pull with extra steps, and the person who does not know what they do not know is failed again. The filter has to live in the system, it has to be designed by somebody accountable for what it drops, and its error rate has to be visible. A filter nobody can audit is a pull system wearing a push system's clothes.

Three properties are within reach even without a general method, and each is something a filter can be held to.

It has to log what it dropped. A filter that silently discards is indistinguishable from a filter that is broken, and the log is what lets somebody ask, after an incident, whether the information was available and suppressed. That is an uncomfortable record to keep and it is the only one that makes the filter accountable rather than merely convenient.

Its recipients have to be able to read the rule. Not tune it, necessarily, but know it: you get notified when X, and here is what you do not get notified about. Somebody who knows the boundary of what arrives can go looking for the rest deliberately, which restores a pull channel for the cases the filter gets wrong. Somebody who does not know the boundary assumes the channel is complete, assumes wrongly, and is worse off than under the pull system I was trying to replace.

And somebody has to own its error rate with both directions counted. Filters are almost always evaluated on volume reduction, which measures one kind of mistake. The misses are the expensive kind and they are invisible by construction, so they get counted only if the filter's owner goes and finds them: after any significant surprise, ask whether the system knew and did not say.

I do not have a general method for building that filter, and this is the weakest point in the revision. The clinical case is fifty years of very smart people failing at exactly this, with better data and higher stakes than anything I work on. What I have is a direction, a three-part test, and the andon condition, and the honest position is that the filter is the hard problem and I am handing it forward mostly unsolved. Chapter 18 is where it gets taken up.

What survives:

The original named an architecture and treated attention as free. The revision names a test, prices the attention, and gives up the general claim that push beats pull, because the evidence from the best-instrumented push systems in existence says that a push system past its recipients' capacity delivers exactly what a pull system delivers, which is nothing, while reporting that it is working.

Three things go forward. The filtering problem is unsolved and I have said so. The credibility cost of a spent channel is asymmetric in a way I have only described, not measured. And this rule now collides directly with the one holding that an efficient system minimizes user input while maximizing automated output, because automated output is push, and the next chapter has to price it the same way this one just did.