Monthly cadence as a discipline lever

For a side project running alongside a startup, cadence isn't a scheduling choice. It's a survival mechanism. Weekly and quarterly both fail in predictable ways. Monthly is the only rhythm that absorbs the main work's variance without either eating it or quietly dying.

Stating the claim

For a side project, monthly is the only cadence that survives the main work's variance. Anything tighter and the side project starts demanding attention the main work can't spare. Anything looser and the side project has no forcing function and dies in week six. Monthly is the floor on too-tight and the ceiling on too-loose; that's the only reason it works.

The claim isn't that monthly is ideal. An ideal cadence would match the project's actual rhythm. The claim is that for the specific case of a research arm running parallel to a startup, monthly is the cadence that doesn't fail in a predictable way.

Why not weekly

Weekly turns into an overhead spiral. Every week becomes a small launch: a writeup, a publish step, a "what did I learn" pass, a check against last week's progress. Each of those is cheap on its own. Stacked weekly, they outweigh the actual work within a month.

The deeper problem is psychological. Weekly cadence means every week is either a success or a failure, and most weeks in a side project are neither (they're partial). A side project that grades itself weekly will quit because most weeks look like falling behind. Weekly is a manager's cadence. A research arm doesn't have a manager. Trying to be your own weekly manager is how you end up resenting the arm.

Why not quarterly

Quarterly has the opposite failure mode. The pressure release is too long; nothing's due, and the main work fills the space.

Week 6 of a 13-week quarter is when a side project quietly dies. The kickoff energy has decayed, the deliverable is too far away to feel real, and the main work has had six weeks to flood the calendar. Quarterly cadence requires a forcing function the arm doesn't have. Without external accountability, "I'll get back to it next month" becomes "I never got back to it."

Quarterly also makes the wrong unit feel normal. A quarter is the length of a project, where a cadence point should be the length of a check-in. By the time three months have passed, the right move is usually to redirect what the project is doing, which is a much bigger commitment than the arm was supposed to hold.

Monthly, mechanically

One notebook target per month. That's the only commitment. If the notebook ships, the month was a success. If not, the same notebook carries into next month and nothing else changes.

The check-in is on the first of each month, copied from 12-Parley/roadmap.md:

On the first of each month:

- Was last month's notebook shipped? If not, it's still the current notebook.

- Did anything from QC [URGENT] pull cycles? If yes, that's fine — note it in decisions.md.

- Any new research questions surfaced that should go on the roadmap?

- Update notebooks-published.md if anything shipped.

Four items. Twenty minutes over coffee. No meeting, no report, no metric to roll up. The check-in is the entire ceremony around the arm.

The second checkbox is the one that does the most work. It's an explicit permission to let the main work win — without guilt, without a recovery plan, just a note in the decision log. That permission is what keeps the arm from feeling like a debt. A month where QC ate the cycles is a normal month, not a failed one.

When a month gets skipped

One miss is fine. Two is the first signal.

The carry-forward protocol is the same as the regular check-in: the unshipped notebook stays the current notebook, the reason gets logged in decisions.md, and the month rolls forward without renegotiation. No make-up plan, no doubling down next month. The arm doesn't try to recover from a slip because the slip is part of the design — the arm exists to absorb that variance, not to fight it.

Two consecutive misses is the first kill-criteria signal. Not an automatic kill (that's covered in Lesson 8), but an automatic review. The question to ask: has the arm stopped working, or is the main work in a phase that legitimately precludes side work? If the answer is the former, the arm gets paused or killed. If the latter, the arm gets paused until the phase clears, with a written restart date.

The reason two misses is the signal (and not three or six) is that two months is the longest a side project can be inactive before the muscle memory degrades. Past that point, restarting feels like starting, and most side projects don't survive a restart.

Apply this

Pick the first of next month as your check-in date. Put it in your calendar as a recurring 20-minute event. Write the check-in checklist into the project's roadmap or README, with whatever variant fits your arm — the four Parley questions are a template, not a spec.

Commit the checklist. Show up on the first. Run the four questions, write any notes into the decision log, and close the loop. Do it once. The hardest part of monthly cadence is the second month, when nothing has shipped and the temptation is to skip the check-in entirely. The whole point is that you don't.