Quarterly OKR Planning
Purpose: Define the team's objectives and key results for the quarter and how to resource them
How to run this meeting
Limit the team to 3–5 objectives per quarter. More than that and you don't have priorities — you have a wish list. If everything is important, nothing is. The hardest and most valuable part of this meeting is not generating ideas; it's forcing the explicit trade-off conversation about what you're not going to do this quarter.
Key results must be measurable. "Improve developer experience" is an objective. "Reduce mean time to first green CI build from 18 minutes to 10 minutes" is a key result. Push every key result through the test: can you look at a number in 90 days and say definitively whether you hit it? If the answer requires judgment, rewrite it until it doesn't.
Distinguish committed OKRs from aspirational ones before you leave the room. Committed OKRs are things the team is expected to deliver — they affect resourcing decisions, and missing them is a problem. Aspirational OKRs are moonshots; you expect to hit 70% and you learn from the gap. Mixing them without labeling creates confusion about accountability. Most teams should have 1–2 committed OKRs and 1–2 aspirational ones per quarter.
Before the meeting
- Review last quarter's OKRs and score them before the planning session
- Collect input from team members and stakeholders on proposed objectives (async, in advance)
- Review company-level OKRs to ensure team objectives ladder up appropriately
- Bring data on current metrics that will serve as baselines for key results
- Come with a draft set of objectives for discussion — not a blank slate
Meeting Details
- Date:
- Facilitator:
- Attendees:
- Duration: 2–3 hours (half-day for larger teams)
Last Quarter Review
Brief assessment of Q1 results before setting Q2 direction. Don't skip this — it calibrates the conversation.
| Objective | Key Result | Target | Actual | Score |
|---|---|---|---|---|
| Improve platform reliability | API p99 latency < 150ms | 150ms | 162ms | 0.7 |
| Improve platform reliability | Error rate < 0.1% | 0.10% | 0.08% | 1.0 |
| Grow developer adoption | 50 new API integrations | 50 | 41 | 0.8 |
| Grow developer adoption | Docs NPS > 45 | 45 | 38 | 0.7 |
Retrospective notes: Latency improvement was blocked by a mid-quarter infrastructure migration that wasn't anticipated. API adoption was strong in the first 6 weeks, then plateaued — possible docs friction identified as a factor.
Objectives
The "what we want to achieve" — qualitative, inspiring, time-bound to the quarter.
O1 — Committed: Make Northstar's payment infrastructure production-ready for enterprise customers O2 — Committed: Reduce integration friction so developers reach their first successful API call faster O3 — Aspirational: Establish Northstar as a thought leader in developer-first payments infrastructure
Key Results
The measurable outcomes that define success for each objective. Each KR should have a baseline and a target.
O1 — Payment infrastructure
- KR1.1: Achieve 99.95% uptime across all payment endpoints (baseline: 99.87%)
- KR1.2: Pass third-party SOC 2 Type II audit with zero critical findings
- KR1.3: Reduce mean time to recovery (MTTR) for P0 incidents from 47 min to 20 min
O2 — Integration friction
- KR2.1: Reduce time-to-first-successful-API-call from 38 minutes to 15 minutes (measured via sandbox telemetry)
- KR2.2: Increase developer docs satisfaction score from 38 to 50 (quarterly survey)
- KR2.3: Launch interactive API explorer with 100% endpoint coverage
O3 — Thought leadership (aspirational)
- KR3.1: Publish 4 technical blog posts with >500 unique views each
- KR3.2: Speak at 2 developer conferences this quarter
Strategic Initiatives
The major workstreams or projects that will drive the key results. Map each initiative to its OKRs.
| Initiative | Drives | Lead | Rough Effort |
|---|---|---|---|
| SOC 2 audit preparation | O1-KR1.2 | @sec-lead | Large (6 weeks) |
| Incident response improvements | O1-KR1.3 | @dev-ops | Medium (3 weeks) |
| Developer onboarding flow redesign | O2-KR2.1, O2-KR2.2 | @dx-lead | Large (8 weeks) |
| API explorer build | O2-KR2.3 | @platform-lead | Medium (4 weeks) |
| Content/conference program | O3-KR3.1, O3-KR3.2 | @devrel | Small (ongoing) |
Resource Allocation
How the team's capacity is distributed across objectives and initiatives for the quarter.
| Team | O1 (reliability) | O2 (dx) | O3 (thought leadership) | Carry-over / Maintenance |
|---|---|---|---|---|
| Platform | 30% | 50% | 5% | 15% |
| Security | 80% | 5% | 0% | 15% |
| Infra / DevOps | 60% | 15% | 0% | 25% |
| DevRel | 10% | 40% | 50% | 0% |
Key trade-off decisions made:
- Mobile SDK work deferred to Q3 to protect SOC 2 timeline
- New enterprise features deprioritized in favor of reliability work
- DevRel time split toward O2 and O3 rather than direct sales support
Success Metrics
How will you track progress week over week? What are your leading indicators?
- Weekly reliability dashboard review (uptime, MTTR, error rate) — owned by @dev-ops
- Sandbox telemetry dashboard showing time-to-first-call — owned by @dx-lead
- Docs satisfaction surveyed mid-quarter (week 6) — owned by @devrel
- SOC 2 audit milestone tracker — owned by @sec-lead
Mid-quarter checkpoint: Week 6 review — score each KR at 0.0–1.0, adjust initiatives if off track.
Risks
What could prevent achieving these objectives? What assumptions are you making that might be wrong?
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| SOC 2 audit scope expands | Medium | High | Scope was reviewed with auditor last week; buffer built into timeline |
| Sandbox telemetry instrumentation takes longer than expected | Medium | Medium | Start instrumentation in week 1; KR measurement depends on it |
| Key personnel departure mid-quarter | Low | High | SOC 2 and DX work have shared knowledge; no single points of failure |
| Company-level strategy shift deprioritizes O3 | Medium | Low | O3 is aspirational; impact is bounded |
Action Items
| Owner | Action | Due Date | Status |
|---|---|---|---|
| @dx-lead | Instrument sandbox environment for time-to-first-call telemetry | 2026-03-20 | Open |
| @sec-lead | Send SOC 2 scoping doc to auditor for sign-off | 2026-03-16 | Open |
| @product-lead | Publish final Q2 OKRs to company wiki | 2026-03-16 | Open |
| @eng-manager | Share resource allocation plan with team leads | 2026-03-14 | Open |
| All leads | Confirm OKR ladder from team KRs to company OKRs | 2026-03-18 | Open |
Follow-up
Publish the final OKRs to a shared location (wiki, Notion, etc.) where the whole company can see them. Each objective should have a named owner who is accountable for tracking and reporting progress. Schedule a mid-quarter check-in (week 6) to score KRs and course-correct. OKR scores from this quarter become the starting point for next quarter's planning — close the loop.
Skip the template
Let Stoa capture it automatically.
In Stoa, the AI agent listens to your quarterly planning / okr planning and captures decisions, drafts artifacts, and tracks open questions in real time — no note-taking required.
Create your first Space — free