Reduce commitments ~30% during high-demand months vs. baseline — match project load to measured seasonal capacity, not aspirational capacity

Why This Is a Rule

High-demand months have approximately 30% less available capacity than baseline months for most professionals. The 30% comes from the convergence of multiple demand sources: holiday obligations consume personal time, year-end or quarter-end processes consume work time, seasonal events consume both, and cumulative fatigue reduces productive hours per day. The exact number varies by individual and period, but 30% is a robust starting point calibrated against most people's seasonal audit data (Audit the past 12 months of calendar data — rate each month as low/baseline/high-demand/crisis to reveal recurring seasonal patterns).

The critical insight is that this reduction should apply to project commitments (the number of active projects and deliverables you take on), not to effort (how hard you try). Most people respond to high-demand periods by trying harder — working longer hours, skipping recovery, running on caffeine and adrenaline. This maintains project count at the cost of quality, health, and sustainability. Reducing project count by 30% while maintaining normal effort produces better outcomes: fewer projects completed well rather than many projects completed poorly.

The "measured capacity data" clause prevents arbitrary reduction. The 30% is a starting estimate; your actual seasonal capacity differential might be 20% or 40%. Audit the past 12 months of calendar data — rate each month as low/baseline/high-demand/crisis to reveal recurring seasonal patterns's audit and Forecast high-demand capacity from last year's same-period actuals, not from your current energy — the outside view beats the inside view's reference class forecasting provide the data to calibrate this number to your specific reality.

When This Fires

• When planning project commitments for an upcoming high-demand period
• When you notice you always overcommit in certain months and underdeliver
• When implementing Make at least one structural adjustment before each high-demand period — push deadlines, reduce projects, or front-load preparation's structural adjustments and deciding how much to reduce
• Complements Audit the past 12 months of calendar data — rate each month as low/baseline/high-demand/crisis to reveal recurring seasonal patterns (seasonal audit), Make at least one structural adjustment before each high-demand period — push deadlines, reduce projects, or front-load preparation (structural adjustment), and Forecast high-demand capacity from last year's same-period actuals, not from your current energy — the outside view beats the inside view (reference class) as the specific commitment-level action

Common Failure Mode

Equal commitment across all months: planning 5 active projects per month regardless of seasonal demand. During baseline months, 5 projects are manageable. During high-demand months, 5 projects plus seasonal obligations exceed capacity, producing the familiar pattern of December burnout and January guilt about what didn't get done.

The Protocol

(1) Calculate your baseline monthly project load: how many active projects do you carry during a normal month? (2) For months rated as high-demand in your seasonal audit (Audit the past 12 months of calendar data — rate each month as low/baseline/high-demand/crisis to reveal recurring seasonal patterns), multiply by 0.7: if baseline is 5 projects, high-demand months get 3-4. (3) For crisis months, multiply by 0.5: if baseline is 5, crisis months get 2-3. (4) Apply the reduction proactively: decline, defer, or delegate projects before the high-demand period starts (Make at least one structural adjustment before each high-demand period — push deadlines, reduce projects, or front-load preparation). Don't wait until you're overwhelmed. (5) Calibrate the percentage using your actual data: if you consistently complete 3 projects in high-demand months despite planning 5, your actual capacity reduction is 40%, not 30%. Adjust accordingly.