The mechanics are deceptively simple. An Objective is qualitative and directional: "Become the clear market leader in cloud infrastructure." A Key Result is the quantitative test that tells you whether you got there: "Grow GCP revenue to $24.2M ARR by Q4" or "Achieve 65+ NPS among enterprise accounts." Google's standard is 3-5 objectives per quarter, each supported by 3-5 key results. That's a maximum of 25 measurable outcomes per team, per quarter.
What separates Google's implementation from most corporate goal-setting is the grading system, the cadence, and the explicit link between team-level OKRs and company-level strategy. None of those three things work the way most finance teams assume.
How Google Structures OKRs Across Levels
OKRs at Google cascade but don't clone. The company sets 3-5 annual objectives at the executive level. Each product area then sets quarterly objectives that contribute to those annual goals without copying them verbatim. Individual team OKRs connect to the product area OKRs, not directly to the company ones.
A finance team example: if the company objective is "extend runway to support Series B readiness," the FP&A team's quarterly OKR might be "build investor-grade financial model package" with key results like "complete three-statement model with monthly granularity through Q4 2027," "reduce churn below 3% annually," and "deliver sensitivity analysis across 5 WACC scenarios for bank syndicate DCF." The objective belongs to FP&A. The key results are owned by specific analysts.
Google also separates committed OKRs from aspirational OKRs. Committed OKRs are expected to hit 1.0 (fully delivered). Aspirational OKRs are meant to stretch the team, and a score of 0.7 is considered a win. Most companies miss this distinction and treat all OKRs the same way, which kills the point of aspirational goal-setting entirely.
The OKR Grading Scale: The Part Everyone Gets Wrong
Google grades OKRs on a 0.0-1.0 scale. The expected score is 0.6-0.7, not 1.0. This is the piece that breaks people's intuition.
A score of 1.0 means you set the target too low. A score below 0.4 triggers a post-mortem: something either went badly wrong in execution, or the key result was poorly written. The 0.6-0.7 zone is where healthy stretch lives.
As John Doerr writes in Measure What Matters (Portfolio, 2018): "We want to set goals that make us stretch, but not snap." That framing matters. If your finance team is consistently hitting 0.9+ across all OKRs, you're running a KPI system with inspirational language bolted on, not an OKR system.
Google's re:Work documentation (Google's official people operations resource, re.work/guides/set-goals-with-okrs) makes this explicit: "If you are consistently scoring 0.7 or above on aspirational OKRs, you aren't setting them ambitiously enough." The recommendation is to score at the end of the quarter and use those scores to calibrate the next quarter's targets, not to judge individual performance.
The grading scale also means OKRs can't function as performance reviews. Google keeps them separate by design. Mixing OKR scores with compensation decisions causes teams to sandbag targets to guarantee 1.0 scores. The moment that happens, the whole system reverts to theater.
Google's OKR Cadence: Quarterly + Annual, Not Either/Or
Google runs OKRs on two parallel timelines. Annual OKRs set the strategic direction for the year. Quarterly OKRs are the operational layer where work actually gets executed and tracked.
The cadence looks like this: company annual OKRs are set in Q4 for the coming year. Q1 kicks off with team-level quarterly OKRs that map to those annual goals. Mid-quarter check-ins (typically week 4-5 and week 8-9) let teams score progress and surface blockers. End-of-quarter scoring feeds into the next quarter's planning.
For FP&A teams, this creates a natural integration point with the quarterly board pack. The OKR check-in is a structured moment to pull actuals against the key result targets and explain variance - the same motion as budget vs. actual review, just mapped to strategic metrics rather than P&L line items.
The practical formula for tracking a key result in a multi-tab model looks like this:
=IFERROR(
SUMIFS('Actuals'!D:D, 'Actuals'!B:B, OKRs!$B4, 'Actuals'!C:C, ">=" & Assumptions!$B$3) /
OKRs!C4,
0
)
Where OKRs!C4 holds the target value (say, $24.2M ARR), Actuals!D:D is revenue, and the SUMIFS filters by business unit and period. The result is your OKR score as a decimal: 0.74 means you're at 74% of target.
Building an OKR Tracker in Google Sheets
The standard Google Sheets OKR layout uses one tab per quarter, with a summary tab that pulls scores across all teams. Here's the column structure most finance teams land on after a few cycles:
| Column | Contents | Example |
|---|---|---|
| A | Objective # | O1 |
| B | Objective text | Extend runway to Series B |
| C | Key result text | Reduce churn below 3% annually |
| D | Owner | FP&A / CS |
| E | Target | 3.0% |
| F | Actuals (formula) | ='Actuals'!C14 |
| G | Score (formula) | =1-(F5/E5) |
| H | Status | On track / At risk / Behind |
The actuals column is where most OKR trackers break down. Teams either update it manually once a quarter (defeating the purpose of a live model) or build a formula that references a range that drifts when rows are inserted. Neither works at scale.
The cleaner approach is to pull actuals from a named range on your P&L or metrics tab, scoped by time period:
=SUMIFS(
'P&L'!$E:$E,
'P&L'!$B:$B, OKRs!$B5,
'P&L'!$A:$A, ">=" & Assumptions!$C$2,
'P&L'!$A:$A, "<=" & Assumptions!$C$3
)
This pulls the relevant metric for the quarter without manual updates. The score column then auto-updates every time actuals come in.
ModelMonkey handles the part that's still manual for most teams: pulling external actuals into the tracker. If your churn rate lives in HubSpot or your ARR lives in Stripe, asking ModelMonkey to refresh those fields into your actuals tab takes seconds rather than a CSV export workflow. The OKR scores then recalculate automatically.