Milestone map
Milestone map
3 milestones
Design the OKR Structure and Cadence
3 weeks
Produce a written OKR system design for your organisation covering: the OKR hierarchy (company, department, team levels), cadence (quarterly, semi-annual, annual), the process for setting and reviewing OKRs at each level, ownership accountability, and how OKRs connect to performance reviews (or explicitly how they are kept separate). Interview at least two team leads or department heads to understand current goal-setting pain points and incorporate the findings.
Proof required
Submit the OKR system design document (min 800 words) plus interview notes from at least two team leads or department heads, showing specific pain points identified and how the design addresses them.
What gets checked
- Design covers all three OKR hierarchy levels with distinct guidance for each
- Pain points from at least two interviews are specifically named and addressed in the design
- OKR-to-performance-review boundary is explicitly stated — ambiguity here destroys OKR quality
Common mistakes
- Design is generic OKR theory — not adapted to the organisation's actual structure
- Pain point interviews are skipped — design misses the real dysfunctions
- Performance review boundary is left ambiguous — teams interpret OKRs as performance targets
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask the submitter to explain how the OKR hierarchy cascades — what happens when a company OKR is missed at the department level?
- Verify the performance review boundary is explicit — can they quote the exact statement from the design?
- Confirm at least two interviews were conducted and their outputs are visible in the design
Run the First Full OKR Cycle
12 weeks
Facilitate the first full OKR cycle end-to-end: run the kickoff session for company-level OKRs, facilitate department-level alignment, support at least three team-level OKR sessions, run mid-cycle check-ins, and facilitate the cycle retrospective. Document the facilitation approach for each stage and the outcomes. Collect written feedback from at least three participants (team leads or department heads) on the process quality.
Proof required
Submit cycle documentation (kickoff agenda + notes, department alignment notes, at least three team-level session notes, mid-cycle check-in records, retrospective), plus written feedback from at least three participants rating the process and identifying improvements.
What gets checked
- All five cycle stages are documented — kickoff, department alignment, team sessions, mid-cycle, retrospective
- Written feedback from three named participants is included and substantive
- Retrospective identifies at least two specific process improvements for the next cycle
Common mistakes
- Kickoff happens but mid-cycle check-ins are skipped — OKRs become set-and-forget
- Team-level sessions are not facilitated — teams are left to write OKRs without support
- Retrospective only reviews OKR attainment, not the process quality
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm all five cycle stages have documentation — not just the kickoff
- Ask the submitter what the biggest surprise was in mid-cycle check-ins
- Verify the three participant reviewers are named team leads or department heads, not peers or reports
Iterate the System After Cycle Two
12 weeks
Run a second OKR cycle incorporating the improvements identified in cycle one. After cycle two, conduct a structured evaluation comparing cycle one and cycle two on: OKR quality (are they more ambitious? more measurable?), process adherence (did more teams complete check-ins?), and perceived usefulness (team lead survey). Produce a written evaluation report (min 500 words) and a recommended system update document.
Proof required
Submit the cycle two retrospective, the structured evaluation comparing cycles one and two (min 500 words covering all three dimensions), and the recommended system update document. A senior leader (CEO, COO, or equivalent) must review and sign off on the system update recommendations.
What gets checked
- Evaluation compares both cycles on all three named dimensions with data
- System update recommendations are specific and actionable — not 'communicate better'
- Senior leader sign-off is documented — they reviewed and approved the updates
Common mistakes
- Second cycle runs without any changes from cycle one — evaluation produces no learning
- Evaluation is qualitative only — no data on process adherence or perceived usefulness
- System update is written but not reviewed or approved — it is never implemented
Resources
Foundationstart here
What a verifier looks for
- Ask the submitter how OKR quality changed from cycle one to cycle two — can they point to specific examples?
- Confirm the senior leader reviewed the system update recommendations — not just acknowledged them
- Check the data collection method for 'perceived usefulness' — what was the survey or collection approach?
Part of