Stop Starting — Start Finishing

Pulse Works office, Monday morning. Ren has redrawn the Kanban board with a new rule: no column can hold more than three items at a time. He's written the numbers in red marker above each column. The team stares at it like a traffic sign they don't want to obey.

Ren (蓮) "Okay, new rule. We're adding WIP limits (a cap on how many items can be in any stage at once). No more than three cards in 'In Progress.' No more than two in 'Review.'"

→ WIP limits are the core mechanism of The First Way from The Phoenix Project. By constraining work-in-progress, you force the system to finish work before starting new work.

Hina (陽菜) "But what if someone finishes their task and there's no room to pull a new one? Do they just… wait?"

Ren (蓮) "Not wait — help. If 'Review' is full, you help clear the review queue instead of starting something new. It's a pull system (new work starts only when there's capacity, not when someone pushes it in)."

→ A pull system inverts the default. Instead of assigning work top-down, team members pull the next item when they have capacity. This prevents overload at the constraint.

Tetsu (哲) "So instead of me starting a fourth thing while three are waiting on my review, someone else picks up the review."

Ren (蓮) "Exactly. Our throughput (the amount of work we actually complete per week) hasn't been growing because we keep starting things without finishing them. The board last week proved it."

→ Throughput measures output, not busyness. A team can be 100% utilized and still have low throughput if work sits unfinished in queues.

Hina (陽菜) "Um, I tracked it — the API auth layer took eleven days to go from 'To Do' to 'Done.' That's the cycle time (the time for a single item to move through the entire workflow), right?"

Tetsu (哲) "Eleven days for three days of actual work. The rest was waiting."

Ren (蓮) "That's why we're doing this. Less starting, more finishing. One week. Let's see what happens."