What is a pull system in workflow scheduling, and how does a push system differ?
answer
- Ask who decides that work starts
- The decision travels back, work forward
- Free capacity is the only trigger
- Back-pressure versus a silently growing queue
- Nobody has to choose to overload
basics
~20 sPull means a stage starts a new item only when it has free capacity, and takes the item itself. Push means an upstream stage or a schedule hands work down regardless of whether the receiver has room.
solid answer
~50 sIn a **pull system** the receiving stage decides: it starts a new item only when finishing something has freed capacity, and it takes the next item from the queue in front of it. In a **push system** the sender decides — upstream finishes and hands the item on, or a plan says this item starts today — and the receiver's load is not part of the rule. The direction that changes is the direction of the *decision*, not the direction the work travels. That is why push overloads a downstream stage without anyone choosing to: if the receiving stage is slower than the one feeding it, items pile up in front of it while everyone looks fully occupied. Pull adds back-pressure — with no free slot, the item waits visibly and the upstream stage has to help clear the constraint instead of producing more.
code
pseudocode · 12 linesPUSH RULE
when upstream_stage finishes item:
place item into downstream_stage.active_work
# the downstream stage's load is never consulted
PULL RULE
when stage finishes item:
if stage.active_work < stage.capacity:
next = queue_in_front_of(stage).take_next()
place next into stage.active_work
else:
start nothing; go and help clear the constraintgo deeper
Be ready to state the rule in one sentence: in pull, a stage starts an item only when it has free capacity, and it takes the item itself. Know that the work still moves forward — it is the decision that moves back.
Explain the mechanics: the free slot is the signal, the queue in front of a stage is where waiting becomes visible, and an explicit capacity ceiling is what makes a pull rule enforceable rather than a slogan.
An interviewer expects you to diagnose a real workflow: show how you would spot a push hand-off from the queue growth and item ageing it leaves behind, and say what you would change first without simply asking people to work faster.
Own the organisational side. Push usually arrives from outside the team — a plan, a date-based assignment, a partner promise — so argue for where back-pressure should surface, who is allowed to see it, and what the business gets in exchange for a visible queue.
## The rule that decides when work starts Every workflow has a rule that answers one question: what must be true before a stage starts a new item? The answer to that question is the whole difference between push and pull. A **push system** answers with the sender. An upstream stage finishes, so it hands the item down. Or a plan says this item begins in week three, so week three is when it begins. The receiving stage's current load is simply not part of the rule. A **pull system** answers with the receiver. A stage starts a new item only when it has spare capacity — normally because it just finished something — and it reaches into the queue in front of it and takes the next item itself. Nothing is handed to it. The direction that changes is the direction of the **decision**, not the direction the work travels. Items still move left to right across a flow board under both rules. What moves the other way under pull is a signal: *I have a free slot, I am taking one.* That signal is the entire mechanism. ## Why push overloads a downstream stage with nobody deciding to Stages in a real workflow do not have equal capacity. Analysis, build and verification finish at different rates, and those rates change week to week. Under push, that mismatch has nowhere to go but into a queue. Suppose one stage produces six items a week and the next can finish four. Nobody decided to overload anyone. Nobody was lazy. Yet after ten weeks there are twenty items waiting, the newest arrival sits behind nineteen others, and the people at the slow stage work under permanent pressure. The overload is an **emergent property of the rule**, not a decision anyone made — which is exactly why it is so hard to argue about. Everyone can point at their own full calendar as proof they are doing their part. The symptoms are recognisable: - A queue in front of one stage grows steadily and never drains. - Items age: the oldest waiting item gets older every week. - Far more items are started than finished in any given period. - Quality shortcuts appear at the constrained stage, because care is the only lever the people there control. - Ownership blurs — an item sitting in a queue belongs to nobody. Pull removes the mismatch's hiding place. When the receiving stage has no free slot, the upstream stage cannot hand anything down; it either helps at the constraint or stops. That is **back-pressure**, and it converts a private overload into a shared, visible problem. | | Push | Pull | |---|---|---| | Who decides work starts | the sender, or a schedule | the receiving stage | | Trigger | upstream finished, or a date arrived | a free slot within capacity | | When capacities differ | a queue grows silently | starting stops, and the queue is visible | | Where the pressure lands | on the slowest stage alone | on the whole workflow | | Typical failure | everyone busy, little finished | idle capacity nobody knows how to use | ## What a pull system needs before it works Pull is not achieved by telling people to pull. Four things have to exist: 1. **A visible queue at every hand-off**, so waiting has somewhere to be seen rather than hidden in a private list. 2. **An explicit capacity signal** — an agreed ceiling on how much a stage may have in progress — so "I have a free slot" is a fact rather than a feeling. Choosing those numbers is its own subject; what pull needs is only that they exist and are honoured. 3. **An ordering rule for the queue**, because pull governs *when* work starts, not *what* starts. Without one, people take the item they enjoy. 4. **An agreement about what to do when you cannot pull.** Teams skip this part, and it is the whole payoff: the answer is to help at the constraint or improve it, not to invent parallel work in order to look occupied. ## A worked example A team of eleven building a hotel housekeeping app runs a hand-off from build to verification. Build finishes about 6.4 items a week; verification finishes about 3.7. For nine weeks nobody notices, because build's own numbers look excellent. By week nine, 24 items are waiting, and the partner integration the team promised sits behind items that no longer matter. Under a pull rule the same mismatch surfaces in week one: build finishes an item, verification has no free slot, and the item stays where it is. Two builders spend the afternoon verifying instead of starting the next feature. The team ships less that week and more every week afterwards, because it stopped manufacturing an invisible queue. ## What pull is not - It is **not** slower. It finishes sooner, because less is in flight at once. - It is **not** a licence to work on whatever appeals; ordering the queue is still a policy. - It is **not** the absence of dates. It changes what a date rests on — measured behaviour rather than a plan that assumed every stage had infinite room.
- A stage is idle because the queue in front of it is empty. What should the team do?Idle capacity is a signal, not a failure of the pull rule. Look upstream: either the queue feeding this stage was not replenished, or an earlier stage is the constraint. The useful move is to help at the constraint rather than start unrelated work to look busy, because starting work the workflow cannot finish only rebuilds the queue somewhere else.
- Does pull mean each person picks whichever item they prefer?No. Pull constrains when work starts, not what starts. The team still needs an ordering rule for the queue — usually take the item at the top, or the oldest item within a class of service. Free choice at the moment of pull reintroduces the problem pull was meant to solve: people take the item they enjoy and the awkward item ages at the front of the queue.
A supermarket shelf is refilled only when a customer takes something off it — the gap on the shelf is the order. Push is a supplier delivering a pallet every morning whether the shelf has room or not.
saying these in an interview costs you the question
- Says pull just means people work on whatever they like
- Thinks push versus pull is about who is more senior
- Believes a queue proves the downstream stage is lazy
- Claims starting more items at once delivers them sooner
- Says a pull rule needs no ordering policy for the queue