Why does Google re:work say OKRs should not be tied to compensation?

Google re:work separates OKRs from compensation to protect the integrity of target-setting. When OKRs drive pay, employees set conservative targets to protect their bonus - a pattern called sandbagging. Google's framework targets roughly 70% OKR completion as the sign of appropriate ambition; if you pay out based on that attainment rate, you've created an incentive for 70% to become the ceiling, not the floor. Performance evaluations, which run on a separate cycle, handle compensation decisions instead. The re:work guide states this explicitly: "Do not use OKRs for performance reviews."

What does Google use to determine compensation if not OKRs?

Under the re:work model, compensation is driven by performance reviews - a separate process evaluating how an employee executed their role, not just whether their team hit its quarterly targets. The review considers judgment, collaboration quality, and output. OKR results may appear as supporting context in a manager's review narrative, but they don't feed directly into a payout formula. Keeping the two separate lets OKR targets stay ambitious without creating a financial incentive to low-ball them in the planning cycle.

How do I structure a comp model at a company that has separated OKRs from pay?

Your bonus pool calculation should reference a performance rating column from a Perf Reviews tab or HRIS export, not OKR achievement percentages. The typical structure is a SUMIFS against rating tiers applied to base salary from your Headcount tab, with payout multipliers in your Assumptions tab. Run your sensitivities on rating distribution - what changes if 15% vs. 20% of headcount lands in the top tier - rather than on OKR attainment. Check your comp tab for any `='OKR Tracker'!` formula references; if they exist in a payout cell, that's the coupling Google's framework is designed to remove.

Does separating OKRs from comp mean OKRs are irrelevant to performance reviews?

No. The separation is about formula links, not information flow. In practice, managers writing a strong review narrative will almost always reference OKR contributions as evidence. The distinction is between OKRs as inputs to a qualitative judgment versus OKRs as a cell reference driving a calculation. As re:work frames it, OKRs measure whether goals were ambitious and whether progress was made - not a complete picture of how someone performed their role. Keeping the two separate lets both processes do their jobs without corrupting each other.

What if my company still uses OKR scores in bonus calculations?

It's more common than the re:work literature suggests. The main risk is target compression over time: each planning cycle, managers negotiate targets slightly lower to protect payout, and the numbers that reach finance are pre-discounted before they hit the model. Some companies try to mitigate this with forced distributions on OKR scoring (for example, no more than 20% of teams can grade themselves above 85%), but that tends to generate its own gaming dynamics. The cleaner fix is Google's approach: run OKR grading as a transparency exercise with no compensation consequence, and let the performance review handle pay decisions independently.

Google re:work: Why OKRs Aren't Tied to Compensation

The Sandbagging Math

OKRs are designed to be aspirational. Google's framework targets roughly 70% completion as the sign of appropriate ambition. As the re:work OKR guide states: "If people are always hitting 100%, the targets weren't ambitious enough."

Tie those same OKRs to a bonus pool and the math inverts. A manager whose team's $14.2M ARR target determines their 15% annual bonus has every incentive to negotiate that target to $11.8M before Q1 starts. The OKR number stops representing what the business actually believes is achievable and starts representing what's safe to miss.

Across 50 employees running the same negotiation, your operating plan drifts toward a consensus fiction. Finance ends up modeling off numbers that were discounted before they hit the Assumptions tab.

That's the structural problem Google re:work is trying to prevent.

What the re:work Framework Actually Says

The Google re:work OKR guide is direct: "Do not use OKRs for performance reviews. If OKRs are used to reward or punish employees for their results, the goal-setting process gets politicized and people will start to set easily achievable OKRs."

The framework traces to Andy Grove at Intel in the 1970s, where OKRs were introduced as a management alignment tool - not an evaluation mechanism. John Doerr formalized the separation when he brought the system to Google in 1999, and the compensation decoupling has been a documented, non-negotiable part of Google's published guidance since (rework.withgoogle.com, updated through 2025).

The implication is architectural: OKRs measure collective ambition. Performance reviews measure individual execution. They draw on different data, run on different timelines, and should live in different tabs in your model - with no formula links between them.

How This Changes Your Comp Model Structure

Most comp models at mid-size companies have this buried somewhere in their structure: a cell in the bonus calculation pulling from an OKR score. It's usually labeled "goal attainment %" and driving 30-50% of the payout formula.

If your company follows the re:work framework, that link shouldn't exist. Here's what the two approaches look like in a real model.

The wrong architecture - OKR achievement feeding the bonus calc:

// Bonus per employee, pulling OKR attainment from tracker tab
=IFERROR(
  VLOOKUP(Headcount!B5, 'OKR Tracker'!$A:$F, 6, FALSE)
  * Headcount!E5 * Assumptions!$C$12,
  0
)

This wires OKR scores directly to comp. You'll see it dressed up as a multiplier, a gate, or a weighted average - the effect is the same.

The right architecture - performance rating feeding the bonus, OKRs informing but not calculating:

// Bonus pool per headcount, driven by perf rating tier
// Perf Reviews tab comes from manager ratings, not OKR scores
=SUMPRODUCT(
  ('Headcount'!$D$2:$D$200 = Assumptions!$B$5) * 1,
  VLOOKUP('Perf Reviews'!$C$2:$C$200, Assumptions!$G$3:$H$7, 2, FALSE),
  'Headcount'!$E$2:$E$200
)

The Perf Reviews tab feeds from manager evaluations (Exceeds/Meets/Below), not from ='OKR Tracker'!F5. The OKR Tracker exists as a planning and visibility tool - it's read by finance and leadership but has no formula paths into the comp model.

What Drives Comp Instead

Under the Google model, compensation decisions rest on a separate performance review process, deliberately run at a different time of year to prevent conflation. Performance reviews assess how someone executed their role - judgment, collaboration, output quality. OKRs assess whether goals were ambitious and whether progress was made. They're measuring different things.

For your comp model, the input data looks structurally different:

Source	Data	Used in Comp Formula?
OKR Tracker	Target, Actual, Achievement %	No direct formula link
Performance Reviews	Rating (Exceeds/Meets/Below)	Yes - primary driver
Market benchmarks	Salary band vs. midpoint	Yes - calibration input
Tenure/promo data	Years in role, last increase	Yes - eligibility gate

The OKR Tracker might inform the performance review narrative - a manager noting their team hit 68% of an ambitious pipeline target. But the payout formula references the review rating, not the OKR percentage.

Bonus Pool Modeling Without OKR Anchors

If your company has separated OKRs from comp, your bonus pool model needs a different sensitivity structure. You're not varying achievement percentages across headcount. You're varying rating distributions.

A clean version looks like this:

// Bonus pool total by rating tier
// Multipliers in Assumptions!$G$3:$H$7
// Cross-tab references: Headcount, Perf Reviews, Assumptions

=SUMIFS('Headcount'!E:E, 'Perf Reviews'!C:C, "Exceeds")
  * VLOOKUP("Exceeds", Assumptions!$G$3:$H$7, 2, FALSE)
+SUMIFS('Headcount'!E:E, 'Perf Reviews'!C:C, "Meets")
  * VLOOKUP("Meets", Assumptions!$G$3:$H$7, 2, FALSE)
+SUMIFS('Headcount'!E:E, 'Perf Reviews'!C:C, "Below")
  * VLOOKUP("Below", Assumptions!$G$3:$H$7, 2, FALSE)

This structure lets you run the sensitivities that actually matter for board-level comp discussions: what happens to the $2.4M bonus pool if the "Exceeds" population is 18% of headcount vs. 12%? That's the lever finance controls. Whether the ARR OKR hit 71% or 74% isn't the input.

One Thing Most Articles Miss

The re:work prohibition applies at the calculation level, not the information level. OKRs don't disappear from the comp process - they appear in the manager's review narrative as supporting evidence. A manager justifying an "Exceeds" rating will cite OKR contributions. The difference is that this is a qualitative input to a human judgment, not a cell reference in a formula.

For FP&A, this distinction matters when you're auditing an inherited model. A quick Ctrl+`` (toggle formula view) scan of the comp tab will surface any cross-tab references you should interrogate. If you see ='OKR Tracker'! anywhere in a bonus calculation, that's the conversation to have with HR before the next planning cycle.

If you're building an OKR tracker alongside a clean comp model, the OKR template guide covers the tab structure and keeps both tools in their proper lane.

ModelMonkey can scan across tabs and map formula dependencies - useful when you've inherited a comp model and need to know quickly whether someone quietly wired OKR scores into the payout calc. Try ModelMonkey free for 14 days - it works in both Google Sheets and Excel.