See how Alex worksWork with Alex
All practices

Practice — Planning

Planning Cycles: Commitments, Cooldowns, and Continuous Planning

Compare 37signals’ fixed build cycles and cooldowns, GitLab’s nested planning horizons, and Linear’s continuous preparation of candidate projects. The cases show different ways to select work and revisit commitments; they do not establish one mandatory cadence or a measured reduction in coordination costs.

By Alex Karasyov — Operating consultant for product & engineering teams

Last reviewed November 1, 2026

What It Is

Planning cadence defines when work is selected, reviewed, and reconsidered. The cases use different mechanisms: 37signals fixes build periods and cooldowns; GitLab connects several planning horizons; Linear develops candidate projects continuously before quarterly prioritization. (37signals, GitLab, Linear)

[Inference — comparison guidance.] Inspect the commitment, scope, review point, and dependency handoff separately. A shared company-wide build cycle is one design choice, not a defining requirement for every planning system.

Why It Works

37signals separates selection from execution. Its handbook describes six-week cycles across teams and two-week cooldowns for bugs, write-ups, and deciding what comes next. Shape Up uses appetite to constrain scope before a bet. (Handbook, Shape Up)

Linear prepares choices continuously. Its October 2025 account describes developing candidate projects as ideas arrive, then selecting among them against customer demand, revenue impact, and quarterly goals. Continuous preparation is not evidence that the company avoids prioritization. (Source)

GitLab connects different horizons. Its cadence runs from weeks to thirty years, with adjacent horizons roughly three to five times apart. These periods describe the work’s horizon, not necessarily how often its plan is updated. (Source)

[Inference — application guidance.] Explicit selection and review points may make commitments easier to discuss. Inspect priority changes, unfinished work, and dependency delays locally; the sources do not measure a universal reduction in interruptions or establish that every team needs a cooldown.

Where It Fails

[Inference — implementation cautions, not measured failure rates.]

  • A calendar without a selection decision. Inspect what was declined or deferred and who had authority to choose.
  • Dependencies without a handoff. Teams can use different rhythms if commitments and review points are explicit. A common cadence alone does not settle dependencies.
  • Unplanned work without a tradeoff. Record what changes when urgent work enters a commitment period.
  • Service work forced into a build-cycle template. Distinguish immediate response obligations from planned improvement work. This is application guidance, not a claim that 37signals exempts its operational teams: its handbook says all teams share the six-week cadence. (Source)

Best Examples

37signals / Basecamp — Six-week cycles across teams and two-week cooldowns. Shape Up separates shaping, betting, and building. The handbook describes six annual opportunities to make major work-selection decisions; this is not a maximum of six projects or bets per team. (Handbook, Shape Up)

GitLab — A multi-horizon cadence from weekly work to thirty-year mission, with quarterly OKRs and longer planning horizons. This is a nested set of horizons, not one shared build cycle for every function. (Source)

Todoist (formerly Doist) — Its September 2022 accountability article describes 1–5-person DO squads and objective cycles lasting one to six months, plus monthly reflection and end-project async retrospectives. The current onboarding guide still references DOs and cycle planning; the precise present cadence is not established by the publicly readable pages. (Accountability, onboarding)

Linear — Its October 2025 planning account describes continuous development of candidate projects, prioritized against customer demand, revenue impact and quarterly goals. Configurable cycles and optional cooldowns in the product do not establish a mandatory internal cycle for every Linear team. (Company planning, product settings)

Buffer — Its August 2026 Build Week is a dated example of a company-wide learning/building event, not evidence of a permanent cadence. (Source)

Implementation Guide

[Inference — experiments drawn from the cases, not a universal implementation recipe.]

  1. Name the commitment. Specify which work is selected, who can change it, and how changes are recorded.
  2. Choose a review point. Test a fixed build period or continuous preparation against the actual work. A cooldown is one option for maintenance and replanning, not a mandatory pause for every function.
  3. Prepare choices before committing. Compare appetite-based shaping with continuously developed candidate projects. (Shape Up, Linear)
  4. Define dependency handoffs. Align review points where useful; different teams need not share every cycle boundary.
  5. Publish the plan and outcome. 37signals’ Kickoffs and Heartbeats are examples of written cycle records. Decide who maintains the corresponding records in your own system. (Source)
  6. Evaluate the change. Review missed commitments, priority changes, maintenance work, and dependency delays before extending the experiment.

Common Mistakes

[Inference — comparison cautions.]

  • Copying duration without selection or review. Scrum Sprints and Shape Up cycles include different commitments and mechanisms. A renamed calendar does not establish equivalence. (Scrum Guide, Shape Up)
  • Treating maintenance as incompatible with planning. Immediate incident response and planned maintenance have different needs; 37signals explicitly uses cooldown for bugs. (Handbook)
  • Equating continuous planning with indecision. Linear’s account describes explicit prioritization of candidate projects. (Source)
  • Treating a company example as a measured optimum. None of these cases establishes one best cycle length or a required organization-wide rhythm.

Sources

  1. 37signals Employee Handbook: How We Work: https://basecamp.com/handbook/how-we-work
  2. Shape Up (37signals): https://basecamp.com/shapeup
  3. GitLab Cadence: https://handbook.gitlab.com/handbook/company/cadence/
  4. How Doist Works Remote: https://doist.com/how-we-work/how-doist-works-remote

Todoist accountability (September 2022): https://async.twist.com/accountability-remote-workers/

Todoist onboarding: https://handbook.todoist.net/s/6ca6f66e-2d02-4e05-b629-b1c772f5ff23

Linear internal planning (October 2025): https://linear.app/now/continuous-planning-in-linear

Linear cycle configuration: https://linear.app/docs/use-cycles

Buffer Build Week (August 2026): https://buffer.com/resources/build-week-2026/

Scrum Guide 2020: https://scrumguides.org/scrum-guide.html

Inferences

  • Explicit selection, ownership, and review points may help a team discuss tradeoffs; inspect their effect in actual work.
  • Fixed cycles, nested horizons, and continuous preparation solve different parts of planning. The cases support comparing those mechanisms, not ranking every planning model or attributing outcomes to a calendar alone.

Work with Alex

If your roadmap feels like a graveyard of “in progress” work that never ships, and your team operates on three different planning cadences that never align, Alex helps leadership teams design planning systems that actually produce shipped decisions.

planningexecutionpracticeasync

Last reviewed November 1, 2026