Systeric / Docs
Open App →

Blocks & Sprints

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.


The block is the commitment cycle#

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.

GoalTeamResult
Ship saved-address checkoutProduct
Coordination milestone: address API ready for GrowthPlatform
One-tap add-on at checkoutGrowth
Compress & lazy-load product imagesPlatform

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?


Systeric’s block-and-sprint cadence is adapted from Shishir Mehrotra’s account of how YouTube scaled: see “Rituals for Hypergrowth: An Inside Look at How YouTube Scaled.”


Related: Cadence, Half Strategy, The Framework, Bets