OKR Cadence: Setting the Quarterly Planning Cycle

OKR cadence: set the quarterly planning cycle under annual OKRs and schedule drafting, alignment, check-ins and grading so every level starts on time.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

OKR cadence is the calendar that makes the method run: how long each cycle lasts, when each level drafts and publishes, how often progress is checked, and when grading and reflection happen. The OKR method is built around a quarterly planning cycle nested inside annual goals, and this skill is about setting that rhythm deliberately rather than letting it drift.

The quarterly default has a history. What Matters notes that one of the key differences between Grove's OKRs and the Management by Objectives system they grew from is that OKRs are quarterly, not annual (What Matters: What is an OKR?). Google keeps both layers: its re:Work guide says Google sets annual and quarterly OKRs and holds company-wide meetings quarterly to share and grade them (re:Work).

The cycle is more than a start and end date. John Doerr's typical OKR cycle lays out a sequence: senior leaders brainstorm company OKRs 4 to 6 weeks before the quarter, finalize and communicate them 2 weeks before, teams share their OKRs at the start of the quarter, contributors share theirs 1 week after, everyone checks in through the quarter, and scoring and reflection happen near its end. The sequence is what stops lower levels from starting late.

Some choices are genuinely open. Marty Cagan notes that team objectives are normally created or updated every quarter, which gives teams enough time for real progress while letting the business adjust, and that mid-quarter changes should be the exception (SVPG, Team Objectives: Summary). Practitioners disagree on how strict that exception should be, which this page covers below.

The output of this skill is a one-page OKR calendar for the year: annual OKR dates, the quarterly sequence for each level, check-in rhythm, grading and reflection dates, and the rule for changing OKRs mid-cycle.

How It Works

Start with cycle length. The quarter is the common default because it is long enough to move an outcome and short enough to correct course several times a year. What Matters describes the grading period as typically a quarter (What Matters). A shorter cycle can suit a very early company whose priorities change monthly, at the cost of more planning overhead. A longer one suits objectives that genuinely take a year, which is what the annual layer is for.

Nest the layers. Annual OKRs, or a few annual objectives, state what the company wants by year end. Quarterly OKRs state what will move toward them this quarter. An objective can be long-lived and roll over for a year or longer while its key results evolve, as What Matters notes, so the quarterly layer is often new key results under a stable objective.

Build the sequence backwards from the quarter start. Using Doerr's typical cycle as the template, company OKRs must be final about two weeks before the quarter so teams can draft, align and publish in time. Each extra level adds time, so organizations with more layers either start earlier or let levels draft in parallel against the company OKRs.

Set the in-cycle rhythm. re:Work recommends a mid-quarter check-in for all levels before final grading, and an end-of-quarter check-in to prepare for it (re:Work). What Matters recommends lighter conversation-based check-ins at least weekly (Weekly OKR check-ins). The weekly rhythm catches drift; the mid-quarter review is where re-planning happens.

Decide the rule for mid-cycle changes before you need it. Christina Wodtke's advice is not to change OKRs halfway through the quarter, even if you realize they were set badly, and to learn from the result (Wodtke, The Art of the OKR, Redux). What Matters, by contrast, says it is completely reasonable to do away with an OKR mid-cycle if it is not producing value (Common OKR Mistakes), and re:Work describes revisiting OKRs to abandon objectives that clearly will not happen. A workable rule is to allow changes only at the mid-cycle review, with a written reason.

Close each cycle with grading and reflection before the next planning starts, so the lessons feed the new OKRs instead of arriving after them.

Step-by-Step Guide

Step 1: Choose the cycle length

Default to quarters unless there is a clear reason to differ. If the business changes direction more often than quarterly, consider a shorter cycle for a period. Write down the choice and the reason so it can be revisited after a few cycles. Align the cycle to the fiscal calendar if the finance team plans that way.

Step 2: Define the annual layer

Set a small number of annual objectives, or annual OKRs, at the start of the year. Plan to review them each quarter, since some key results will need to change. Keep the annual set short enough that quarterly OKRs can clearly trace back to it.

Step 3: Map the levels and build the sequence

List every level that will set OKRs, such as company, department and team. Work backwards from the quarter start using Doerr's typical cycle: company brainstorming weeks ahead, company OKRs final about two weeks before, team OKRs at the start, individual OKRs if any shortly after. Remove levels that add delay without adding clarity.

Step 4: Schedule alignment and publication

Put the cross-team alignment review and the publication date on the calendar for every cycle. Make publication a fixed date that does not move when drafts run late. Late teams publish what they have and refine in the first check-in.

Step 5: Set the check-in rhythm

Choose a weekly or biweekly check-in for teams and a mid-cycle review for all levels, as re:Work recommends. Put both in recurring calendars before the cycle starts. Decide who attends each and what gets updated beforehand.

Step 6: Set the change rule

Write down when OKRs may change mid-cycle and who approves it. A common rule is changes only at the mid-cycle review, with the reason recorded and the original kept for the reflection. Share the rule when OKRs are published so nobody is surprised.

Step 7: Schedule grading and reflection

Book grading in the last week of the cycle and reflection straight after it, before the next planning session. Put the results where the next planning session's pre-read will pick them up. Review the calendar itself at the end of each year.

Best Practices

• Publish the whole year's OKR calendar at once. Fixed dates known months ahead are easier to protect than dates set each quarter.
• Keep planning short relative to the cycle. If drafting and alignment take a large share of the quarter, the process has more layers or steps than it needs.
• Let lower levels draft in parallel. Waiting for each level above to finish is the main cause of late team OKRs; drafting against the company OKRs directly avoids it.
• Hold the company-wide grading moment. re:Work describes Google meeting quarterly to review grades and set new OKRs (re:Work); a shared moment keeps grading from being skipped.
• Expect the first cycles to be rough. Doerr told Betterworks it usually takes a company 1-2 quarters to figure out its cadence and model.
• Carry aspirational OKRs forward on purpose. Decide at each planning session which unfinished aspirational OKRs continue, instead of letting them silently vanish.

Common Mistakes

• Annual-only OKRs: Goals set once a year are forgotten by spring and cannot adapt. Keep the annual layer for direction and set key results quarterly.
• Sequential cascades that start late: Team OKRs arrive weeks into the quarter. Build the sequence backwards and let levels draft in parallel.
• No mid-cycle review: Teams discover at grading that a key result was off track for weeks. Schedule the review before the cycle starts.
• Changing OKRs whenever priorities shift: Frequent changes remove the focus OKRs are meant to create. Allow changes only at agreed points, with a reason.
• Planning the next cycle before grading this one: The lessons arrive too late to use. Grade and reflect first, then plan.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Objectives and Key Results (OKRs)

Related Skills

• How to Run an OKR Planning Session
• OKR Check-In Meetings and Progress Reviews
• OKR Scoring System: How to Score and Grade OKRs
• OKR Alignment Across Teams and Levels
• How to Write OKR Objectives That Focus a Team
• How to Write Key Results That Are Measurable
• OKR Mistakes to Avoid: Common OKR Anti-Patterns

Sources

• What Matters: A Typical OKR Cycle
• What Matters: What is an OKR?
• Google re:Work: Set goals with OKRs
• What Matters: Weekly OKR check-ins
• What Matters: Common OKR Mistakes
• Christina Wodtke: The Art of the OKR, Redux
• SVPG: Team Objectives, Summary
• Betterworks: Q&A with John Doerr

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.