How the Quarterly Cycle Runs at Scale
The OKR Process: How the Quarterly Cycle Runs at Scale
Most leadership teams can describe the OKR process on a slide. Far fewer can say what happens in week seven, who is allowed to change a key result mid-quarter, or what the organization does with a set of scores once they exist. The gap between the slide and the calendar is where execution systems quietly stop working, and it widens with every team you add.
This is the cycle itself. Not how to introduce OKRs for the first time, which is a separate piece of work with its own rollout plan, but what the organization repeats every quarter once they are live.
What is the OKR process?
The OKR process is the recurring cycle an organization runs to set objectives, work against them, review what happened and start again. It runs a quarter in most organizations, and it is a standing operating rhythm rather than a project with an end date.
IBM puts the shape of it plainly: “The OKR cycle typically operates on a quarterly cadence“, with annual objectives guiding what each quarter commits to. The confusion worth clearing up early is between the process and the rollout. A rollout happens once, takes nine to twelve months at enterprise scale, and ends when internal capability exists. The process starts on day one of the first cycle and never ends. Organizations that treat the second as a continuation of the first usually keep the rollout governance in place long after it has stopped being useful, and the cycle becomes something the programme office runs rather than something the business does.
What are the stages of the OKR cycle?
Four stages: plan before the quarter opens, commit at the start, run a weekly cadence through the middle, and close with a review and a retrospective. Each stage has an owner and produces one artefact, and a stage without an artefact is the one that gets skipped when the quarter gets busy.
| Stage | When | What happens | Who owns it | What it produces |
|---|---|---|---|---|
| Plan | 2 to 3 weeks before the quarter | Company objectives confirmed, teams draft their own, dependencies negotiated | Leadership team, then team leads | A drafted set per team, with owners named |
| Commit | Week 1 | Sets are finalised, baselines recorded, the calendar is booked | Team leads | Locked key results with a starting number |
| Run | Weeks 2 to 11 | Weekly team check-ins, monthly division review, mid-quarter reset | Key result owners | A decision each week that changes the next one |
| Schließen | Weeks 12 to 13 | Scoring, then a retrospective on how the cycle ran | Team leads, process owner | Scores, plus two or three changes to the next cycle |
The baseline in stage two is the part organizations discover they skipped three months later. A key result without a recorded starting number cannot be scored honestly at the end, and the argument about what the number was in January is not one anyone wins.
When should OKR planning start?
Before the quarter opens, not in its first week. Two to three weeks ahead is realistic for a single team and closer to four once several layers have to agree.
The sequence matters more than the lead time. Google’s guidance is that “it can be helpful to commit first to organizational objectives, so that teams and individuals can set their own objectives”, and IBM describes the same dependency from the other side: “Organizations often use annual objectives to guide quarterly OKR development.” When company objectives land late, every team below improvises, and you spend weeks three and four rewriting sets that were drafted against a guess. Teams remember that. The second time it happens, they wait.
How do OKRs align across teams without cascading everything top down?
Leadership sets the company objectives, teams write their own key results against them, and the dependencies between teams get negotiated directly rather than routed upwards. Alignment is a horizontal conversation that a vertical cascade cannot produce.
Google’s framing is that “successful OKRs can often come from a mix of top-down and bottom-up suggestions“, and Atlassian describes the mechanism as teams taking “high-level objectives and refining them for each specific area”. Neither describes a translation exercise where each level restates the level above in smaller words.
The horizontal pass is the one that gets cut when planning runs late. It is also the only stage where a team discovers that the key result it just committed to depends on a platform team that has committed to something else. Finding that out in week six costs a quarter. Finding it out in planning costs an afternoon.
What is the OKR operating cadence inside the quarter?
Weekly at team level, monthly at division level, with one mid-quarter review that reaches every layer. The frequency is not about reporting volume. It is about how quickly a stalled key result gets noticed by someone who can do something about it.
IBM sets the pattern out directly: “Monthly reviews at the department or division level maintain alignment across teams, while weekly or biweekly team check-ins drive consistent execution.” Google adds the middle marker, noting that “it can be helpful to have a mid-quarter check-in for all levels of OKRs”.
At enterprise scale the mid-quarter point is the only sanctioned moment to change a key result. Without it, teams either quietly abandon the ones that no longer make sense, which corrupts the scores, or grind on with a target everyone knows is dead, which corrupts something worse.
What happens at the OKR quarterly review?
Each key result gets scored, and then the set gets read as a whole. The second half is the part that produces value, and it is the part that gets dropped when the review is scheduled for forty-five minutes.
What Matters is explicit that “grading OKRs happens at the end of every cycle and is an opportunity and non-biased way to reflect on a team’s overall performance”. On what a good score looks like, Google’s position is that “the sweet spot for an OKR grade is 60% to 70%“, and Atlassian is blunter: “scoring 0.7 on a key result is considered a success”. Committed work is graded differently, and IBM notes that teams “are expected to achieve 100% of their committed OKRs“. Mixing the two scales in one review is how a leadership team ends up congratulating a team that delivered nothing ambitious and questioning one that moved a hard number by half.
How is an OKR retrospective different from the quarterly review?
The review judges the results. The retrospective judges the process that produced them, and it is the only stage where the cycle itself gets to change.
What Matters makes the pairing explicit: “on their own, grades don’t mean all that much. That’s why we always pair grading with self-assessment and reflection.” Run it per team, then run one short cross-team session on the mechanics: did planning start late, did the mid-quarter reset happen, how many key results were still owner-updated in week ten. Two or three changes are enough. A retrospective that produces a list of eleven improvements produces none.
How does the OKR process change across 20 teams instead of one?
The four stages stay identical. What changes is that the calendar has to be shared, the dependencies have to be mapped, and somebody has to stop the company view from becoming unreadable.
Staggered quarters are the first thing to fix. Teams on different cycle dates cannot negotiate a dependency, because one of them is closing while the other is planning, and a shared operating rhythm is the entire point. The second is volume. Google’s recommendation of “three to five objectives with about three key results for each objective” is sensible per team and arithmetic at scale: twenty teams at the top of that range is three hundred key results. No executive reads three hundred of anything. The company view has to be the company set plus exceptions, and everything else stays at the level that owns it.
Who owns the OKR process at enterprise scale?
One named person owns the calendar and the standard. Team leads own the content, permanently, and that line is what separates an execution system from an internal reporting function.
The process owner decides when planning opens, what a key result has to contain to be accepted, and when the review happens. They do not write objectives, chase updates on behalf of owners, or maintain the numbers. The moment they do, the organization has a programme office producing a quarterly document, and the teams have gone back to working the way they always did. This is the difference between training that produces certificates and OKR-Implementierung that produces behaviour change.
Where does the OKR process break in the second cycle?
Cycle one runs on novelty and attention. Cycle two runs on whether anything in cycle one visibly changed as a result, and most organizations cannot point to anything when asked.
The pattern our coaches see most is a first cycle that was never closed properly. Scores were assigned, nobody read them as a set, no retrospective happened, and the second planning session opened with the same objectives and the same problems. The cycle is not a loop unless something at the end of it changes the start of the next one.
Frequently asked questions
How long is a typical OKR cycle? A quarter for most organizations, with annual objectives sitting above it. Longer cycles reduce the number of correction points to a level where the process stops functioning as a feedback loop.
When should we set next quarter’s OKRs? Two to three weeks before the quarter opens, after company objectives are confirmed. Teams that draft against unconfirmed company objectives usually rewrite their sets in week three.
Can OKRs be changed mid-quarter? Yes, at the mid-quarter review, with the change recorded. Uncontrolled edits make scoring meaningless, and a target everyone privately knows is dead damages the process faster than a missed one.
How many key results should a team have? Three to five objectives with about three key results each is the common recommendation. At scale the constraint is not the team’s limit, it is whether the company view stays readable.
Is the OKR process the same as an OKR rollout? No. A rollout is the one-time work of introducing OKRs and building internal capability. The process is the quarterly cycle that keeps running afterwards.
Who runs the OKR process day to day? Team leads run their own cycle. A single process owner holds the calendar, the standard and the review dates, and stays out of the content.
If your cycle produces scores but nothing in the next quarter looks different because of them, the loop is open, and closing it is usually a one-quarter fix. Our coaches work through exactly that in the 90-Day Execution Sprint.
About the author
Dirk Schmellenkamp is Founder and CEO of the OKR Institute, which has certified more than 70,000 practitioners and run OKR implementation programmes for over 1,000 organizations across 50+ countries since 2017. The OKR Institute is accredited by the International Coaching Federation, the Association for Coaching and HRD Corp.
CEO des OKR Instituts
Ähnliche Kurse
kürzliche Posts
Stichworte
#OKR
#OKR AI agents
#trends 2026