Topics

Pull vs push: why kanban models pull and what changes when it does

Push systems shove work into people; pull systems let people draw it when they're ready. The difference shows up in calendar pressure, blocker rates, and how often the team gets sick.

Pull system
Production
Lean
Concepts
Finn Glas
Finn GlasCo-Founder + Engineering
·April 29, 2026·
4 min read

Pull is the difference between asking your team to commit to ten cards by Friday and letting them take the next card when they finish the current one. The first sounds productive; the second actually is.

The two systems, side by side

Push: work is assigned in advance based on someone's plan or estimate. Monday morning the team gets handed a list of what to ship by Friday. The system optimises for the planner's view of the week. Pull: work waits in a backlog. People draw the next card when they finish the current one - no commitment beyond that. The system optimises for the actual rate the team can absorb. Same work, different mechanism, very different downstream effects.

Why push feels right and is often wrong

Push is intuitive for managers and miserable for teams. Three reasons it persists: it gives the planner a sense of control; it produces a clean weekly status report; it matches how non-production work (announcements, customer commitments) shows up. The cost is invisible to the planner: when the plan misses (most weeks), the team carries the failure - either by staying late, by cutting quality, or by quietly absorbing the variance into next week's plan. The board's optimism becomes the team's unpaid overtime.

What pull buys you in practice

Calendar honesty. A pull system can't lie about throughput because the rate is set by what the team actually finishes, not by what someone wished they'd finish. Lower blocker rates. Pull systems give the team agency to refuse work that has structural issues (missing input, ambiguous brief); push systems force them to start anyway. Better recovery from disruption. When someone's sick, a pull system slows down evenly; a push system thrashes because the assigned-but-now-unstaffed cards become an emergency.

Push optimises for the planner; pull optimises for the team's actual rate.
Push hides variance as overtime; pull surfaces variance as honest throughput.
Push fails on disruption; pull degrades gracefully.

The pull discipline test

Look at this morning's first move. Did someone assign the day's cards to people, or did people take their next card from the backlog when they sat down? If it's the first, your board is a push system in kanban clothing. If it's the second, you're running pull and the board is doing its job.

Where push still earns its place

Two cases where push is the right model. Hard customer deadlines that exist regardless of internal capacity (a wedding date doesn't move because the team had a slow week). The schedule is genuinely external; the team has to either stretch or refuse the work, but they can't pull-pace the deadline. Cross-team handoffs with strict SLAs: if your team is the input to another team's schedule, the second team needs a firm commitment they can plan against. The honest move there is to negotiate a realistic SLA based on observed throughput, then push to that, not to wishes.

How Production Board makes the model explicit

{PRODUCT} is a pull-shaped board. The dashboard surfaces "next available card" per phase based on owner availability and WIP capacity; the team draws from the backlog rather than being assigned a week ahead. WIP limits enforce the pull discipline - cards can't be pushed into a phase already at capacity, the planner can't override the limit, the team's actual rate sets the rate. Hard customer deadlines are honoured by tagging the card with a delivery date and surfacing them at the top of the backlog so they're never accidentally deprioritised.

FAQ

Frequently asked

Share this article

Try Production Board

Free plan, no credit card. We host in Germany. You can export and delete everything self-serve.

Finn Glas

Written by

Finn Glas

Co-Founder + Engineering

Finn is one of the Co-Founders. He owns the engineering side, the infrastructure, and most of the late-night fixes that ship before anyone notices.

finn.glas at aicuflow dot comLinkedInWebsite