Avoiding Common OKR Mistakes and Anti-Patterns
This skill teaches you to recognize and prevent the most damaging OKR pitfalls, including sandbagging goals, confusing outputs with outcomes, overloading teams with too many objectives, and creating perverse incentives by linking OKR scores to compensation.
Start by auditing your OKRs against a checklist of known anti-patterns: sandbagging (setting goals you already know you can hit), writing tasks as key results instead of measurable outcomes, setting more than 3-5 OKRs per team, and tying OKR scores directly to compensation or performance reviews. For each anti-pattern found, apply the specific correction before finalizing your OKRs for the cycle.
Outcome: Your OKRs consistently drive ambitious, measurable outcomes instead of devolving into task lists, sandbags, or bureaucratic compliance exercises that waste organizational energy.
Prerequisites
- Familiarity with the OKR framework structure (Objectives paired with Key Results)
- Experience writing or reviewing at least one cycle of OKRs
- Understanding of the 0.0-1.0 OKR scoring scale and what a target score of 0.7 means
- Basic knowledge of how OKRs cascade or align across teams
Overview
Most OKR implementations fail not because the framework is flawed, but because teams make a predictable set of mistakes that quietly undermine the system from the inside. These anti-patterns are so common that experienced OKR coaches can spot them within seconds of reading a draft set of objectives and key results. The problem is that each mistake feels reasonable in isolation. Writing "Launch the new onboarding flow" as a key result feels productive. Setting 8 OKRs feels thorough. Tying OKR scores to bonuses feels like it will increase accountability. In practice, each of these choices creates a specific failure mode that compounds over time, eventually causing teams to view the entire Objectives and Key Results (OKRs) framework as bureaucratic overhead rather than a genuine tool for focus and alignment.
This skill gives you a structured diagnostic process for catching these anti-patterns before they take root. Rather than a vague warning to "set better OKRs," you will learn to audit draft OKRs against a concrete checklist of known failure modes, understand why each anti-pattern is destructive, and apply a specific correction for each one. The artifact you produce is a reviewed, corrected set of OKRs along with a written record of which anti-patterns were detected and how they were resolved. This record becomes increasingly valuable over multiple cycles because it reveals your organization's habitual failure modes.
The skill sits at a critical juncture in the OKR workflow. It should be applied after writing effective objectives and defining measurable key results but before the OKRs are finalized and shared during OKR planning sessions. Think of it as a quality gate: every set of OKRs passes through this diagnostic step before being committed to. Teams that skip this step tend to discover their mistakes only at the end-of-cycle scoring and grading review, when it is too late to recover the quarter.
Success looks like a team that can self-diagnose. After two or three cycles of structured anti-pattern auditing, team members begin catching mistakes in real time during drafting rather than needing a formal review pass. The checklist becomes internalized, and the time spent on audits drops significantly while OKR quality keeps climbing.
How It Works
The core mental model behind this skill is pattern recognition applied to goal quality. OKR anti-patterns are not random errors. They cluster into four categories, each driven by a different underlying cause. Understanding these categories lets you diagnose new mistakes you have never seen before, not just the ones on a static checklist.
Category 1: Ambition Failures. These include sandbagging (setting goals you are already on track to hit), anchoring to last quarter's performance, and negotiating OKRs downward during review. The root cause is that people optimize for looking successful rather than for organizational learning. When OKR scores feel like performance ratings, the rational response is to set easy targets. The fix is structural: decouple OKR scores from individual performance evaluations entirely, and celebrate learning from ambitious misses as much as hitting targets.
Category 2: Measurement Failures. These include writing tasks or activities as key results ("Launch feature X" instead of "Increase activation rate from 30% to 45%"), using binary key results that cannot show partial progress, and choosing vanity metrics that do not reflect real impact. The root cause is that measuring outcomes is harder than measuring outputs. Teams default to what they can control (shipping features) rather than what matters (customer behavior changes). The diagnostic test is simple: ask "Could we achieve this key result and still have failed to make progress on the objective?" If yes, the key result is measuring the wrong thing.
Category 3: Focus Failures. These include setting too many OKRs (more than 3-5 per team), making every initiative an OKR, failing to distinguish OKRs from business-as-usual commitments, and creating OKRs that overlap with other teams without clear ownership. The root cause is that saying no is politically difficult. Every stakeholder wants their priority reflected in the OKRs, and the path of least resistance is to add another objective. The diagnostic signal is straightforward: if a team cannot recite their OKRs from memory, they have too many.
Category 4: Incentive Failures. These include tying OKR scores directly to bonuses or promotions, using OKRs as a performance management tool, punishing teams for ambitious misses, and creating competitive dynamics between teams whose OKRs should be collaborative. The root cause is conflating accountability with punishment. OKRs work because they create transparency about what matters and how much progress is being made. The moment scores carry personal consequences, people game the system. Google's original OKR practice explicitly states that OKR scores should have no direct impact on compensation.
The OKR framework functions best when treated as a learning system rather than an evaluation system. Each anti-pattern undermines learning in a specific way. Sandbagging prevents learning by removing stretch. Task-based key results prevent learning by measuring effort instead of impact. Too many OKRs prevent learning by scattering attention. Compensation ties prevent learning by making honesty dangerous. Your audit process should test for each category systematically, in order, because earlier categories tend to cause later ones. A team that sandbags their goals will also write task-based key results, because tasks are easier to sandbag than outcomes.
Step-by-Step
Step 1: Gather the Draft OKRs and Baseline Data
Collect all draft OKRs for the team or organization that are about to be finalized. For each key result, pull the current baseline metric value and any historical trend data for that metric over the past 2-3 quarters. You need the drafts in a format where you can annotate them with feedback, whether that is a shared document, spreadsheet, or dedicated OKR tool export. Also gather the previous cycle's OKR scores and any retrospective notes from the last check-in and review.
The output of this step is a single document containing all draft OKRs alongside their historical context, ready for systematic review.
Tip: If baseline metrics do not exist yet for a key result, that is itself a finding. Flag it immediately, because a key result without a baseline is impossible to score meaningfully at end of cycle.
Step 2: Run the Ambition Audit
For each key result, compare the target value to the current baseline and recent trend. Calculate what the metric would reach if the team did nothing differently (the "do nothing" projection). If the target is at or below this projection, the key result is sandbagged. " Also check whether any objectives are simply continuations of existing work rebranded as OKRs.
A genuine OKR objective should describe a meaningful change in state, not maintenance of the status quo. For each flagged item, write a one-sentence note explaining why the target does not represent genuine stretch. The output is an annotated list showing which OKRs pass the ambition test and which need target adjustments.
Tip: A useful heuristic from Google's OKR practice: if you are confident you will hit 100% of a key result, the target is not ambitious enough. Aim for targets where achieving 70% would represent strong progress.
Step 3: Run the Measurement Audit
For each key result, apply the "task or outcome" test. " Tasks describe activities ("Ship redesigned checkout flow"). Outcomes describe measurable changes ("Reduce checkout abandonment from 68% to 52%"). Flag every task-based key result.
Next, check for binary key results that can only be scored 0 or 1 with no partial progress. These are acceptable only in rare cases where the outcome is genuinely binary (regulatory approval, for example). For all other cases, rewrite the key result to include a measurable spectrum. Finally, check whether each key result's metric actually reflects progress on its parent objective.
Write the rewrite suggestion next to each flagged item.
Tip: The most common disguised task is a key result that starts with a verb: "Launch," "Build," "Complete," "Implement." If the key result starts with an action verb, it is almost certainly a task. Reframe it as the measurable outcome that action is supposed to produce.
Step 4: Run the Focus Audit
Count the total number of objectives and key results for each team. The recommended maximum is 3-5 objectives with 2-5 key results each. If a team has more than 5 objectives or more than 20 total key results, flag it for consolidation. Next, check for overlap: are two or more OKRs across different teams targeting the same metric or the same initiative without explicit shared ownership?
This creates either duplication of effort or territorial conflict. Also identify any OKRs that represent business-as-usual work (keeping the servers running, maintaining existing customer satisfaction scores) rather than change initiatives. These should be tracked as health metrics or commitments, not OKRs. The output is a focus score for each team and a list of OKRs recommended for removal or consolidation.
Tip: Ask each team lead to recite their OKRs from memory without looking at notes. If they cannot recall all of them, the team has too many. This is a surprisingly reliable diagnostic that takes less than two minutes.
Step 5: Run the Incentive Audit
Review how OKR scores are used in the organization. Determine whether scores feed directly into performance reviews, bonus calculations, promotion decisions, or team rankings. Document each connection explicitly. 6 triggers a performance improvement plan," for example).
Also check whether there are informal incentive structures: do managers publicly praise teams with high OKR scores and criticize those with low scores in all-hands meetings? These informal signals can be as damaging as formal compensation ties. The output is a written inventory of all connections between OKR scores and personal or team consequences.
Tip: Interview 2-3 individual contributors privately and ask: "Does your OKR score affect your career here?" Their answers reveal the real incentive structure, which often differs significantly from the official policy.
Step 6: Prioritize and Classify Findings
Review all flagged items from steps 2-5. Classify each finding as Critical (will cause the OKR to produce misleading results or perverse behavior), Important (will reduce OKR effectiveness but not catastrophically), or Minor (a quality improvement that can wait). Critical findings must be resolved before OKRs are finalized. Important findings should be resolved in this cycle if time permits.
Minor findings are logged for the next cycle. Create a simple table listing each finding, its category (ambition, measurement, focus, incentive), its severity, and the recommended correction. This prioritized list is your audit artifact.
Tip: In your first audit cycle, expect to find 5-15 issues. This is normal and does not mean the team is bad at OKRs. It means the team has not had a structured diagnostic process before.
Step 7: Apply Corrections Collaboratively
Share the audit findings with the OKR owners. Do not unilaterally rewrite their OKRs. Present each finding with the specific anti-pattern it matches, the reason it is problematic, and a suggested rewrite. Let the OKR owner choose whether to accept the rewrite, propose an alternative, or argue that the original is correct.
This collaborative approach is essential because the OKR owner has context you may lack, and because people are more committed to goals they helped shape. For incentive-related findings, escalate to leadership with a specific recommendation and evidence for why the current approach is counterproductive. The output is a revised set of OKRs with all critical findings resolved.
Tip: Frame corrections as questions rather than directives. "Could we achieve this key result and still fail to improve customer retention?" is more effective than "This key result is wrong, rewrite it." The question invites the owner to discover the problem themselves.
Step 8: Document Patterns for Future Cycles
After corrections are applied, write a brief retrospective note (3-5 bullet points) capturing which anti-patterns appeared most frequently, whether any are recurring from previous cycles, and what systemic causes might be driving them. Store this alongside your OKR archives. Over 2-3 cycles, these notes reveal your organization's habitual failure modes. A team that consistently sandbags may need a cultural intervention around psychological safety.
A team that consistently writes tasks as key results may need additional training on defining measurable key results. The output is a short written record that feeds into the next cycle's audit and into broader OKR coaching conversations.
Tip: If the same anti-pattern appears three cycles in a row despite corrections, the problem is systemic rather than educational. Escalate to leadership, because the root cause is likely in the team's incentive structure, reporting relationships, or workload rather than in their understanding of OKRs.
Examples
Example: Early-Stage SaaS Startup (8-Person Team)
A seed-stage B2B SaaS company with one product team of 8 people is running their second OKR cycle. The CEO drafted 7 objectives with 4 key results each (28 total key results). Several key results are tasks like "Ship Stripe integration" and "Hire 2 engineers." The team scored 0.9 on most OKRs last quarter, and the CEO ties OKR completion to a small quarterly bonus.
The audit starts with the focus check: 7 objectives and 28 key results for an 8-person team is far beyond the recommended 3-5 objectives. The team cannot possibly make meaningful progress on all 7 fronts simultaneously. The auditor recommends cutting to 3 objectives, selecting the ones most directly tied to the company's current survival metric (reaching 50 paying customers before the next fundraise). Next, the measurement audit flags 11 of 28 key results as tasks rather than outcomes.
"Ship Stripe integration" becomes "Reduce payment setup time from 15 minutes to under 2 minutes," focusing on the customer impact rather than the technical deliverable. "Hire 2 engineers" is removed from OKRs entirely and tracked as an operational commitment. 9 average score indicates systemic sandbagging. The team was setting targets they already knew how to hit.
The auditor works with the CEO to recalibrate targets so that 70% achievement represents strong performance. Finally, the incentive audit flags the bonus tie. For a seed-stage company, the auditor recommends removing the bonus connection entirely and instead using OKRs purely for strategic focus, reintroducing structured performance conversations separately. 7 achievement.
Example: Mid-Size B2C Product Organization (4 Squads)
A consumer app company with 4 product squads (Growth, Engagement, Monetization, Platform) is in its sixth OKR cycle. Each squad sets its own OKRs, but squads frequently have overlapping key results. The Growth squad and the Engagement squad both claim ownership of "DAU" as a key result metric. Platform squad OKRs are entirely task-based ("Migrate to Kubernetes," "Reduce deploy time"). 0 every quarter.
The focus and overlap audit identifies the DAU conflict first. Both Growth and Engagement influence DAU, but neither fully controls it, which means neither can be held accountable for the result. " The measurement audit addresses Platform squad's entirely task-based OKRs. " These outcomes capture why the migration matters.
0 scores across six cycles. This is a textbook sandbagging pattern. The auditor reviews Monetization's targets against their historical trendlines and discovers that every target was set below the existing growth trajectory. The correction involves resetting targets to represent genuine stretch, specifically 130-150% of the projected trendline value, so that 70% achievement still represents exceeding the natural trajectory.
The documented pattern log now shows that overlap and sandbagging are recurring organizational issues, prompting a leadership discussion about aligning OKRs across teams before the next cycle.
Example: Enterprise Company Rolling Out OKRs for the First Time
A 500-person enterprise software company is adopting OKRs for the first time. Leadership has cascaded OKRs top-down: the CEO set company OKRs, VPs derived department OKRs from them, directors derived team OKRs from department OKRs, and managers derived individual OKRs from team OKRs. There are now over 200 individual OKRs across the company. HR has announced that OKR scores will replace the existing performance review ratings.
The audit immediately flags two critical, systemic issues. First, the pure top-down cascade with individual OKRs has created a bureaucratic compliance exercise. 200 individual OKRs are unmanageable, and cascading through four layers means each individual's OKR is so narrow it has lost connection to strategic intent. The correction is to eliminate individual OKRs entirely for the first year and set OKRs only at the company and team levels.
Individual contribution to team OKRs can be discussed in one-on-ones without requiring a separate goal artifact per person. Second, and more critically, the HR announcement that OKR scores replace performance ratings is an incentive time bomb. With 500 people suddenly afraid that an ambitious miss will lower their annual review, sandbagging will be universal by the second quarter. The auditor escalates this to the CEO with a concrete recommendation: OKR scores are tracked transparently and discussed in reviews as qualitative context, but the numeric score never directly replaces the performance rating.
The existing performance review system continues in parallel for the first year. Additionally, the auditor flags that many team-level OKRs are simply restatements of the VP's OKRs with the team name substituted in, meaning teams had no real input into their goals. The correction is to hold bottom-up OKR drafting sessions where teams propose their own key results that ladder to the company objectives, reviewed for alignment but not dictated.
Example: Product Team Confusing Roadmap Items with OKRs
A B2B product team at a Series B company has been using OKRs for three cycles. Their current draft has 4 objectives, but all key results read like a product roadmap: "Launch self-serve analytics dashboard," "Release API v2," "Complete SOC 2 compliance," "Ship mobile app MVP." The team is frustrated because they always score either 0 or 1 on key results with no way to show partial progress.
The measurement audit reveals that every single key result is a binary deliverable. The team has been using OKRs as a project tracking system rather than an outcome measurement system. The auditor walks through each key result with the product manager, asking "Why does this matter? " For the analytics dashboard, the underlying goal is reducing support tickets about reporting.
" For API v2, the goal is enabling partner integrations. " SOC 2 compliance is a genuine binary milestone with no meaningful partial progress, so it is moved to the team's commitment list rather than OKRs. 0 scale based on actual progress toward measurable targets. The product roadmap still tracks the deliverables, but the OKRs now measure whether those deliverables actually achieved their intended purpose.
Best Practices
Separate OKR scoring from compensation and promotion decisions completely. When scores carry personal consequences, rational actors will sandbag targets, hide information about likely misses, and avoid ambitious objectives. Google, Intel, and most successful OKR practitioners explicitly decouple scores from pay. If your organization insists on some connection, use OKR completion as one qualitative input among many rather than as a numeric formula.
Limit each team to 3-5 objectives with 2-5 key results each, and enforce this limit without exception. Every additional OKR beyond this range dilutes focus and reduces the team's ability to make meaningful progress on any single objective. When stakeholders push to add more, treat it as a prioritization conversation: "Which existing OKR should this replace?" rather than "How do we fit this in?"
Run the anti-pattern audit before OKRs are finalized and shared publicly, not after. Once OKRs are committed and communicated across the organization, political cost of changing them rises dramatically. Teams become attached to their stated goals. The audit is a quality gate that sits between drafting and commitment, catching problems when they are cheap to fix.
Test every key result with the "achieved but failed" question: "Could we hit this key result and still have failed to make progress on the objective?" If a team launches a feature (task-based key result) but nobody uses it, they scored 1.0 on a key result while making zero progress on the objective. This single question catches the majority of measurement failures.
Track anti-pattern frequency across cycles rather than treating each audit as an isolated event. The value of the audit compounds over time as you identify recurring organizational habits. A pattern log that shows "sandbagging detected in 3 of last 4 cycles in the Platform team" is far more actionable than a one-time correction.
Keep business-as-usual metrics out of OKRs entirely. Server uptime, existing customer satisfaction, and revenue maintenance targets belong in health metric dashboards, not in the OKR system. OKRs are for change, stretch, and learning. Mixing them with operational commitments waters down the framework and inflates OKR counts without adding strategic value.
Make OKR audits a peer activity rather than a top-down review. When the audit is conducted by peers (another team lead, an OKR coach, a cross-functional partner), the dynamic is collaborative rather than evaluative. Top-down audits trigger defensive behavior and make teams less likely to set ambitious goals in the first place.
Common Mistakes
Treating every initiative, project, and commitment as an OKR
Correction
This happens because teams confuse "important work" with "OKR-worthy work." The signal is an OKR list with 8 or more objectives, many of which describe ongoing operations. OKRs should capture the 3-5 most important changes the team wants to drive, not a comprehensive inventory of everything they do. Move operational commitments and maintenance work into a separate tracking system (health metrics, team commitments, or a lightweight status dashboard). Reserve OKRs for stretch goals that represent meaningful change from the status quo.
Writing tasks and deliverables as key results instead of measurable outcomes
Correction
This is the single most common OKR mistake, and it happens because outputs are easier to control and predict than outcomes. The tell is key results that start with action verbs: "Launch," "Build," "Ship," "Complete," "Implement." Catch it by asking "What changes in the world if we do this?" For example, rewrite "Launch redesigned onboarding flow" as "Increase new user activation rate from 25% to 40%." The launch is a milestone on your project plan. The activation rate change is the key result that tells you whether the launch actually mattered.
Sandbagging targets by setting key results the team already knows it can achieve
Correction
Sandbagging happens when teams feel that missing an OKR target carries real consequences, whether formal (bonus impact) or informal (public criticism). The diagnostic is comparing the target to the "do nothing" trendline: if the metric would likely reach the target anyway with no additional effort, the key result is sandbagged. Fix this on two levels. Tactically, raise the target to a point where 70% achievement represents genuine progress.
Structurally, remove the consequences that make sandbagging rational by decoupling OKR scores from performance evaluation and by publicly celebrating ambitious misses alongside hits.
Setting OKRs once and never revisiting them until end of cycle
Correction
This happens when OKRs are treated as a planning ritual rather than an operating system. The signal is that team members cannot remember their OKRs without looking them up, and weekly or biweekly work does not reference OKR progress. The fix is to integrate OKR progress into regular check-ins and reviews, ideally weekly or biweekly. Each check-in should include a brief update on key result metrics and a confidence rating for end-of-cycle achievement.
OKRs that sit in a document untouched for 12 weeks are not OKRs; they are quarterly wishes.
Cascading OKRs top-down without input from the teams responsible for executing them
Correction
Pure top-down cascading produces OKRs that teams do not own and cannot influence. The signal is teams whose OKRs are assigned to them rather than co-created. This kills both motivation and accuracy, because leadership rarely has the ground-level context to set realistic key result targets. The recommended approach is roughly 60% bottom-up and 40% top-down.
Leadership sets the strategic direction (objectives), and teams propose how they will measure their contribution (key results). This preserves alignment while giving teams genuine ownership. See aligning OKRs across teams for the full alignment process.
Tying OKR scores directly to individual bonuses, raises, or promotion decisions
Correction
This creates a system-level perverse incentive that corrupts every other part of the OKR process. When a 0.5 score means a smaller bonus, every rational person will sandbag their targets, avoid ambitious objectives, and hide early signals of underperformance. The fix is to use OKR scores as one qualitative signal in a broader performance conversation, never as a direct numeric input to compensation formulas. Many organizations use a separate performance management system that may reference OKR contributions narratively but does not mathematically derive rewards from OKR scores.
Other Skills in This Method
Running OKR Planning and Setting Sessions
How to facilitate collaborative quarterly OKR-setting workshops that generate buy-in, ensure ambition, and produce well-structured goal sets.
Setting OKR Cadence and Planning Cycles
How to determine the right OKR cycle length, manage quarterly vs annual rhythms, and coordinate timing across different organizational levels.
Conducting OKR Check-Ins and Progress Reviews
How to run weekly or bi-weekly OKR check-ins and quarterly retrospectives to track progress, remove blockers, and maintain accountability.
Writing Effective OKR Objectives
How to craft qualitative, inspirational, and actionable objectives that motivate teams and provide clear strategic direction.
Aligning OKRs Across Teams and Organization Levels
How to cascade and align OKRs from company-level down through departments and individual contributors to ensure strategic coherence.
Defining Measurable Key Results
How to create specific, quantifiable key results with clear metrics and targets that accurately measure progress toward an objective.
Scoring and Grading OKRs at End of Cycle
How to evaluate OKR progress using the 0.0-1.0 scoring scale, interpret results, and distinguish between committed and aspirational targets.
Frequently Asked Questions
How many OKR mistakes to avoid should I check for in each cycle?
Focus on the four major categories every cycle: ambition failures (sandbagging), measurement failures (tasks as key results), focus failures (too many OKRs), and incentive failures (compensation ties). Within each category, you are checking 2-3 specific patterns, so a thorough audit covers 8-12 specific anti-patterns total. This is manageable in 45-90 minutes per team. Do not try to create an exhaustive checklist of 30+ items, because the audit becomes so burdensome that teams skip it.
Should I audit OKRs before or after the team planning session?
Run the audit after drafting but before final commitment. The ideal workflow is: teams draft OKRs, the audit identifies anti-patterns, corrections are applied collaboratively, and then OKRs are finalized during the [planning session](/skills/running-okr-planning-sessions). If you audit after public commitment, political cost of changes is high and teams resist corrections. If you audit before any drafting happens, you have nothing concrete to review.
How do I convince leadership to decouple OKR scores from compensation?
Present the evidence concretely: show examples of sandbagging from your own organization (targets set below the trend line), and quantify the ambition gap by comparing targets to what teams actually achieved. Point to Google, Intel, and other well-known OKR practitioners who explicitly separate scoring from pay. Frame it as a business argument, not a fairness argument: "Our teams are setting targets 30% below what they actually achieve, which means we are leaving significant growth on the table because the incentive structure punishes ambition." Propose a trial period of two quarters with decoupled scoring to demonstrate the impact.
What is the difference between a health metric and an OKR?
A health metric tracks something you need to maintain at an acceptable level, such as server uptime, customer satisfaction within a known range, or revenue retention rate. An OKR tracks a change you want to drive, such as increasing activation rate from 25% to 40%. Health metrics have thresholds ("alert if NPS drops below 40"). OKRs have stretch targets. Mixing them inflates your OKR count and dilutes focus. Track health metrics on a dashboard with alerting, and reserve the OKR system for the 3-5 changes that matter most this quarter.
Why does my team keep writing tasks as key results even after I explain the difference?
This usually happens because the team does not have easy access to outcome metrics, so they default to what they can directly control: their own output. The fix is not more training on OKR theory. The fix is investing in measurement infrastructure so that outcome data is available and legible to the team. If the team cannot see activation rates, retention curves, or revenue impact data, they will keep writing "Ship feature X" because that is the only progress they can observe. Start by identifying the 3-5 outcome metrics that matter most and making them visible in a weekly dashboard before the next OKR cycle.
How do I handle OKR anti-patterns in teams I do not manage?
Offer to run a peer audit as a collaborative exercise rather than a critique. Frame it as "I found these patterns helpful to check in my own team's OKRs, would you like me to run the same review for yours?" Share your own team's audit findings first to demonstrate vulnerability and show that everyone has anti-patterns. If the other team is defensive, focus on asking questions ("What happens if you ship this feature but adoption is low?") rather than making statements. Escalate to shared leadership only if the anti-patterns create cross-team problems, such as overlapping OKRs or misaligned incentives.
Can OKR scores ever be used in performance conversations without creating perverse incentives?
Yes, but only qualitatively. A manager can reference OKR outcomes in a performance review by discussing what the person learned, how they contributed to the team's progress, and whether they took on ambitious stretch goals. The line to avoid crossing is using the numeric score as an input to a formula. 6 on your OKRs, so your performance rating drops by one level" is destructive. 65, which represents meaningful progress. Tell me about the approach you took and what you learned" is productive. The distinction is between score-as-verdict and score-as-conversation-starter.