OKRs - From Mission to Metrics - How Objectives and Key Results Can Help Your Company Achieve Great Things

1. 1Set the Results Meeting cadence to sit inside your short cycle. If you run monthly cycles, meet more frequently; for quarterly cycles, a weekly or biweekly Results Meeting keeps OKRs alive. The point is a fixed, recurring gathering the leader holds with direct reports.
2. 2Confirm every Key Result is built on a plottable, easy-to-measure KPI that the owner can influence and that reports within the cycle. If a KR is hard to measure, people won't track it, and monitoring collapses before it starts. Fix fuzzy KPIs ("sales") into precise ones ("revenues from new orders") before you begin monitoring.
3. 3Track two things continuously between meetings: the metric each KR is based on, and the action plans/initiatives that were planned to move it. Best case is the plan being executed AND the KR moving toward target; anything else surfaces at the meeting.
4. 4Run the meeting on one fixed agenda per direct report: which OKRs/Projects are off-track (red), why they're off-track, and which actions are already under way to recover them. Give each report a time allotment and hold the line on it.
5. 5Focus exclusively on what's red. Skip on-track items entirely because time is limited and meetings become long and boring; spend the scarce time on problems and root-cause analysis.
6. 6Protect the culture in the room: do not condemn or humiliate anyone presenting red items. Treat failed hypotheses as normal; treat unhonored commitments (action plans not followed through) as a separate behavioral issue handled offline.
7. 7Close the loop by feeding what you learn into the next planning cycle — the debriefing (grading OKRs) kicks off a new cycle, often concomitantly.

A manager in the accounts payable team, under the CFO, owns an OKR to reduce errors in invoices paid and received, plus another to reduce days-receivable/extend days-payable. She unfolds these into Projects: implementing a major new piece of software and reengineering the approval process. In the Results Meeting she reports only the red items — say, the error-reduction KR is off-track. She explains why (the new software rollout slipped, so errors haven't dropped), then states the actions already under way (a revised rollout schedule and interim manual double-checks). Because she honored her prior commitments and is honestly reasoning about what went wrong, the discussion stays intellectually challenging rather than a scolding. The team leaves with a corrected hypothesis for the next cycle, not a scapegoat.

• If a KR's KPI is hard to measure or outside the owner's control, then rewrite or reassign it before monitoring — otherwise it will never get tracked.
• If an item is on-track (green), then skip it in the Results Meeting; only red items get airtime.
• If someone's hypothesis failed but they honored their commitments, then treat it as constructive learning; if they broke a commitment (an action plan not executed), then handle it offline as a behavioral issue.
• If the cycle is short/fast-paced (e.g., ridesharing), then monitor more frequently; if the market is stable, a lighter cadence within a quarterly or semiannual cycle suffices.
• If people can't remember their OKRs or teams aren't tracking them, then you scaled too fast — pull back to fewer OKRs and shorter cycles until the monitoring habit forms.

• Fuzzy KPIs kill tracking. Tell: KRs say "sales" instead of "revenues from new orders," and no one can state the actual number in the meeting.
• Turning the meeting into public scolding. Tell: presenters go defensive, hide red items, and the room feels like guilt and finger-pointing rather than problem-solving.
• Reviewing everything, including greens. Tell: meetings run long and boring and lose the focus on root-cause of what's off-track.
• Confusing efforts with results. Tell: people report on Projects executed (effort) as if they were OKRs (results) — "we implemented the ERP" instead of "errors dropped."
• Scaling too fast — unfolding many OKRs to individuals in a long cycle at once. Tell: nobody remembers their OKRs, teams stop monitoring, and the ritual quietly dies.

• ▸Owner / role — who presents this item
• ▸OKR or Project — name it, and mark whether it's a result (OKR) or effort (Project)
• ▸KPI & formula — the exact plottable metric and how it's calculated
• ▸Current vs. target — this cycle's number against the goal
• ▸Status — green (skip) or red (present)
• ▸Why off-track — the root cause / failed hypothesis, in one line
• ▸Actions already under way — recovery steps started, not planned intentions
• ▸Commitment check — was the prior action plan honored? (yes / no → offline)

1. 1Start with a single company-wide Objective and three or four Key Results—no more. Resist the urge to define five OKRs or push them to individuals in cycle one.
2. 2Run that first Objective on a one-month cycle. The short cycle exists so you can course-correct fast and rehearse the rituals (results meetings, debriefings) before they carry weight.
3. 3Set the initial Key Results conservatively—levels that aren't a big stretch. Employees don't yet know how their main KPIs behaved historically, so aggressive targets are guesswork that leads to universal failure and a tarnished image for the whole method.
4. 4Debrief every cycle honestly: did you hit the result (yes/no), what went right, what went wrong, why, and what you learned. Use a simple form or a couple of slides. The point is building the reflection habit, not the paperwork.
5. 5After roughly three monthly cycles, unfold the OKRs loosely to teams—company level first, individual level only once the company cadence is real.
6. 6Only after the company as a whole reaches 70–80% of targets do you let people set stretch goals, and cap it at one stretch OKR per cycle. Never lead with moonshots.
7. 7Treat 'has the company incorporated the habit of monitoring its OKRs?' as your true success signal—more than any single result achieved.

A company adopts OKRs and warms the engines gradually. Month 1: it sets one company-wide Objective with four Key Results, all at conservative levels, on a one-month cycle. At month's end everyone fills a short reflection form—results achieved yes/no, what went right and wrong, why, and lessons—and repeats. It does this for three monthly cycles, using each to fix how results meetings and debriefings are run. Around month 3 it unfolds those OKRs loosely to teams, then runs three more monthly cycles at the team level. By contrast, a company that tries to unfold five company OKRs to the individual level in an annual cycle fails: people don't know what's going on, can't remember their OKRs, and teams don't monitor them. Only after the gradual company reaches 70–80% of targets across the org does it let people add a single stretch OKR per cycle.

• If it's your first cycle, then use one company-wide Objective with three or four Key Results—not more, not individual-level.
• If the company hasn't yet consistently hit 70–80% of targets, then keep goals conservative and allow zero stretch OKRs.
• If you've reached the 70–80% maturity threshold, then permit one stretch OKR per cycle—but never more than one.
• If teams don't yet remember or monitor their OKRs, then you've moved too fast; shrink scope and lengthen the habit-building phase before unfolding further.
• If employees don't understand how a KPI has behaved historically, then set the Key Result conservatively rather than aggressively.

• Doing everything at once—five company OKRs cascaded to individuals on an annual cycle. Tell: people can't recall their OKRs and teams stop monitoring them.
• Leading with moonshots. Employees, ignorant of past KPI behavior and spooked by Google 'roof shot/moonshot' lore, set overly aggressive Key Results; when no one hits them, the first impression is terrible and OKRs get abandoned. Tell: near-zero achievement in early cycles.
• Starting with long (annual) cycles instead of short ones, removing the fast course-correction that early habit-building needs. Tell: problems surface only at year-end.
• Skipping company-level and going straight to individual OKRs. Tell: individuals have goals but there's no aligned company Objective above them.
• Setting too many OKRs and losing the focus the short cycle is meant to buy. Tell: attention scattered across goal-irrelevant activities.

• ▸Current cycle number: which iteration you're on (e.g., cycle 1).
• ▸Scope this cycle: company-only / loosely-unfolded-to-teams / individual—pick based on maturity.
• ▸Cycle length: start at one month; lengthen only after habits stick.
• ▸Number of Objectives: keep at one for early cycles.
• ▸Number of Key Results: three or four to start.
• ▸Stretch level: conservative until org hits 70–80%; then max one stretch OKR.
• ▸Habit check: are teams monitoring and recalling their OKRs? (yes/no).
• ▸Debrief completed: results yes/no, what went right/wrong, why, lessons learned.
• ▸Trigger to advance: conditions met to add scope or stretch next cycle?

1. 1Define the small set of business results that matter for the coming cycle (typically 3 months) — force yourself to name only the vital few Objectives, not everything you could do.
2. 2Attach measurable Key Results to each Objective so that 'success' is unambiguous, e.g. 'grow net income to $100 million' and 'reach net profit margin above 7%.'
3. 3Separate efforts from results before finalizing: mark each candidate as effort (attending sales meetings, building a feature) or result (closing sales, raising conversion), and only keep results as Key Results.
4. 4Ripple the focus downward: company OKRs feed VP OKRs, which feed director and squad OKRs, so every level knows which small set of things matters here and now.
5. 5Make the OKRs public by default so dependencies and conflicting priorities surface early and can be discussed and resolved.
6. 6In monitoring meetings, spend time exclusively on what's 'red' (off-track) — skip on-track items unless time remains — because time is limited and meetings get long and boring.
7. 7Use a two-by-two matrix (action plan executed y/n × OKR achieved y/n) to diagnose whether a result happened on purpose or by chance, and apply Five Whys to reach the root cause before the Results Meeting.

A company wants to concentrate the cycle on one vital priority: 'We will increase the profitability of the company.' Rather than listing every finance initiative, it commits to two Key Results: grow net income to $100 million and reach a net profit margin above 7%. Because OKRs belong to a cycle and carry no separate end date, everyone assumes both must be hit before the quarter closes. A product squad that owns only the shopping cart does not adopt the profitability OKR directly; its focused Objective is 'improve shopping cart conversion rates' with the Key Result 'improve conversion between adding items and purchase from 3% to 5%.' This keeps each team's attention on results relative to what it actually controls, and away from goal-irrelevant activity. In the Results Meeting, only the off-track (red) items get discussed, so the group's limited attention lands on the problems that matter.

• If a candidate item describes activity (attending a meeting, implementing an ERP, building a feature) rather than an outcome, then it's an effort — demote it, don't make it a Key Result.
• If an OKR is on-track, then don't spend meeting time on it unless there's surplus time — reserve focus for red items.
• If actions were executed but the OKR is off-track (Quadrant 1), then the hypothesis/plan was wrong — investigate and adjust the plan, not the people.
• If a result is relative to another team's scope, then assign the OKR to the team that actually owns that lever — squad OKRs track results relative to the person or team owning them.
• If someone presents off-track work, then treat it as a problem to solve, not a person to scold — behavioral follow-through issues get handled one-on-one, offline.

• Listing too many priorities so nothing is truly vital — the tell: teams can't say what does NOT matter this cycle.
• Confusing efforts for results (50 sales meetings logged, no sales closed) — the tell: Key Results describe activity you can do regardless of outcome.
• Letting goal-setting itself consume 2–4 months of the fiscal year — the tell: less than 20% of the year is left for actual work, and some employees fill goals with 'dots and gibberish.'
• Discussing on-track items in monitoring meetings — the tell: meetings run long and boring, and red items get rushed at the end.
• Turning off-track reviews into finger-pointing — the tell: presenters hide problems or get humiliated, killing the learning culture the two-by-two matrix depends on.

• ▸Cycle length & end date: state the period (default 3 months) by which OKRs must be complete.
• ▸Objective (max 1–3): the vital business result you concentrate effort on this cycle.
• ▸Key Results: 2–3 measurable outcomes with from→to numbers (e.g. margin 3%→5%).
• ▸Owner & scope: the team/person whose controllable levers this result is relative to.
• ▸Effort vs result check: confirm each KR is an outcome, not an activity.
• ▸Alignment link: which higher-level OKR this feeds (company→VP→director→squad).
• ▸What does NOT matter this cycle: explicitly named lower priorities to ignore.
• ▸Off-track (red) trigger: the threshold at which this item earns Results Meeting time.
• ▸Root-cause note: quadrant (1–4) + Five Whys finding for any red item.

1. 1Set the goal above current capacity but within reasonable reach: per Falconi, the value of the goal must be above the person's capacity to reach it so they must learn and grow, yet Locke's finding is that only difficult-but-achievable goals raise motivation. Calibrate between too-easy and too-hard, both of which demotivate.
2. 2Separate the goal from compensation. Run it as a management tool, not a pay-for-performance formula, so people can commit to aggressive roof-shots and moonshots without sandbagging to protect their bonus.
3. 3Distinguish effort from result when writing the goal. State the result relative to the owner (e.g., 'improve conversion between adding to cart and purchase from 3% to 5%'), not the effort ('build a new cart feature').
4. 4Install constant feedback against the goal. Mace found goals only work when individuals get ongoing performance comparisons and see discrepancies as they emerge, not at year-end.
5. 5When someone misses, coach the attribution before resetting the goal. Steer them toward causes that are internal, unstable, and controllable (e.g., 'lack of effort this cycle') and away from stable/uncontrollable framings that trigger lowered goals.
6. 6Have the person set and calibrate the goal themselves, bottom-up, then align it upward. Drucker: self-control produces 'a desire to do the best rather than just enough to get by'; a mere 'sense of participation' is not enough.
7. 7Watch persistence, not just initial effort. Goals mostly raise performance by prolonging effort over time, so protect against withdrawal when a large negative gap makes attainment look unlikely.

A product team owns the shopping-cart feature. Instead of the effort goal 'build a new cart feature,' you write the result-owned Objective 'improve shopping cart conversion rates' with the Key Result 'improve the conversion rate between adding items and purchasing from 3% to 5%.' The 5% target sits above the team's current demonstrated capacity, so per Falconi they must learn and experiment to reach it, which raises task motivation per Locke. Because this OKR is not tied to their bonus, they set a genuine roof-shot rather than negotiating it down. You give them weekly conversion feedback so discrepancies surface early and effort is prolonged rather than abandoned. When they land at 4% and miss, you frame the shortfall as an unstable, controllable cause ('we didn't run enough tests this cycle') rather than 'the team lacks the skill,' so next cycle they set an equally hard target instead of sandbagging.

• If the goal is at or below current capacity, then raise it until reaching it requires learning and growth, since easy goals demotivate as much as impossible ones.
• If a goal statement describes an activity or deliverable, then it's an effort, not a result; rewrite it as a measurable outcome owned by that person or team.
• If you want people to commit to aggressive stretch goals, then decouple the goal from variable compensation, because linking the two invites sandbagging.
• If someone misses and attributes it to stable/uncontrollable causes ('I'm not good enough,' 'the market'), then intervene to reframe toward internal, unstable, controllable causes before they set next cycle's goal, or they'll lower it.
• If a negative goal-performance gap grows large and attainment looks unlikely, then add feedback and support fast, because discouragement triggers withdrawal of effort.

• Writing efforts as goals: tracking 'attended 50 sales meetings' or 'implemented the ERP' instead of 'closed sales' or 'reduced accounting errors.' Tell: the goal has no KPI and mixes activities, job descriptions, and projects.
• Tying attainment to pay: bonuses depend on hitting 100%, so people negotiate soft, achievable targets. Tell: goals cluster suspiciously near 100% attainment and nobody sets a roof-shot.
• Setting goals so hard they read as unrealistic: Mace found unrealistic goals aren't accepted by the individual. Tell: quiet non-commitment, or people fill the goal field with 'dots and gibberish.'
• Letting missed goals default to stable/incompetence attributions: individuals then adjust goal levels down (sandbag) next cycle. Tell: goal levels shrink after every setback.
• No ongoing feedback: goals are set, then untouched until year-end. Tell: goal-setting eats 2-4 months and mid-cycle discrepancies are never surfaced, so effort isn't prolonged.

• ▸Objective (owned by whom): the outcome this person/team is accountable for, stated as a result not an effort
• ▸Key Result (from X to Y): a measurable target with baseline and destination
• ▸Difficulty check: is the target above current capacity yet reasonably achievable? (yes/no + why)
• ▸Compensation linkage: is this goal tied to pay? (aim for 'no' to enable roof-shots)
• ▸Feedback cadence: how and how often the person sees performance vs. goal
• ▸Setback attribution (on a miss): internal or external? stable or unstable? controllable or uncontrollable?
• ▸Reframe action: how to shift the attribution toward internal/unstable/controllable
• ▸Next-cycle goal decision: keep, raise, or (flag if lowering = sandbagging)

1. 1Break the compensation link first: separate OKR attainment from pay-for-performance bonuses. As long as bonuses ride on the numerator, people negotiate easy goals (sandbagging) and commitment is corrupted into self-protection.
2. 2Run OKR-setting as a two-way process: have each contributor draft their own OKRs in line with the higher team/company goals, then calibrate them with their manager for cohesion and alignment. Do not push goals 'down the line' from board to CEO to VP as a rigid cascade.
3. 3Make OKRs public by default so anyone can consult individual and team OKRs; keep private only genuinely confidential items (M&A, layoffs, cost-cut plans). Transparency lets people see how their work impacts the bigger picture, which is what drives commitment.
4. 4Nest cadences explicitly: connect each short cycle (1–6 months) up to the annual cycle, up to the strategic cycle (3–10 years), up to mission and vision — like Russian dolls — so each person can trace their OKR to a superordinate goal they value.
5. 5Set OKRs as stretch/moonshot goals where hitting ~70% takes real effort, and state up front that missing them is not punished. Aggressive goals only build commitment when the culture makes it safe to fall short.
6. 6Run Results Meetings that focus only on what's off-track and treat misses as flawed hypotheses, not moral failures. Never condemn or humiliate the presenter publicly; handle broken commitments (unexecuted action plans) offline as behavioral issues.
7. 7When something is off-track, use the execute/achieve two-by-two to diagnose: ask whether the action plan was executed and whether the OKR was reached, so the team learns whether the miss was 'by chance' or a wrong hypothesis — this keeps effort attributed to controllable causes and preserves commitment.

A product team owns only the shopping cart feature. Instead of accepting a top-down number, they draft their own Objective — 'improve shopping cart conversion rates' — and a Key Result: 'improve the conversion rate between adding items to the shopping cart and making a purchase from 3% to 5%.' Because they wrote it themselves and calibrated it with their manager, they own it rather than treating it as a mandatory pain. The OKR is public, so the team can see how a higher cart conversion feeds revenue and the company mission, which sustains their dedication. In the Results Meeting, if conversion is stuck at 3.5%, the discussion is not 'who failed' but 'why was our hypothesis wrong and what will we change' — an intellectually challenging session, not a scolding. Because compensation is not tied to hitting exactly 5%, nobody has an incentive to have argued for an easier 3%-to-3.5% target. The actual result achieved, not the percentage, is what matters.

• If goal attainment feeds directly into bonuses, then expect sandbagging and even fraud (as at Wells Fargo) — break the link before expecting genuine commitment.
• If a goal was set purely top-down with no employee voice, then treat low commitment as the predictable outcome and rebuild it via bottom-up drafting plus manager calibration.
• If an OKR is tangential to the higher superordinate goal, then let people revise it downward; if it contributes significantly to a highly valued higher goal, then push to continue pursuit even after a miss.
• If a person attributes a miss to a controllable cause (like effort), then they will renew commitment — reinforce that framing; if they blame uncontrollable/stable causes, they will lower future goals, so steer the diagnosis toward controllable factors.
• If a team is grossly out of alignment, then it will stand out precisely because OKRs are visible — use that visibility to correct it rather than a rigid cascade process.

• Linking OKR percentage to pay — the tell: managers and employees politically negotiate easy goals before the cycle and resist changing them mid-year.
• Running a rigid top-down cascade and calling it OKRs — the tell: employees are still 'filling in' their goals at year-end just in time for reviews, and quality is terrible.
• Keeping OKRs private or siloed — the tell: people can't explain how their work impacts the bigger picture, so dependencies and conflicts surface late.
• Punishing missed stretch goals — the tell: Results Meetings feel like scolding sessions, so people set safe goals and hide bad news instead of surfacing off-track items.
• Letting people set any goal they want in the name of 'bottom-up' — the tell: the process becomes chaotic and unsynchronized, and teams row in different directions with no alignment.

• ▸Objective (drafted by owner): the qualitative aim in your own words
• ▸Key Result (measurable, from X to Y): a real result for the owner, not an effort
• ▸Superordinate goal it serves: which higher team/company/strategic goal this feeds
• ▸Why it matters to me/us: one line on the impact on the bigger picture
• ▸Bottom-up vs top-down origin: who proposed it and where calibration happened with the manager
• ▸Public or private: default public; mark private only if confidential (M&A, layoffs)
• ▸Cycle length (1–6 months): the short cycle this OKR runs in
• ▸Stretch level: is ~70% attainment hard? confirm it is aggressive
• ▸Compensation link: confirm this OKR is NOT tied to variable pay

1. 1Set company OKRs first: reduce the CEO/board strategy to one or more Objective–Key Result pairs. If the priority is organic market-share growth to defend against Chinese competitors, that becomes the company Objective everyone reads before writing their own.
2. 2Publish all OKRs by default so every team can consult them. Keep only genuinely confidential items (M&A, cost-reduction plans implying layoffs) private. Transparency is what lets conflicts and dependencies surface.
3. 3Align through time and through the organization: strategic OKRs derive from mission/vision, annual OKRs derive from strategic, then within one cycle VPs align to company, directors to VPs, squads to business units and to each other.
4. 4Run the unfolding bottom-up-with-guardrails: have teams and individuals draft their own OKRs in line with higher goals, then discuss with managers for cohesion. Do not let it become chaotic — alignment is the primary goal of the process.
5. 5Decide the unit of ownership per area: unfold OKRs to individuals in sales (results are individual and measurable); keep OKRs at the team level for multidisciplinary product/engineering teams where no single person owns the outcome.
6. 6Distinguish results (OKRs) from efforts (Projects/Action Plans) as you go down the chart. Lower-level employees are usually accountable for executing Projects that serve a manager's OKR, not for owning OKRs themselves.
7. 7Scan for teams grossly out of alignment and the few major initiatives that touch everyone; manage those directly rather than force-cascading every goal up and down.
8. 8In Results Meetings each cycle, have each direct report present their OKRs and Projects so drift toward the wrong trade-off (e.g., margin over growth) gets caught early.

A manager in accounts payable, under the CFO's organization, translates the finance strategy into her own OKRs rather than waiting for orders. She sets one OKR to reduce errors in invoices paid and received, and another to reduce days-receivable or extend days-payable. Because these are results, she then unfolds Projects to her team that they believe will hit the goals: implementing a major new piece of software and reengineering the accounts-payable approval process. Her OKRs are public, so peers can see how her days-payable target interacts with their cash-flow work and flag any conflict. Her team is measured on executing the Projects, while she is accountable for the OKR outcomes. This keeps her unit rowing with the CFO's direction instead of optimizing something the strategy never asked for.

• If a role's results are individually owned and easy to measure (e.g., a salesperson's sales numbers), then unfold OKRs down to the individual.
• If work is multidisciplinary and no single person owns the outcome (product teams of engineers, designers, PMs), then keep the OKR at the team level and don't split it into individual OKRs.
• If a person is high on the org chart, expect individual OKRs; the farther down, the more likely they own Projects (efforts) rather than OKRs (results).
• If cascading goals up and down would take excessive time to line everyone up, then use a market-based approach: publish top OKRs, keep all OKRs visible, and directly manage only the few out-of-alignment teams and cross-cutting initiatives.
• If a proposed team OKR conflicts with or duplicates another's, then resolve it in the alignment discussion before the cycle starts — transparency exists to surface exactly this.

• Company priorities are set but never communicated: six months in, operations chases margins, others chase disruptive tech, corp dev hunts M&A — all power lost to unclear priorities. Tell: teams pursuing different 'top priorities' with no shared Objective.
• Confusing efforts with results — writing Projects (implement software, reengineer a process) as OKRs. Tell: 'OKRs' that describe activities rather than measurable business outcomes.
• Forcing individual OKRs onto multidisciplinary teams. Tell: arguments over who 'owns' a shared outcome (the engineers? designers? PMs?) and demotivated members.
• Treating bottom-up as license for chaos — people setting goals however they want and picking projects without reasoning. Tell: OKRs that don't ladder up to any higher goal.
• Over-engineering the cascade — spending hours aligning every goal top-to-bottom. Tell: the process consumes more effort than it returns, and goals still don't line up perfectly.

• ▸Company Objective + Key Results: the CEO/board strategy reduced to 1+ O-KR pairs
• ▸Level: mark whether this OKR sits at company / VP / director / squad / individual
• ▸Aligns upward to: name the higher OKR this one supports
• ▸Owner type: OKR-owner (result) or Project-owner (effort) — pick one
• ▸My Key Results: SMART, KPI-based, and proof the Objective was hit
• ▸Projects/Action Plans: the efforts you'll run to try the hypothesis (not OKRs)
• ▸Visibility: public by default — note here only if confidential and why
• ▸Dependencies/conflicts: list other teams' OKRs this touches, and resolution
• ▸Results-meeting check: what metric you'll report each cadence to confirm you're still rowing in the same direction

1. 1Run Results Meetings on a fixed cadence: each direct report presents only OKRs/Projects that are off-track (red), why they're off-track, and which actions are already under way to recover them. Skip on-track items unless time is spare.
2. 2Apply Falconi's two-by-two matrix to every off-track OKR: cross 'action plan executed / not executed' with 'OKR achieved / not achieved' to separate results earned 'on purpose' from those that came 'by chance.'
3. 3For Quadrant 1 (plan executed but OKR off-track), treat the underlying hypothesis as falsified: find out why the plan was wrong and adjust it, don't just work the plan harder.
4. 4For Quadrant 2 (plan not executed but OKR on-track), investigate which factors you failed to account for that produced the result anyway, and separately why the plan wasn't executed and whether exogenous factors could have been neutralized with alternate actions.
5. 5At debriefing, finalize OKRs by inputting last KPI data, then have each person answer four questions per OKR: Were results achieved (yes/no)? What went right/wrong? Why? What have I learned that I'll carry forward?
6. 6Capture learnings in a fixed artifact — a form in the performance app or a couple of slides — so reflection is honest, comparable, and preserved for the next cycle.
7. 7Protect the culture: never condemn or humiliate someone for a failed hypothesis in public; treat broken commitments (action plans not followed through) as a separate behavioral issue handled offline.

A company sets an OKR to grow revenue 25% in a quarter. Its hypothesis: at recent conversion rates, it needs 100% more leads, so it unfolds a 'generate 15,000 more inbound leads quarter-on-quarter' Key Result to marketing, with an action plan of three e-books and ten webinars. Suppose at the Results Meeting the plan is fully executed and leads do hit 15,000, but revenue stays flat — a Quadrant 1 outcome. The learning is that the hypothesis 'more leads produces more sales' was wrong; conversion, not volume, was the constraint, so the plan is adjusted toward improving the sales process where breakage occurs. Had revenue grown while the webinars were never released (Quadrant 2), the team would instead dig into what unmodeled factor lifted revenue and why the plan lapsed. Either way the debrief records what was learned so the next cycle's hypotheses start smarter.

• If the plan was executed but the OKR missed, then the hypothesis is falsified — revise the plan, don't blame the executor.
• If the OKR hit but the plan wasn't executed, then treat it as luck to be explained — identify the unmodeled factor before repeating.
• If someone presents a failed hypothesis honestly, then treat it as productive; if someone broke a commitment they made, then address it offline as a behavioral issue.
• If it's your first cycles with OKRs and history on the KPI is thin, then set conservative, non-stretch targets so people actually hit them and don't abandon the method.
• If time in a Results Meeting is limited, then discuss only red items; only cover on-track OKRs when there's spare time.

• Scolding people publicly for missed OKRs — the tell is that presenters start hiding red items or sandbagging targets, and meetings stop surfacing real problems.
• Confusing a wrong hypothesis with poor performance — the tell is teams repeating the same executed-but-failing plan instead of asking why the reasoning was wrong.
• Celebrating a Quadrant 2 hit without investigation — the tell is a result 'by chance' credited as skill, so the unaccounted factor is never understood and can't be repeated.
• Skipping honest debriefing (blank or self-congratulatory reflections) — the tell is the four learning questions answered vaguely, so nothing carries into the next cycle.
• Opening with moonshots when the team doesn't know its KPI baselines — the tell is no one hits anything, OKRs get a terrible first impression, and people quietly abandon them.

• ▸OKR / Key Result: state the result being reviewed
• ▸Result achieved? (yes/no): final KPI vs target
• ▸Plan executed? (yes/no): were the committed action plans carried out
• ▸Falconi quadrant: on purpose / by chance / wrong hypothesis / not executed
• ▸What went right / wrong: the specific facts, not opinions
• ▸Why did it go right or wrong: root cause, including any exogenous factor
• ▸Hypothesis verdict: confirmed, falsified, or partially — what to change
• ▸Learning to carry forward: one thing you and the company take into next cycle

1. 1Audit your stated values: if some variation of 'results orientation' sits in your corporate competencies, force the definition — a results-oriented professional clearly knows the difference between an effort and a result. Make people prove they can tell them apart.
2. 2For each team, list its recurring activities and classify each as effort or result relative to that team's ownership. Attending sales meetings, implementing an ERP, building a cart feature are efforts; closing sales, reducing accounting errors, increasing conversion rate are the paired results.
3. 3Write Objectives (qualitative business results) and pair each with S.M.A.R.T. Key Results built as proof. Use the test: if all Key Results hit, you must feel comfortable the Objective was reached; if not, your Key Results were wrong.
4. 4Break the compensation link. Keep OKRs as a management tool, not a pay-for-performance formula, so people stop politically negotiating easy goals and can support aggressive roof-shots/moonshots.
5. 5Make OKRs public by default; confidential ones (M&A, downsizing) are the exception. Transparency is what strips out subjectivity and politics.
6. 6Install the cadence, not just the definitions: run monthly-then-quarterly Results Meetings where leaders review OKRs and Projects with direct reports. Monitoring is where results orientation actually forms as a habit.
7. 7Deploy CEO/company OKRs downward so everyone 'rows in the same direction,' but cap each entity at three Objectives (never more than the fingers on one hand) so priorities are remembered and acted on.

A product team owns only the e-commerce shopping cart, so its Objective is 'improve shopping cart conversion rates' and its Key Result is 'improve the conversion rate between adding items to the cart and making a purchase from 3% to 5%.' Notice the effort/result discipline: building the new cart feature is an effort — increasing the conversion rate is the result, and only the result becomes the Key Result. Because the relationship is relative, this same team's 'faster page' improvement would be an effort feeding the conversion result. Contrast this with an accounts-payable manager under the CFO, whose OKRs are 'reduce errors in invoices paid and received' and 'reduce days-receivable / extend days-payable' — the results — while implementing new software and reengineering the approval process are Projects (efforts) unfolded to her team. As people repeatedly see which of their efforts actually produced results, they build a culture of fewer politics, less subjectivity, and more results orientation.

• If all Key Results are achieved but the Objective still feels unmet, then your Key Results were wrong from the start — rewrite them as better proof.
• If an item can be started and finished by working harder or longer (attend meetings, ship a feature, install an ERP), then it's an effort/Project — do not put it in a Key Result, which must be a result.
• If the role has individual, easily measured output (a salesperson's numbers), then unfold OKRs to the individual; if it's a multi-disciplinary product team where credit can't be cleanly split, then keep OKRs at the team level.
• If goal attainment starts feeding directly into bonuses, then expect political negotiation of easy goals — break the link to keep aggressive goals safe.
• If any single entity has more than three (max five) Objectives, then cut — beyond a hand's worth of fingers they won't be remembered.

• Listing 'results orientation' as a value without defining it. Tell: teams celebrate activity — meetings held, features shipped — instead of movement on a metric.
• Confusing efforts with results in the OKR itself, e.g., a Key Result like 'implement ERP system.' Tell: the OKR can be marked done even though nothing measurable improved.
• Wiring goals into compensation. Tell: managers and reports front-load tension negotiating easy targets, and behavior/'culture fit' ratings get bumped to compensate poor attainment — subjectivity and politics return.
• Trying too much at once — unfolding five company OKRs to individuals in an annual cycle. Tell: people don't remember or monitor their OKRs and the rollout collapses.
• Defining OKRs but skipping the rituals. Tell: no cadenced Results Meetings, so OKRs are set once and never revisited — 'the rubber never meets the road.'

• ▸Team / owner: name the entity that owns this outcome (result must be relative to them)
• ▸Effort being confused for a result: write the activity people currently track (meeting, feature, install)
• ▸Actual result it should produce: state the measurable business outcome that effort serves
• ▸Objective (qualitative): 'We will _____' — the business result in plain terms
• ▸Key Results (S.M.A.R.T., 1-3): '...and we'll know we succeeded if we can _____' — specific, from-X-to-Y metrics that prove the Objective
• ▸Proof check: if all KRs hit, is the Objective clearly reached? (yes/no — if no, revise KRs)
• ▸Objective count check: does this owner have 3 or fewer Objectives total? (yes/no)
• ▸Compensation link: confirm this OKR is NOT tied to a bonus formula (checkbox)
• ▸Cadence: cycle length (start 1 month, then 3) and Results Meeting owner/date

1. 1Separate efforts from results before writing any OKR: name the deliverable (attend meetings, build a feature, implement an ERP) then ask what result it produces (close sales, raise conversion, reduce errors). The Objective must be the result, not the effort.
2. 2Write each Objective qualitatively as the business result you need, then attach 2-4 Key Results that are SMART and act as proof. Test with: 'if all Key Results are hit, am I comfortable the Objective is achieved?' If not, your Key Results are wrong.
3. 3Set difficulty in the productive zone: hard enough that the team must learn and grow to reach it, but with a reasonable chance of achievement. Since OKRs are decoupled from compensation, push toward roof-shots and moonshots.
4. 4Choose a deployment model to match your workforce: decentralized/bottom-up for creative teams to gain speed and engagement; centralized/top-down for stable, low-tech, blue-collar operations to gain precision. Share board results in an all-hands so bottom-up OKRs have the context to align.
5. 5Run short-cycle monitoring via Results Meetings that cross-check two axes: was the action plan executed, and is the OKR on-track. Place every OKR into one of four quadrants and respond by quadrant.
6. 6In debriefing, grade each OKR and reflect even when on-track: determine whether the result came from the action plan or from exogenous factors you failed to foresee, using Five Whys to reach root cause.
7. 7Assign each Objective relative to who owns it: a team owning only the shopping cart gets a cart-conversion Objective, not a company-wide revenue Objective, so contributions actually add up.

Take the shopping-cart product team. 'Building a new feature for the e-commerce shopping cart' is an effort; the result is increasing the conversion rate. So the Objective becomes 'improve shopping cart conversion rates' and the Key Result becomes 'improve the conversion rate between adding items to the shopping cart and making a purchase from 3% to 5%.' Contrast this with Grove's Intel example, where a goal to 'Dominate the mid-range microcomputer component business' was followed by a Key Result to 'win new designs for the 8085' — note that this Key Result reads like an effort or milestone in an action plan, not a measurable result. The passages flag this as the recurring flaw: Grove stressed measurability but his examples resemble deliverables. The stronger cart OKR passes the proof test — hit 3%-to-5% and you're comfortable conversion actually improved — while the 8085 wording proves activity, not outcome.

• If hitting all Key Results still leaves you unsure the Objective was reached, then the Key Results were mis-specified — rewrite them before the cycle starts.
• If a stated 'result' is really a step or deliverable in an action plan (like 'win new designs for the 8085'), then it's an effort — demote it to the plan and find the true measurable result.
• If actions were executed but the OKR is off-track (Quadrant 1), then the hypothesis behind the plan was wrong — fix the plan, not the effort level.
• If the OKR is on-track but the plan wasn't executed (Quadrant 2), then investigate what unplanned factor carried it and whether the missed execution is a behavioral issue to address one-on-one.
• If your workforce is mostly smart creatives, then decentralize goal-setting; if it's stable low-tech manufacturing, then centralize it.

• Treating OKRs as a high-level task list — the tell: Key Results read as to-dos and milestones rather than measurable results, exactly the misuse found among Google employees interviewed.
• Copying simplistic examples like 'Eat 5 Pies' from surface-level sources (re:Work) — the tell: Objectives that are cute or arbitrary and don't map to a business, customer, or employee result.
• Setting the wrong difficulty — the tell: too-easy goals produce coasting and too-hard goals cause large negative discrepancies where people withdraw effort and perceive low likelihood of success.
• Over-decentralizing without shared context — the tell: summing everyone's bottom-up OKRs doesn't add up to corporate strategy, and grossly misaligned teams appear.
• Celebrating on-track OKRs without diagnosis (Quadrant 3) — the tell: no one can say whether the win came from the plan or from unforeseen exogenous factors, so it isn't repeatable.

• ▸Objective (qualitative result, owned by this team): state the business result you must achieve
• ▸Effort-vs-result check: name the effort and confirm the Objective is the result, not the effort
• ▸Key Results (2-4, SMART): list measurable KRs that prove the Objective
• ▸Proof test (yes/no): if all KRs hit, are you comfortable the Objective is reached?
• ▸Difficulty setting: roof-shot / moonshot — confirm it requires learning yet is achievable
• ▸Deployment mode: centralized or decentralized, justified by workforce type
• ▸Quadrant at review: (1) plan done/off-track (2) plan missed/on-track (3) plan done/on-track (4) plan missed/off-track
• ▸Five Whys root cause: ask why until you reach the underlying cause of the gap
• ▸Result vs exogenous factor: was progress caused by the plan or by unforeseen external factors?

1. 1Remove the formula. Delete any rule that converts goal-attainment percentage into a bonus multiplier (e.g., 'hit 65% → 3 months' salary, hit 90% → 6 months'). Announce explicitly that OKR grades no longer feed pay.
2. 2Reframe OKRs as a management tool: state in writing that objectives exist to focus effort and coordinate teams, not to compute compensation. Keep the grading scale (0.0–1.0) as a learning signal, not a payout trigger.
3. 3Shift compensation to manager discretion grounded in evidence. Base bonuses and advancement on the actual results achieved (the numerator) plus deep discussions about context, difficulty, and behaviors — not a mathematical average of goal percentages.
4. 4Set OKRs bottom-up and top-down together, and make them public by default. Because pay is detangled, employees have no incentive to sandbag, so encourage aggressive roof-shots and moonshots where the target sits above current capacity.
5. 5Run short cycles (1–6 months, commonly 3) and allow goals to change mid-cycle. Without pay attached, you drop the strict 'no changing goals' rules that annual pay-linked systems require.
6. 6Preserve meritocracy deliberately. Direct scarce resources — money, opportunities, challenges — to great performers through calibrated discussion, so detangling pay from grades does not become detangling reward from performance.
7. 7Separate the axes. Assess results, behaviors/values, and compensation as distinct conversations rather than folding everything into one stack-ranked goal score.

Contrast the two systems the passages describe. In a Fortune 500 setup, an employee who reaches 65% of a weighted goal average earns 3 monthly salaries and one who reaches 90% earns 6 — so both employee and manager front-load pressure and politically negotiate the easiest possible targets before the year even starts. Detangle it: a product team owns the Objective 'improve shopping cart conversion rates' with the Key Result 'improve conversion between adding items and purchase from 3% to 5%.' Because grading that KR no longer sets a bonus, the team can commit to the aggressive 5% roof-shot instead of quietly promising 3.2%. At debrief they hit 4.3% (a 0.65 grade); the manager rewards them well because moving the real number from 3% to 4.3% is a strong result achieved against a hard goal. The same manager might pay less to a peer who scored 0.9 on a trivially easy goal. The Wells Fargo failure — executives opening fake accounts to hit product goals tied to pay — is the outcome you avoid by breaking the link.

• If a goal's grade mechanically determines a payout, then you have not detangled — remove the formula before calling it OKRs.
• If employees are negotiating targets downward before the cycle, then compensation is still linked (sandbagging tell); decouple pay and reset targets to roof-shots.
• If a goal creates incentive to hit a number by unethical means, then the metric is tied to pay too tightly — separate the two, as the Wells Fargo case shows.
• If a bonus decision can't be explained without citing meaningful discussion of actual results, then you've drifted back to a formula and lost the manager-discretion basis.
• If salespeople are involved, then accept more top-down, budget-based goals — Google keeps sales goals set that way even while other teams run OKRs loosely.

• Rebranding old MBOs as OKRs while keeping the pay-for-performance formula — the tell is a table mapping goal percentage to salary multiples still living in the comp policy.
• Detangling pay but keeping annual cycles and mid-year change-freezes; the tell is goals treated as 'mandatory pain' filled in just before performance reviews.
• Interpreting 'not linked to pay' as 'not meritocratic' — the tell is uniform rewards and no one steering scarce resources toward great performers.
• Grading percentage of completion as if it were the point; the tell is celebrating a 100% score on an easy goal over a 0.65 on a bold one — the actual numerator moved less.
• Folding results, behaviors, and calibration into one stack-ranked score (e.g., forcing 20/70/10 distributions); the tell is ratings 'massaged' to fit a curve rather than reflecting real results.

• ▸Objective + Key Results: state the OKR being reviewed in the 'we will ___, we'll know if ___' form.
• ▸Pay linkage today: describe any formula converting grade → bonus (write 'none' if detangled).
• ▸Sandbagging check: is the target a roof-shot above current capacity, or negotiated-easy? Note evidence.
• ▸Result vs. effort: name the numerator (actual result achieved) separate from the % completion.
• ▸Ethical risk: could hitting this metric reward gaming the number? Describe the exposure.
• ▸Cycle length + change rule: 1–6 months? Are mid-cycle changes allowed?
• ▸Reward basis: how will bonus/advancement be decided — discretion + discussion, or formula?
• ▸Meritocracy allocation: who gets the scarce resources (money, opportunities, challenges) and why?
• ▸Axis separation: are results, behaviors, and comp handled as distinct conversations? Yes/No + gap.

1. 1Make OKRs public by default: publish the great majority of individual and team OKRs in a place anyone in the company can consult, and treat privacy as the exception, not the rule.
2. 2Define the exception list explicitly before publishing — confidential OKRs cover mergers and acquisitions, cost reduction plans that may imply layoffs, and downsizing. Everything else is open.
3. 3Publish the alignment chain visibly so dependencies are traceable: company OKRs, then VPs' OKRs aligned to the company, directors aligned to VPs, squads aligned to business units and to each other. Visibility across this chain is what lets teams see who they depend on.
4. 4Use a market-based approach rather than exhaustive cascading: because top OKRs are known and everyone else's are visible, goals converge over time. Teams that are grossly out of alignment stand out on their own — you don't need to force-line-up every goal.
5. 5During planning, have each person set their OKRs bottom-up in line with higher goals, then discuss with their manager for cohesion — and cross-check against the visible OKRs of teams they depend on to surface conflicts before the cycle starts.
6. 6In Results Meetings, use transparency operationally: because everyone can see everyone's panel, a dependency that's off-track can be traced to its source and the responsible parties discussed in the same room.
7. 7Protect transparency with culture: publicly visible off-track OKRs must never become grounds for humiliation. The goal is solving problems, not scolding people in front of peers.

Laszlo Bock describes how Google uses transparency in place of heavy cascading: 'We have a market-based approach, where over time our goals converge, because the top OKRs are known and everyone else's OKRs are visible. Teams that are grossly out of alignment stand out, and the few major initiatives that touch everyone are easy enough to manage directly.' The mechanism is that spending hours cascading goals up and down does not improve performance — it takes too much time and it's too hard to make all goals line up. Instead, publishing the top OKRs and keeping everyone's OKRs visible lets teams self-correct: misalignment becomes conspicuous rather than hidden. A product squad whose OKR conflicts with an engineering squad's dependency can see it directly and resolve it, without a strategic planning team mediating. This is transparency doing the alignment work that formal cascading would otherwise attempt slowly and imperfectly.

• If an OKR touches mergers, acquisitions, layoffs, or cost reduction that may imply layoffs, then keep it private; otherwise publish it by default.
• If two teams' visible OKRs create a dependency or conflict, then surface and resolve it promptly in discussion rather than discovering it mid-cycle.
• If a team's OKRs are grossly out of alignment with the visible top OKRs, then it will stand out on its own — manage those exceptions directly instead of cascading every goal.
• If a major initiative touches everyone, then manage it directly rather than relying only on convergence through visibility.
• If someone's publicly visible OKR is off-track because they formed a hypothesis that didn't work, then treat it as constructive; only broken commitments (unexecuted action plans) get handled offline as a behavioral issue.

• Treating transparency as optional or making most OKRs private — the tell is that the exception (confidential OKRs) has become the rule, so dependencies stay hidden and conflicts surface late.
• Trying to replace transparency with exhaustive cascading — the tell is teams spending hours lining up goals up and down the org, which takes too much time and still doesn't make them align.
• Publishing OKRs but weaponizing the visibility — the tell is people being condemned or humiliated in public for off-track OKRs, which kills the honesty transparency depends on.
• Publishing OKRs without a discussion mechanism — the tell is that visible conflicts and dependencies are seen but never 'promptly identified, discussed, and resolved,' so visibility yields no alignment.
• Assuming visibility alone guarantees alignment for everything — the tell is that a few major cross-cutting initiatives drift because no one manages them directly, expecting convergence to handle them.

• ▸OKR owner (individual or team): who owns this objective
• ▸Objective (qualitative): the business result to be achieved
• ▸Key Results (S.M.A.R.T.): measurable proof the objective was reached
• ▸Public or confidential: default public; mark confidential only if merger/acquisition/layoff-related
• ▸Aligned upward to: which higher OKR (company/VP/director/business unit) this rolls up to
• ▸Depends on (visible OKRs): other teams' published OKRs this relies on
• ▸Conflicts flagged: any visible OKR that conflicts, plus resolution owner
• ▸Discussion status: identified / discussed / resolved — with date

1. 1Establish the four nested cadences in order: mission/vision (no expiration), strategic OKRs (3 to 10 years), annual OKRs (parallel to fiscal/budget cycle), and short-cycle OKRs (1 to 6 months). Each nests inside the next like Russian dolls.
2. 2Don't stall on the outer dolls. If you lack a settled mission, vision, or strategy, run a few short cycles first and discuss the outer layers later — 'if you don't know where you're going, anywhere will do,' but eventually set them.
3. 3Pick a short-cycle length matched to business and practice maturity: start at one month for a first-time team, move toward quarterly, and treat 6 months as the maximum you can afford in a competitive market. Almost no company should run annual-only.
4. 4Align through time before aligning across the org: strategic OKRs derive from mission/vision, annual OKRs derive from strategic, and short-cycle OKRs derive from annual. Within a single cycle, teams then align to each other.
5. 5At each short-cycle boundary, run the full loop — set, monitor, debrief/grade, then start a new cycle — so course-correction happens every 1 to 6 months instead of at a mid-year review.
6. 6Warm the engines gradually: begin with one company-wide Objective and three or four Key Results in a one-month cycle, learn, repeat, then after ~three months unfold OKRs loosely to teams. Move from shorter cycles toward longer ones, not the reverse.
7. 7If annual OKRs suffice for your business, collapse the annual and short cycle into one — apply everything meant for the short cycle to the annual cycle — but the passages advise almost every company keep at least a 6-month short cycle.

A product team owns the shopping cart feature. Inside a quarterly short cycle nested within the annual cycle, they set Objective 'improve shopping cart conversion rates' with Key Result 'improve the conversion rate between adding items to the shopping cart and making a purchase from 3% to 5%.' Because the cycle is three months, not twelve, they monitor progress in results meetings and can course-correct on the feature well before year-end. At the quarter's close they debrief: did they hit it, what went right or wrong, and why. That short cadence sits nested inside the annual OKRs, which sit inside the strategic OKRs (3 to 10 years), which sit inside the company's mission and vision. Google models this at the org level: senior management presents a debriefing of organizational OKRs every quarter in an all-hands meeting following the board meeting.

• If your market is fast-paced and competitive, then never run annual-only — install at least a 6-month short cycle within the fiscal year.
• If a team is new to OKRs, then start with a one-month cycle and one Objective; only lengthen the cycle and add OKRs after the habit takes hold.
• If mission, vision, and strategy aren't yet defined, then run short cycles now and set the outer cadences later — don't block on getting them all at once.
• If annual OKRs already cover the company's needs, then treat the annual cycle as the short cycle and skip the separate short-cycle step.
• If an Objective spans years, then it belongs in the strategic cadence, not the short cycle — short-cycle OKRs must be completable before the cycle ends.

• Going from longer to shorter or too much at once — e.g., unfolding five company OKRs to the individual level in an annual cycle. Tell: people don't know what's going on, can't remember their OKRs, and teams stop monitoring.
• Keeping annual-only cadence in a competitive market. Tell: only a fiscal-year cycle plus a pro-forma mid-year review exists, and course-correction always arrives too late.
• Setting too many OKRs per short cycle, defeating the narrower focus the shorter cadence allows. Tell: the entity's Objectives balloon past the focus limit and priorities blur.
• Never establishing the outer dolls at all. Tell: short cycles run indefinitely with no strategic, annual, or mission anchor — 'anywhere will do' becomes permanent.
• Treating short-cycle OKRs like traditional annual goals with rigid change rules. Tell: OKRs go untouched between cycles because revising is 'frowned upon,' killing the responsiveness the cadence exists to provide.

• ▸Mission/Vision: state the no-expiration direction the company rows toward.
• ▸Strategic OKR horizon: pick 3 to 10 years and name the strategic Objective it aligns to.
• ▸Annual OKR: write the fiscal-year Objective derived from the strategic OKR.
• ▸Short-cycle length: choose 1, 3, 4, or 6 months based on team/practice maturity.
• ▸Short-cycle Objective + KRs: one Objective, three or four measurable Key Results completable within the cycle.
• ▸Time-alignment check: confirm this OKR derives from the annual, which derives from strategic, which derives from mission.
• ▸Cross-org alignment check: list dependencies/conflicts with other teams' OKRs to resolve (public by default).
• ▸Loop dates: set the set / monitor (results meeting) / debrief-grade dates for this cycle boundary.
• ▸Gradual-rollout stage: mark current step (company-only → teams → individuals; monthly → quarterly).

1. 1Set higher-level goals first: define company and team OKRs so individuals have a reference point to align to before they draft their own. Alignment is the primary goal of the process, so this scaffolding comes first.
2. 2Ask employees to draft their own OKRs in line with those higher goals — do not have a strategic planning or business-intelligence team deploy them top-down in a rigid, formal way. The drafting responsibility sits with the person or team who owns the results.
3. 3Calibrate each draft with the manager for cohesion and alignment, following Grove's two-way pattern: individuals define goals according to company goals, then calibrate with their manager. This is where bottom-up commitment meets top-down precision.
4. 4Keep OKRs public by default so alignment happens by visibility rather than by exhaustive cascading — teams grossly out of alignment stand out, and the few major initiatives touching everyone can be managed directly.
5. 5Reserve top-down setting for the roles where it fits: strategic objectives that must be deployed across executives and business units, and functions like sales whose goals are set to budget.
6. 6Guard against chaos: a bottom-up process does not mean people pick projects or set goals however they want. Enforce that OKRs track results owned by the person or team, not vague efforts.
7. 7Break the link between OKR attainment and variable compensation so employees draft honest, ambitious goals rather than politically negotiating easy ones.

Google runs a deliberately loose, market-based version of this balance. Salespeople get goals set more top-down and according to budget, while product and engineering teams are largely free to use OKRs or not, with varying homogeneity. Laszlo Bock explains why: 'Having goals improves performance. Spending hours cascading goals up and down the organization, however, does not.' Instead, Google lets goals converge over time because the top OKRs are known and everyone else's OKRs are visible. Teams grossly out of alignment stand out, and the few major initiatives that touch everyone are easy enough to manage directly. The result is bottom-up participation held in alignment by transparency rather than by a rigid formal cascade.

• If a goal is strategic and must be deployed across multiple executives or business units, then set it top-down; if it belongs to one team's own results, then let that team draft it bottom-up and calibrate with the manager.
• If the function is sales (or otherwise budget-driven), then set goals more top-down; if it is product or engineering, then favor self-set OKRs.
• If cascading goals up and down is eating hours and alignment is still hard to verify, then switch to a market-based approach: make top OKRs known, keep all OKRs public, and manage only the out-of-alignment teams directly.
• If an employee sets a goal unrelated to any higher team or company goal, then reject it in calibration — bottom-up does not license picking projects without reasoning.
• If goal attainment feeds compensation, then expect gaming and de-link it before pushing for honest bottom-up goals.

• Deploying goals top-down in a formal, rigid way via a planning or BI team — the tell is employees who had no say and feel no commitment to goals set for them.
• Treating bottom-up as license for chaos — the tell is unsynchronized, conflicting team goals where people are not rowing in the same direction.
• Over-cascading in pursuit of precision — the tell is hours spent lining goals up and down the org and still no confidence they align (Bock's warning).
• Letting individuals set goals however they want or pick projects without reasoning — the tell is OKRs that track efforts/deliverables instead of results owned by that person or team.
• Keeping OKRs tied to bonuses while asking for participation — the tell is front-loaded tension and politically negotiated easy goals.

• ▸Owner (person/team): who is accountable for these results
• ▸Higher goal this aligns to: the team or company OKR it supports
• ▸Origin mode: mark top-down (strategic/sales/budget) or bottom-up (self-drafted)
• ▸Draft Objective: written by the owner, in the owner's own words
• ▸Key Result(s): measurable result of the owner's efforts (not a deliverable/effort)
• ▸Alignment check: does this visibly support the higher goal? conflicts/dependencies noted
• ▸Manager calibration notes: adjustments made for cohesion and alignment
• ▸Visibility: public by default — mark private only if merger/layoff/confidential
• ▸Compensation link: confirm no direct tie to bonus

1. 1Start conservative in your first cycles: set OKRs at levels that aren't a big stretch, so that people actually hit them and OKRs earn a good first impression rather than a tarnished one.
2. 2Track your organization-wide attainment rate across cycles. Treat 70-80% as the maturity threshold that signals people are ready to be stretched further.
3. 3Once you consistently reach 70-80% of targets, grant the freedom to set exactly one stretch OKR per cycle per team — never more than one, so the aggressive goal doesn't crowd out believable ones.
4. 4Calibrate each stretch goal to the '80% you know how to beat' standard: the owner should already know roughly how to hit 80% of it, with the remaining 20% to be learned by working toward it.
5. 5Set difficulty in a two-way process (top-down and bottom-up): let the individual contributor draft goals aligned to company OKRs, then calibrate difficulty with their manager so both commitment and realism are present.
6. 6Screen against 'too easy': if a goal requires no learning or growth from the owner, raise it — very low goals get achieved but then motivation and energy fall precipitously.
7. 7Keep OKRs decoupled from compensation. Because they're a management tool rather than a pay tool, people can support aggressive goals instead of politically negotiating easy ones to protect bonuses.
8. 8At debriefing, capture what course of action produced the result, so next cycle's difficulty setting is informed by what actually worked, not just by the score.

Carlos Britto, CEO of AB InBev, describes the ideal goal as one 'you know 80% how to beat. The other 20% will be learned along the way.' Apply this to a company just adopting OKRs: for the first few cycles you set a believable target — say a modest, non-stretch revenue or quality improvement — and you hit it, building the habit and credibility. After the whole company is consistently reaching 70-80% of its targets, you let each team add a single stretch OKR. A sales team then sets that stretch goal so they already know how to deliver 80% of it, with the final 20% demanding new learning. This sits deliberately between two failure zones: a moonshot no one believes (which frustrates people because they must believe they can achieve it) and a trivially easy goal (which Locke shows kills motivation and gets narrowly missed anyway).

• If you're in your first few OKR cycles, then set conservative, non-stretch goals — protect the methodology's first impression before you push difficulty.
• If organization-wide attainment sits at 70-80%, then allow one stretch OKR per team per cycle — but not more than one.
• If the owner cannot describe how they'd reach at least 80% of the goal, then it's too hard — lower it until it's believable.
• If a goal requires no learning or growth from its owner, then it's too easy — raise it above their current capacity.
• If goal attainment is being fed into compensation, then expect people to negotiate easy goals — decouple OKRs from pay before trying to calibrate difficulty honestly.

• Launching with moonshots so no one achieves their OKRs — the tell is people concluding that missing OKRs is 'the rule,' or abandoning them entirely.
• Setting goals so easy they need no effort — the tell is targets hit early, then motivation and energy falling precipitously with goals narrowly missed as people minimize energy expenditure.
• Allowing multiple stretch OKRs per cycle before maturity — the tell is aggressive goals crowding out the believable ones and attainment never stabilizing near 70-80%.
• Linking attainment directly to bonuses — the tell is employees and managers politically negotiating easy goals to front-load safe payouts.
• Setting difficulty purely top-down — the tell is low commitment because owners never calibrated the goal with their manager or believed in it.

• ▸Cycle maturity: are we in early cycles (set conservative) or past the 70-80% threshold (allow stretch)?
• ▸Current org-wide attainment rate: enter latest cycle % against targets.
• ▸Goal statement: write the OKR being calibrated.
• ▸80% path: describe how the owner already knows to reach 80% of it.
• ▸20% learning: name what must be learned along the way for the last 20%.
• ▸Believability check: does the owner believe this is achievable? (yes/no)
• ▸Effort check: does this require learning/growth beyond current capacity? (yes/no)
• ▸Stretch count: is this the team's only stretch OKR this cycle? (yes/no)
• ▸Compensation link: is attainment tied to pay? (if yes, decouple before finalizing)