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.
| Goal | Team | Result |
|---|---|---|
| Ship saved-address checkout | Product | ✓ |
| Coordination milestone: address API ready for Growth | Platform | ✓ |
| One-tap add-on at checkout | Growth | ✗ |
| Compress & lazy-load product images | Platform | ✓ |
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