One Thing at a Time — WIP Limits, Time Blocking & Calendar Discipline

Build the flow layer that M7's attention layer runs inside. M7 was attention within a task; this module is commitments across tasks — fewer things in flight, an explicit WIP limit, a calendar that is the source of truth for your own work and not just other people's meetings, and a weekly review that keeps both honest. Walk away with a personal Kanban board with defended WIP limits, measured throughput and cycle-time baselines, and a Sunday-evening time-blocking practice with a Friday review. WIP limits are max-pool-size on database connections. You don't run 1,000 concurrent connections to Postgres; you cap at a defensible number and queue the overflow, because beyond the cap throughput degrades — contention, locks, context-switch overhead. The math underneath is queueing theory, and most engineers who would never run unlimited DB connections run unlimited personal WIP and are surprised when throughput drops. Multi-WIP is the N+1 query pattern applied to your time: invisible until measured, shocking once it is. The board makes the N+1 visible; the WIP limit is the eager-loading fix. And carrying eight half-finished tasks is the buffering anti-pattern — memory pressure, held connections, nothing streamed to the client for weeks. Finish-one-ship-one is the streaming refactor. The calendar is the database; deep-work blocks are protected rows; the weekly review is the replica sync that keeps your model of "what's happening" consistent with what actually happened. Defending the blocks is admission control at the calendar level. And the mythical man-month applies to one person: you can't compress sequential work by adding parallelism — including parallelism across your own projects. Five projects at 20% each take longer than five projects at 100% sequentially, and the total elapsed time is longer. The math is in Reinertsen; the lived evidence is in the graveyard you audited in M0.