You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 8: One Thing at a Time — WIP Limits, Time Blocking & Calendar Discipline #

The thing that is going to happen in this module is that you will first laugh at the 3-WIP limit — I have at least eight things going right now; that limit is absurd for someone in my situation — and then you will watch yourself, over two weeks, discover that the eight-things state was a flow-mismanagement artifact, not actual capacity. The discovery is uncomfortable in a particular way: it suggests that what you have been calling "being busy" was something closer to "being stalled across many fronts simultaneously and not noticing." The math underneath is queueing theory, and Reinertsen's first three chapters give you the load-bearing version: as utilization approaches 100%, queue length goes toward infinity, and small variability in arrivals produces enormous queue growth. Translated to your work: if you are booked at full capacity, a sick day, an unexpected client request, or a household emergency causes cascading delays that take weeks to recover from. The right operating utilization for cognitive work is closer to 70-80%, with the remainder reserved for variability absorption. Most builders run at 100%-plus and are then surprised by the cascade, every time, for years. Note also what the Kanban canon was not written for: Anderson and the Poppendiecks wrote for teams, where the WIP limit spreads across many people. For a solo operator with side projects, every project is a parallel WIP item by default — measure honestly and you may find yourself at WIP 10-14 across products, day-job features, writing drafts, and learning commitments. If the engineer with five side projects audits why the projects died, a large share of the deaths were not bad ideas; they were each running at 15-20% of one person's attention, and the math of sustained development at that utilization does not produce shipped product. The graveyard is partially a flow artifact. The fix is the constraint, going forward — and the temptation, once you feel how much WIP=3 constrains you, will be to raise the limit. Don't. If the limit does not fit, shrink the committed-to set (which M6 was supposed to do), not the limit. The integrity of the limit is what makes the system work.

The calendar half of this module comes from a different lineage, and I want to name the merge honestly: one earlier draft of this curriculum built this material from Kanban and flow, the other from time blocking and calendar discipline. They turn out to be the same module aimed at the same enemy — fragmentation — from inside the tool versus inside the day. Start with a prediction about your current calendar that will be uncomfortably accurate: you block meetings — anything where another human will show up and notice your absence — and you do not block deep work. Your own projects happen "between" the meetings, and the gaps shrink under any pressure because no calendar entry is defending them. The result is a calendar that treats other people's claims on your time as immovable and your own claims as flexible. The cure is structural, not motivational: block the deep work with the same inviolability as a meeting with your most important stakeholder, and when something tries to invade the block, decline it the way you would decline double-booking that stakeholder. Paul Graham's 2009 maker's-schedule/manager's-schedule essay supplies the sizing rule: a single 30-minute meeting in the middle of a clear afternoon does not cost 30 minutes — it costs the afternoon, because it splits a maker's block into two fragments individually too small for real work. Defend half-days, not slots, with a designated communications window between them.

Two cadences hold the whole thing together, and both will meet resistance. The Sunday planning session, 30 minutes, feels like weekend contamination; the honest math is that it reclaims 8-12 hours of weekday clarity, because the unplanned week starts with Monday-morning decision load and bleeds an hour a day of re-deciding what to do next. That trade is too clean to argue with once you have run it for four Sundays. The Friday weekly review is the drift-catcher: what shipped, what slipped, what did I learn about my estimation, what are the top three for next week, what landed on my plate that I did not expect. Without it, the calendar drifts from reality and the drift surfaces as a Sunday-night panic re-plan, which is itself low-quality because it is panic-driven. Thirty minutes on Friday keeps the drift small enough to correct cheaply. Meanwhile the board — yes, an actual board with To Do, In Progress capped at three, and Done — will feel performative for the first week. You will move cards and feel slightly silly. By week two it stops feeling performative and starts feeling like infrastructure, the way version control did before it was a reflex. And the cycle-time data the board generates will ambush you: the "I'll knock this out in two hours" task has actually been in progress for four days, with three context switches and two blocking dependencies. Measuring cycle time externalizes what your internal timer was hiding.

Conclusion #

Module 8 is one discipline wearing two outfits: limit work-in-progress in the tool, and defend single-tenant time in the calendar. Run WIP=3 strictly for two weeks; track throughput and cycle time honestly; resist raising the limit and shrink the committed set instead. Block deep work like it is a meeting with someone you cannot disappoint, defend half-days rather than slots, and install the Sunday plan and Friday review as the cadences that keep the system synced with reality. Booked-at-100% is not diligence; it is a queue catastrophe on a timer.

Predictions #

  • Your honestly-measured starting WIP will be 8-14. The number will be uncomfortable, and naming it is the first step.
  • You will defect from the WIP limit about three times in week one, twice in week two, and roughly zero by week three. The defection trajectory is the installation arc.
  • The cycle-time data will reveal several "basically done" tasks that have sat at 80% for weeks — the exact dataset M11 will operate on.
  • You will discover your "reactive" work is mostly not reactive: the majority of it could wait 4-6 hours without consequence. The urgency was a story.
  • The first time you consciously decline a new in-progress item to defend the limit, you will feel something close to guilt — I should be able to handle one more thing. The guilt is the diagnostic; it is why the old pattern was unsustainable.
  • The Sunday session will feel like an imposition for two weeks and become the thing you defend by week four.
  • One long-ambiguous project will move to Done or formally Sunset during the two-week run, and the closure will turn out to have been blocked by the multi-WIP state itself, not by any real reason to keep it alive.