Pull-Based Workload System
Cap work in progress and pull new work only after completion
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 4
- Confidence
- 98%
A Pull-Based Workload System sets an explicit cap on simultaneous work. Instead of allowing anyone to push another task onto an unlimited personal list, the worker or team defines how many items can be active. Additional requests enter a visible holding tank with an estimated order or start time. When an active item is finished and leaves the system, the next priority is pulled into the open slot. The limit reduces juggling and the meetings, messages, check-ins, and cognitive residue generated by every accepted commitment. It also makes capacity legible to requesters: the answer is not a vague claim of being busy but a clear view of current work and when space is likely to open.
Origin
Newport adapted the pull principle from Kanban-style software development and proposed using it more broadly across knowledge work.
Core principles
- 01Active work must have a visible limit
- 02New work enters only when capacity opens
- 03Pending work belongs in a holding tank
- 04Too much concurrent work creates administrative overhead
How to run it
- 1
Set the active limit
Choose the maximum number of items that can receive active attention at once. Make the number explicit before new requests arrive.
Pro tip Start lower than the number of tasks you believe you can juggle.
Watch out A limit that is routinely ignored is not a system.
- 2
Create a holding tank
Put accepted but inactive work into an ordered queue. Record enough information to explain where each request stands.
Pro tip Give requesters a rough start estimate based on queue position.
Watch out Do not treat the holding tank as hidden active work.
- 3
Protect active work
Work the current items without pulling more tasks into progress. Route ordinary incoming work to the queue.
Pro tip Display active and queued work on a simple board.
Watch out Starting a queued item early recreates the push system.
- 4
Finish and pull
Move completed work out of the active area. Pull the highest-priority queued item only when the slot is genuinely open.
Pro tip Define completion clearly so nearly finished tasks do not occupy slots indefinitely.
In the wild
A development team places requested features in a holding area and keeps only a fixed number in progress. A developer pulls the next feature only when the current feature moves to the next completed stage.
→ The team spends less time juggling features and more time completing them.
Common mistakes
Accepting invisible active work
Agreeing to work without putting it in the queue conceals load and reintroduces overhead.
Pulling before finishing
Starting the next item because the current task is difficult defeats the work-in-progress limit.
Is it for you?
Best for
Individuals and teams whose work arrives continuously but can be queued and prioritized.
Not ideal for
True emergencies that must interrupt current work regardless of the active-work limit.
From the transcript
“I only pull something new in when I'm done with something”
“you don't want to be juggling too much at the same time because the overhead gets to you”
From the episode
#722: Cal Newport — How to Embrace Slow Productivity, Build a Deep Life, Achieve Mastery, and Defend Your Time
Cal Newport