Cadence

Systeric runs on a stack of rhythms, not one calendar. It has two layers. The planning cadence sets direction on a 6-month / 4-week schedule: aspirations every six months, commitments every four weeks. The operating cadence runs underneath it, from daily to monthly, and keeps the committed plan honest between planning moments. None of them replace each other: the daily standup catches what the weekly call is too slow for, and the four-week block catches what the six-month plan is too slow for.

This page is the navigator. The planning cadence is below, then the operating cadence, then the full table of beats (and the doc that owns each one’s mechanics).

The planning cadence#

We plan on a 6-month / 4-week schedule: the former for aspirations, the latter for commitments. We deliberately don’t plan on 13-week quarters: in a fast-moving environment a quarter is too long to truly commit to and too short to achieve something strategic. (Adapted from Shishir Mehrotra’s “Rituals for Hypergrowth”.)

• Every 6 months: Strategic planning (H1 / H2). Two-pager intake from every team, then a prioritization pass, produces ~6 Big Rocks and a resource allocation for the half. This is where aspirations are set. See Half Strategy.
• Every quarter: Strategic checkpoint. A lighter mid-half re-forecast: are the Big Rocks still right, has the diagnosis changed? Reallocate, kill, or add a rock: no full re-plan. So a 6-month horizon never goes a whole half without a strategic look. See Half Strategy.
• Every 4 weeks: Block planning (~3 per quarter, ~6 per half). Each team commits to 4–5 concrete goals for the block: true 100% commitments, not aspirations, so one team can depend on another’s. Inside each block runs a 2-week working rhythm for demos and observable progress. See the block cycle below.
• Every week and below: the operating cadence. The daily standup, the weekly product call and business review, and the monthly testing party keep the committed blocks honest between planning moments. They are the next section.

The block is the commitment cycle#

Half Strategy sets the next 6 months. It doesn’t tell a team what to do this week. Between the two sits the block: the unit that turns a 6-month plan into something a team commits to, delivers against, and is held to.

A block is 4 weeks, two 2-week sprints. Three blocks fit a quarter, and six fit a 6-month planning cycle: the block is how the strategic plan’s Big Rocks get worked down into cycles short enough to commit to and long enough to actually finish something real within. A quarter doesn’t divide evenly into three 4-week blocks, so the third block in each quarter absorbs the remainder and runs a bit longer than the first two.

Four weeks is not the number Shishir Mehrotra’s YouTube account uses (his was six, tied to app-store release cadence); Systeric adapted the shape, not the exact length. Systeric’s reason is its own: four weeks is long enough that a team can commit to a real outcome, including one with dependencies on another team, and short enough that the commitment stays honest, nobody’s stretching a guess out over a quarter and calling it a plan.

Block planning is deliberately lightweight, a day or two, not a planning week. Each team walks in with problems already sourced (from Half Strategy and the Big Rocks it produced) and leaves with a short, committed goal list.

Goals are commitments, not aspirations#

Each team commits to 4–5 concrete, measurable goals for the block. Not ten, not a backlog: four or five, because that’s what a team can actually hold itself to.

The critical property: these are true 100% commitments, not 70% aspirations. That’s a deliberate departure from how OKRs are usually run, where a goal set at 70% confidence is fine, even expected. A 70%-aspiration goal can’t be relied on by anyone outside the team that owns it: if there’s a real chance it doesn’t land, no other team can safely build on top of it. A block commitment is the opposite: when Team A commits to a block goal, Team B can plan its own next block on the assumption that it happens. That’s what makes a commitment a contract another team can depend on, and it’s the entire reason the block exists as a distinct ritual from quarterly bets.

Commitments are set at the team level, batched, not sized as individual person-sprints the way a bet is sized in sand/pebble/rock terms during planning. A block goal is a team’s word that a thing will be true by the end of the block; how the team’s capacity gets divided to get there is the team’s own business.

Goals are often intermediate milestones, not finished features: four weeks is short relative to a 6-month bet, so a goal frequently reads as a step, not the destination. A common shape is the coordination milestone: “Team A gets X ready this block so Team B can build Y next block.” Naming these explicitly is what keeps a dependency from turning into a surprise three weeks in.

Dependency coordination#

Once every team has published its block goals, teams meet to reconcile the dependencies between them, a scrum-of-scrums. This is where “Team B is depending on Team A’s coordination milestone” gets checked against “Team A actually committed to that milestone this block,” and where conflicts between two teams both expecting a third team’s output get caught before either commits to their own plan around it.

The 2-week rhythm inside the block#

Four weeks is short enough that a team could plausibly hold the whole commitment in their head without a checkpoint, but that’s not why the two-week rhythm exists. It’s not there to subdivide an otherwise-too-long gap; it’s the same externally-observable-progress standard the rest of the cadence runs on, applied inside the block instead of just around it. Inside every block, work runs in two 2-week sprints, each ending in a demo of externally observable working software, the same standard Half Strategy sets for milestones generally. That demo lands at the block’s midpoint, the one point where a team is far enough in to have something real to show and still has runway left to redirect before the commitment is due. If two weeks pass with nothing a PM or lead can look at and react to, that’s the signal to check in, not wait for the block to close.

The block plan: the output#

Block planning produces one artifact: a block plan, written at the start, that turns a slice of each Big Rock into concrete commitments. It names (for every goal) the rock it advances, the team that owns it, what “done” means, and any cross-team dependency. It’s short on purpose; the point is that one team can read another’s plan and know exactly what to expect, and when.

# Block 3 · Storefront · weeks 9–13

Advances the H2 rocks: Saved address & payment · Faster product pages

| Goal (this block)                    | Rock          | Team     | Done =                          | Depends on         |
|--------------------------------------|---------------|----------|---------------------------------|--------------------|
| Ship saved-address checkout          | Saved address | Product  | Live to 100%, completion tracked| Address API (wk14) |
| Address API ready for Growth         | Saved address | Platform | Endpoint live + docs, wk14      | None                  |
| Compress & lazy-load product images  | Faster pages  | Platform | Median load < 2.0s in prod      | None                  |

Not this block: one-tap add-on (killed at checkpoint), loyalty (not doing H2).

Each goal is a 100% commitment for the block, not a stretch. If it can’t be finished with confidence, it’s scoped down until it can, so the dependencies above are promises another team can build on.

Tracking the block#

The same plan becomes the tracker: as the block runs, fill the Result column and keep it live. Nothing else moves.

A ✗ at block close isn’t hidden in a retro: it’s the input to the next block’s planning: was the narrative wrong, did a dependency slip, or was the scope simply too big for the block?

The operating cadence#

Underneath the plan, the operating cadence runs from daily to monthly. It does not set direction; it keeps the committed blocks honest and surfaces problems while fixing them still changes the outcome.

• Daily: the standup. Everyone writes their update first (done, doing, obstacles), then the team spends fifteen minutes together, five reading and ten solving. It is the fastest beat, and it exists to clear a blocker the same day instead of letting it wait for the weekly call. See The Daily Standup.
• Weekly: product review and business metrics. Two beats sit here. The Weekly Product Call makes decisions on the roadmap: on track, blockers, ad hocs. The Weekly Business Review reads the metrics: north star and inputs week on week, and digs into variances.
• Monthly: the testing party. All hands use the product together, each person taking a different role, to find what is broken or confusing before real users hit it. The output is a list of feedback, not a status update. It is the beat that keeps the team’s judgment grounded in the actual experience of the thing they ship.

The rhythms#

Every recurring beat in one place. Each row links to the doc that owns the detail.

A proven shape#

None of this is bespoke. It mirrors the operating cadence Claire Hughes Johnson describes running at Stripe and Google in Scaling People, a stack of nested rhythms from the year down to the day. We run the same shape, with our own names:

The point of adopting a known-good shape is that it’s already been stress-tested at scale: we spend our judgment on running the beats well, not on inventing the calendar.

Related: The Framework, Half Strategy, Weekly Report, Expectations, Leading People