How do I map an OKR score to a financial model assumption?

Use a score-weighted blend between baseline and stretch: `=score * stretch + (1 - score) * baseline`. For a Customer Success NRR KR scored at 0.73 with a 115% stretch target and 108% baseline: `(0.73 × 115%) + (0.27 × 108%) = 113.1%`. That number flows directly into the NRR input cell of your retention ARR schedule. At $12.5M opening ARR, the difference between the 108% baseline and the 115% stretch target compounds to a $2.19M full-year revenue delta across four quarters.

How many objectives does Google's re:Work guide recommend per cycle?

The guide recommends 3-5 objectives per cycle, with 3-5 key results per objective. In finance and FP&A contexts, fewer is almost always better: 3 objectives with 3 KRs each gives you 9 data points to track and wire into a model, which is manageable. Above 5 objectives per cycle, the scoring data stops driving prioritization and starts just documenting activity.

What scoring formula should I use for aspirational vs. committed key results?

For committed KRs, cap at 1.0 with `=MIN(1, actual/target)` - overachievement on a committed KR is noise, not signal. For aspirational KRs, use `=actual/target` without a cap so overachievement is visible: at 118% actual NRR vs. a 115% stretch target, the score is 1.02, a number worth surfacing in a board summary. Collapsing both types into `MIN(1, actual/target)` hides overachievement on aspirational KRs and understates upside in the model.

What should I do if a key result target changes mid-cycle?

Lock KR targets at cycle start with a timestamp column. If the target changes, add a new row flagged "Revised" and keep the original row in place for audit. Reference the locked row in any variance analysis that cites the original board figure, and reference the revised row for forward projections. Without this, a mid-cycle target change silently breaks the link between your OKR scorecard and any materials that cited the original number - and nobody notices until the end-of-cycle review.

Google re:Work OKRs Guide: Wire Scores to Financial Model

Q: What is the difference between committed and aspirational OKRs in the Google re:Work guide?

Committed OKRs (roofshots) target a 1.0 score and are expected to be fully achieved; missing one signals a real operational or planning failure. Aspirational OKRs (moonshots) target 0.6-0.7 as the success band. Google's re:Work guide states directly that "if you're consistently scoring 0.7, you know you're setting the bar at the right aspirational level," and that objectives with consistent 1.0 scores "should be revisited - it is probably not ambitious enough." The financial treatment differs: committed KRs underwrite base-case assumptions, aspirational KRs define upside scenarios.

What the re:Work Guide Actually Says

The guide, hosted at rework.withgoogle.com, traces the framework to John Doerr's introduction of it at Google in 1999, which he picked up from Intel under Andy Grove. Core mechanics: 3-5 objectives per cycle, each with 3-5 key results, all scored 0.0-1.0 at cycle end.

The guide's exact language on scoring: "Key Results should be measurable... if you're consistently scoring 0.7, you know you're setting the bar at the right aspirational level." A 1.0 on an aspirational KR is a red flag, not a win. The guide is direct: "If an objective has a consistent 1.0 score, it should be revisited - it is probably not ambitious enough."

For committed KRs (what the guide calls "roofshots" vs. aspirational "moonshots"), the expectation flips. Miss a committed KR and something material went wrong: a hire didn't happen, a renewal slipped, a system went down.

Committed vs. Aspirational: Two Different Financial Treatments

The scoring target tells you exactly how to use each KR type in a model.

	Committed (Roofshot)	Aspirational (Moonshot)
Score target	1.0	0.6-0.7
Miss interpretation	Something broke	Normal; recalibrate
Financial treatment	Underwrite base-case budget	Drive upside scenario
Formula pattern	`MIN(1, actual/target)`	`actual/target` (can exceed 1.0)
Typical examples	Renew 95% of ARR, close 100 logos, ship by Mar 31	NRR ≥ 115%, $4.2M ARR, 3 enterprise integrations
Miss response	Budget variance; escalate immediately	Expected; document and adjust

The Mapping Layer: OKRs to Financial Model Assumptions

The gap the re:Work guide doesn't close is the translation from OKR score to model input. Here's a concrete 3-department structure that closes it.

KR_Tracker tab - one row per key result:

Dept	Key Result	Baseline	Stretch	Q2 2026 Score	Weighted Assumption
Customer Success	NRR ≥ 115% by Q4 2026	108%	115%	0.73	113.1%
Sales	New bookings ≥ $1.8M in Q2	$1.4M	$1.8M	0.85	$1.74M
Product	3 enterprise integrations live by Q3	1	3	0.60	2.2 integrations

The "Weighted Assumption" column is what flows into your financial model. The formula:

// Assumptions!B3 - NRR assumption, blended by OKR score
=KR_Tracker!E4 * KR_Tracker!G4 + (1 - KR_Tracker!E4) * KR_Tracker!F4
// At score 0.73: (0.73 × 115%) + (0.27 × 108%) = 113.1%

E4 is the live OKR score. F4 is baseline NRR. G4 is stretch NRR. As the score updates each month, the NRR assumption in your model adjusts automatically. No manual override. No stale cell nobody touches between board cycles.

For a committed KR like new bookings, same pattern: (0.85 × $1.8M) + (0.15 × $1.4M) = $1.53M + $0.21M = $1.74M as the live bookings assumption feeding into your new ARR line.

NRR at 115% vs. 108%: What That KR Does to Your Retention Schedule

With $12.5M opening ARR, the spread between baseline and stretch NRR compounds through four quarters. Here's the retention waterfall, split by scenario - opening cohort only, new ARR excluded:

Quarter	Baseline (108% NRR)	Stretch (115% NRR)	Δ vs. Baseline
Q1 2026	$12.75M	$12.97M	+$220K
Q2 2026	$13.00M	$13.44M	+$440K
Q3 2026	$13.25M	$13.91M	+$660K
Q4 2026	$13.50M	$14.38M	+$875K
Full-year revenue delta			+$2.19M

The formula in ARR_Bridge!C8 (Q1 retained ARR, score-weighted):

// ARR_Bridge!C8 - quarterly retained ARR using blended NRR
=ARR_Bridge!B8 * (1 + (Assumptions!$B$3 - 1) / 4)
// B8 = opening ARR ($12.5M), B3 = 113.1% blended NRR
// Result: $12.5M × 1.0328 = $12.91M

Drag that across Q2-Q4. Now when a CS team member updates their NRR score from 0.73 to 0.81 in KR_Tracker!E4, Assumptions!B3 recalculates to (0.81 × 115%) + (0.19 × 108%) = 113.6%, and the full retention schedule reprices in the same sheet refresh. The $2.19M full-year revenue delta is a live number, not a judgment call locked into a tab from January.

That's the bridge the re:Work guide doesn't build. The OKR score in column E is the single input that moves a revenue line across four quarters.

Scoring Formulas That Handle Both KR Types

For committed KRs, cap at 1.0:

// KR_Tracker!E4 - committed KR (e.g., new bookings target)
=MIN(1, Actuals!D4 / KR_Tracker!D4)
// Actuals!D4 = Q2 bookings closed; D4 = $1.8M target

For aspirational KRs, let the score exceed 1.0 so overachievement is visible:

// KR_Tracker!E7 - aspirational KR (e.g., NRR)
=Actuals!D7 / KR_Tracker!D7
// At 118% actual vs. 115% target: score = 1.02

Department average, excluding cancelled KRs, filtered by current cycle:

// Summary tab - average score for Customer Success, current cycle only
=AVERAGEIFS(
  KR_Tracker!$E$2:$E$50,
  KR_Tracker!$B$2:$B$50, "Customer Success",
  KR_Tracker!$F$2:$F$50, "<>Cancelled",
  KR_Tracker!$G$2:$G$50, Assumptions!$B$1
)
// B1 = current cycle label, e.g. "Q2 2026"

This is what goes into a board pack: one score per department, tied to one revenue assumption per KR, pulling live from actuals.

If you're building the tracker from scratch, the OKR Google Sheets template covers the full 5-tab setup, including the KR_Tracker structure these formulas assume. For keeping OKR status current mid-cycle, see refreshing OKR status in Sheets.

Where the re:Work Guide Is Thin for Finance

The guide says nothing about mid-cycle target changes. If your "NRR ≥ 115%" KR gets revised to "NRR ≥ 110%" in August because a major account churned, you have a problem: the financial model was built on 115%, the board got a Q2 update citing 115%, and now the KR quietly moved. That's not an OKR design failure. It's a change-control failure the guide doesn't address.

The fix: lock KR targets at cycle start with a KR_Lock timestamp column. If a target changes, fork to a new row flagged "Revised" and keep the original row visible for audit. Your model references the locked row for variance analysis, the revised row for forward projections, and a board summary note explains the gap.

The other gap is weighting. "Ship 3 integrations" and "renew 95% of ARR" are not the same financial magnitude. The guide offers no weighting mechanism. Add a KR_Weight column that sums to 1.0 per objective, then replace AVERAGEIFS with SUMPRODUCT for department-level scores.

Pulling Live Actuals into the Tracker

The mapping layer only works if the actuals column stays current. ModelMonkey can pull actuals from Stripe, HubSpot, or your data warehouse directly into KR_Tracker, so Actuals!D4 (Q2 bookings closed) updates without anyone exporting a CSV. That keeps the score-weighted NRR assumption in Assumptions!B3 live between OKR review meetings rather than reflecting a number from three weeks ago.

As of mid-2026, the most common failure mode in OKR-linked models isn't bad formula design. It's actuals that are 6 weeks stale because the data pull is manual and nobody owns the refresh.

Try ModelMonkey free for 14 days - it works in both Google Sheets and Excel.