Pull System

From the side handing work out, assignment is the natural method. Eight items and four people means two each. The problem is that the state of the receiving side never enters the arithmetic. A fourth item goes to someone already holding three, and from the assigning side there's no way to see that two of those three are parked waiting on somebody else's response.

Pagedeck worked that way. Mia assigned items to four developers at the start of the week. Counting at the end of it, six items had been started and one had finished. Theo alone was holding three: one waiting on code review, one waiting on a design decision, and exactly one he was actually touching. The other two sat started and stopped, counted as progress on every report that week.

Work that has been started returns nothing until it finishes. It still has to be managed, explained when someone asks, and re-entered days later by rebuilding the context. A pull system moves the authority over when work starts from the side assigning it to the side doing it, which is the only side that knows what it is already carrying. Nobody hands work out, and whoever finishes takes the next item themselves.

Signals travel opposite to the direction work flows. The upstream stage doesn't push; the downstream stage pulls. Five things get decided.

1. Build the queue. Line up what comes next in order. Deciding that order is still a person's job, usually whoever owns the product. Without the queue, someone with free capacity has to judge what to take on the spot, and then the loudest request arrives first, which is the situation the queue existed to prevent.
2. Set the condition for pulling. Only someone who finished what they were holding takes the next item. How many can be held at once gets pinned by a work in progress limit — the ceiling on items running simultaneously. Without that ceiling the pull rule exists and one person keeps pulling anyway.
3. Use empty space as the signal. On a kanban board, a column dropping below its ceiling is itself the indication that something can be pulled. It's the board that lays work into columns by state to show the flow, and the distinguishing feature here is that no separate signal gets built — the board's state is the signal.
4. Take from the top. You take the top of the queue rather than whichever item appeals. Allow choosing and the hard items keep sliding to the bottom and staying there, and nobody has to decide to skip them.
5. Decide what happens when you can't pull. If the upstream column is empty while your own column is at its ceiling, you don't pull anything new. What you do then isn't wait — it's join whoever is blocked and clear it. Several people converging on one item to flush it through comes from this rule, and it feels wrong the first few times.

Only one thing separates this from assignment: who decides when work starts. What gets built and in what order is still decided by the side assigning it. So adopting this rule doesn't move authority over priority anywhere, which is worth saying out loud before anyone objects.

The first place is the daily life of a team using a board. The morning meeting stops dividing up who does what, and each person pulls when their column has room. Shorter meetings are a side effect; what actually changes is the number of items open at once, which is the number everything else follows from.

Three other places.

1. Between stages — instead of pushing a finished item into review, the review side pulls when it has capacity. Set up that way, the count of items piled in front of review becomes visible, and that number tells you where the bottleneck is: the slowest segment, the one that ends up setting the pace of the whole flow.
2. Support queues — instead of splitting incoming tickets by owner, they stack in one queue and whoever finishes takes the next. In work where people process at different speeds, assignment will always pile up on one side, and the pile is invisible until someone complains.
3. Requests between teams — work handed to another team goes into that team's queue rather than being thrown over. A long queue lets the receiving side estimate when something will happen without asking what is currently in progress, which removes a whole category of status meeting.

Some situations need a compromise. Teams that plan in fixed cycles settle the work at the start of the cycle. There, pulling happens within the cycle only. Items carrying a fixed external deadline get an explicit exception that puts them at the top of the queue, written down rather than negotiated each time.

"Don't assign it, put it on the queue. Whoever finishes will take it."

Leaving the start time to the side doing the work.

"You're holding three. Don't pull anything new — push the one waiting on review."

At the ceiling, so join the blocked item instead.

"Twelve items stacked in front of review. That's where the bottleneck is."

Reading queue depth as a signal.

Pagedeck stopped assigning after that week. Mia arranges the queue and orders it, and nothing more; who starts what, and when, isn't decided. The development column's ceiling was set equal to the number of people.

Two months later, items open at once had fallen from six to four, and cycle time — the span from starting actual work to finishing it — went from an average of nine days to five. Throughput, the count of items finished per week, was almost unchanged. Nothing more got done; what got started got done faster, and the team could say when.

The most common belief is that this means everyone picks the work they feel like. The word "pull" sounds like choosing. But what gets taken is the top of the queue, and that order is still set by whoever owns the product. Treated as choice, people take only what's familiar, and items nobody wants to touch sit at the bottom for months. Once that happens, the order of the queue means nothing at all.

The other common belief is that switching to this makes work faster, since cycle time comes down. But items finished per week usually stay flat. Nobody was added, so there's no reason for total output to rise. What changes is that the same work sits as four open items flowing through rather than six open items parked. Adopt it expecting speed and you'll read throughput two months later and call it a failure, while the predictability you actually gained never enters the arithmetic.