Weekly Rhythm — The Canonical Week

A 13-month plan lives or dies on the shape of one specific week. If the week is honest and the week is sustainable, thirteen of them make a quarter and four quarters make the M13 pitch. If the week is a fantasy — “I’ll do four hours every evening” — you will quit in month five and be furious with yourself.

This file specifies the canonical week: what a green week looks like given your constraints (Zoho full-time job, Chennai commute or WFH, family and social obligations, 10–15 hours of personal time). It also specifies the slippage rules (green/yellow/red), so that when a week does not go to plan — and half of them will not — you have a decision procedure instead of a spiral.

Read this file once. Then print the weekly table and tape it inside your notebook.

The Constraints (Honest)

  • Zoho job: 9–10 hours/day including commute or context-switch, Mon–Fri. Non-negotiable.

  • Personal time available: ~15 hours in a good week, ~10 in a normal week, ~6 in a bad week.

  • Sleep floor: 7 hours/night, non-negotiable — see ../13_discipline/08_health_burnout.md.

  • Family/social obligations: at least one evening/weekend day per week is not yours on average.

  • Body: Chennai heat Apr–Jun, monsoon Oct–Nov — evening energy varies.

The canonical week is designed for 12 hours of Java work — mid-point between good and normal weeks. Green weeks bank the extra, red weeks eat the buffer.

The Canonical Week (12 hours)

Day

Block

Duration

Purpose

Monday

Evening

1.5 h

Refresh block. Re-open the sprint’s phase file. Type one small program. Read one section. Low-stakes momentum.

Tuesday

Evening

1.5 h

Deep block A. The hardest thing this sprint. If you only get 90 minutes of deep work in the whole week, they happen here.

Wednesday

— (rest)

0

Family / exercise / sleep. Non-negotiable rest evening. You are not falling behind by taking Wednesday off; you are staying employed.

Thursday

Evening

1.5 h

Deep block B. Second hardest thing this sprint. Or the thing that unblocks Friday morning.

Friday

Morning

0.5 h

Micro-review. 30 minutes with coffee before Zoho work. Skim one page of the phase file. Write one line in the lab notebook.

Saturday

Morning

3 h

Long block A. Uninterrupted. This is where the sprint deliverable moves 40%. Phone in another room. No tutorials during this block — code only.

Saturday

Late afternoon

1 h

Publish / polish. Commit, push, update README, fix a linter warning. The kind of work that doesn’t need a fresh brain.

Sunday

Morning

2.5 h

Long block B. Second half of the weekend deliverable. This block usually ends with something committed to GitHub.

Sunday

Evening

0.5 h

Sprint pulse + notebook. 30 minutes writing what shipped this week, what didn’t, what tomorrow-morning-you needs to know.

Total: 12 hours. Deep-work hours: 8. Support hours (review, publish, notebook): 4.

Why This Shape

Three design decisions worth understanding:

  1. Wednesday is off. Not “if I have time.” Off. A mid-week rest evening is the single strongest predictor of whether a knowledge worker will finish a year-long plan. The urge to “just do 30 minutes” on Wednesday is the urge that leads to burnout by M6. Resist.

  2. Saturday morning is the load-bearing block. Three uninterrupted hours — phone in another room, no Slack, no Twitter, no YouTube — does more sprint work than the four weekday evenings combined. Protect it. If you have to skip one thing in the whole week, do not skip this.

  3. Friday morning micro-review exists to make Saturday possible. 30 minutes of skim-and-plan on Friday morning means Saturday’s 3-hour block starts with a specific first move, not with 45 minutes of “where was I.”

Green / Yellow / Red — The Slippage Rules

The week you actually get will not match the canonical week. Every week is classified honestly at Sunday evening’s notebook entry:

🟢 Green Week (≥ 10 hours of real Java work)

Sprint deliverable is on track. Log the retro, ship what’s due, take the extra time (if any) to bank one blog draft or refactor one older commit. Do not add scope.

🟡 Yellow Week (6–9 hours)

Sprint deliverable is at risk but recoverable. Do exactly one thing this weekend:

Do not cut sleep. Do not eat into next week’s Wednesday. Two yellow weeks in a row: yellow-week response applies to both.

🔴 Red Week (≤ 5 hours)

Something happened. Wedding, family emergency, Zoho crunch, illness. This is what the quarterly buffer weeks exist for. Response:

  1. Log the slip in the slippage template (see 02_sprint_calendar.md).

  2. Check whether the quarter’s buffer week is still available.

  3. If buffer available → absorb into buffer. Sprint deliverable slides one sprint.

  4. If buffer already spent → cut sprint deliverable to minimum viable (the one thing that goes public), drop everything else. Move to next sprint clean.

  5. If two red weeks in a row → go read ../99_pre_mortem/09_summary_and_reset_protocol.md. Do the reset.

A red week is not failure. Three red weeks in a row without a reset conversation — that is failure.

India-Specific Notes For The Weekly Rhythm

  • Monday-morning Zoho standup fatigue. Do not schedule Monday-evening deep work if your Mondays at Zoho are release days. Move the 1.5h refresh block to Tuesday morning if needed.

  • Chennai heat (Apr–Jun 2027, M10–M12). In Chennai’s peak summer, evening energy drops. Shift the two deep blocks (Tue/Thu) to Tue/Thu mornings (6:00–7:30 am) and use evenings for the light refresh + publish blocks. Your AC bill will thank you. Your Rung 7/8 will ship on time.

  • Chennai monsoon (Oct–Nov 2026, M4–M5). Power fluctuations are real; keep an offline copy of the current phase file. UPS or laptop-battery hygiene matters when the sprint deliverable is on a Saturday morning and the grid blinks at 9:15 am.

  • Wedding season (Nov 2026 – Feb 2027, M5–M7). Assume 3–4 lost weekends across these months. Front-load reading into weekday evenings during these months, keep Saturday morning free for the make-up weekend when the wedding was last week.

  • Diwali (Oct/Nov 2026) and Pongal (Jan 2027). Family-first weeks. Treat them as yellow-by-default and use the closest buffer week to catch up.

  • Zoho quarterly-review months (Jul, Oct, Jan, Apr). Zoho crunch bleeds into the personal week. Assume yellow.

The Anti-Patterns To Avoid

  • “I’ll do 4 hours tonight to make up for yesterday.” No. Two 90-minute blocks separated by sleep beat one 4-hour block every time, and the 4-hour block costs you the next morning at Zoho.

  • “I’ll skip Wednesday’s rest this week because I feel behind.” No. This is the exact move that leads to red week #2, which leads to red week #3, which leads to the reset protocol.

  • “I’ll watch a tutorial during Saturday morning.” No. Saturday morning is code, not consumption. Save the video for Sunday evening if you must watch it.

  • “I’ll do the retro on Monday.” No. Sunday evening. The whole point of the retro is that Monday-morning-you reads it and starts the next sprint in the right frame. Monday cannot read what was never written.

The Weekly Ritual Checklist

Sunday evening, 30 minutes, in the lab notebook:

### Week ending YYYY-MM-DD

- Sprint: S__ (day _ of 14)
- Hours logged this week: __ (green / yellow / red)
- Shipped this week: ___
- Did not ship / carried over: ___
- One thing learned (predict/measure entry ok): ___
- One thing that surprised me: ___
- Next week's first move (Monday evening, exact task): ___
- Body check: sleep avg __ hrs · exercise __ times · one deep dinner this week? y/n
- Mood check (1–10, honest): __

Six minutes to fill out. Bought at the cost of one YouTube video. Compounds for 52 weeks.

Return to 00_command README · Previous: 03_north_star_artifacts.md · Next: 05_kpi_dashboard.md