The engineering team had spent two weeks crafting their quarterly OKRs. Objectives like "Deliver the checkout redesign." Key results like "Ship the new payment flow by March 15" and "Complete mobile optimization by April 1." The process was thorough—workshops, alignment sessions, sign-offs from leadership.
By quarter end, they'd achieved 100% of their OKRs.
They'd also shipped features that customers didn't use, ignored technical debt that was slowing everything down, and burned out engineers pushing toward arbitrary deadlines that had been set before anyone understood the real complexity. Checkout conversion hadn't budged. Revenue impact was negligible.
"We achieved all our OKRs," the VP of Engineering said at the retrospective, "and we're worse off than when we started. What did we actually accomplish?"
This scenario plays out constantly. OKRs are supposed to connect work to impact—that's the entire point. But most engineering OKRs measure what teams deliver rather than what changes in the world as a result. They become fancy task lists instead of strategic tools. They create the illusion of progress while missing the actual goals.
After helping over 40 engineering organizations implement and fix their OKR systems at SmithSpektrum, I've learned that the difference between OKRs that work and OKRs that waste everyone's time comes down to a handful of fundamental principles that teams consistently get wrong[^1].
The Fundamental Mistake
The fundamental mistake is confusing outputs with outcomes.
An output is what you deliver: a feature, a system, a migration, a number of bugs fixed. An output is entirely within your control—you can commit to shipping the checkout redesign because shipping it depends only on your team's execution.
An outcome is what changes as a result of what you deliver: conversion rate increases, latency decreases, customers report fewer problems, development velocity improves. An outcome depends on whether your output actually worked—whether it achieved the goal that motivated building it in the first place.
"Ship checkout redesign by March 15" is an output. "Increase checkout conversion from 65% to 78%" is an outcome.
The output-focused OKR is seductive because it's achievable. You control whether you ship the feature. You can work harder, cut scope, and hit the date. You can declare victory and move on. It feels good to achieve 100%.
But the output-focused OKR misses the point. You might ship the checkout redesign and discover that conversion doesn't improve—maybe the old checkout wasn't actually the problem. You might ship by March 15 only to realize that the rushed timeline created quality issues that hurt conversion rather than helping it. The OKR was achieved, but the underlying goal wasn't.
Outcome-focused OKRs force you to care about impact. If your key result is "increase checkout conversion to 78%," you can't declare victory just because you shipped something. You have to look at whether conversion actually increased. If it didn't, you have to figure out why and try something else.
This is harder. It requires measuring things. It creates the possibility of failure that's not within your control. It's uncomfortable. That discomfort is the point—it keeps you honest about whether you're making progress toward goals that matter.
What Makes OKRs Work
Good objectives are qualitative and aspirational. They describe a direction, a better future state, something worth striving for. "Make checkout effortless" is an objective. "Ship checkout redesign" is a project.
Good objectives are owned. Someone is accountable for achieving them—not in the sense of being blamed if they fail, but in the sense of being responsible for driving progress, making decisions, and keeping focus.
| OKR Type | Good Example | Bad Example | Why It Matters |
|---|---|---|---|
| Outcome-based | "Reduce p99 latency to <100ms" | "Optimize database queries" | Measures what users experience |
| Measurable | "Increase test coverage from 60% to 80%" | "Improve code quality" | Clear success criteria |
| Ambitious | "50% reduction in deployment failures" | "No major incidents" | Drives real improvement |
| Controllable | "Ship authentication redesign" | "Increase user signups" | Team can directly influence |
| Time-bound | "By end of Q2" | "Eventually" | Creates accountability |
Good objectives are ambitious. The purpose of OKRs is to stretch toward meaningful goals, not to describe work that's already planned. If your OKR is just a list of committed projects, you don't need OKRs—you need a project tracker.
Good key results are quantitative. They're measurable—you can tell at the end of the quarter whether you achieved them or not. "Improve developer experience" is a bad key result because you can't measure it. "Reduce build time from 15 minutes to 5 minutes" is a good key result because the number tells you whether you succeeded.
Good key results measure outcomes, not activities. "Conduct 20 user interviews" is an activity. "Identify 3 validated pain points" is closer to an outcome—it describes what you learned, not just what you did. "Reduce support tickets about X by 40%" is an outcome—it describes change in the world.
Good key results are achievable but challenging. The conventional wisdom is that you should expect to achieve 60-70% of your key results. If you're consistently achieving 100%, you're sandbagging—setting goals that don't stretch you. If you're consistently achieving 30%, your goals are unrealistic and demoralizing. The 60-70% zone means you're reaching for things that require real effort but aren't impossible.
Engineering OKRs That Work
Let me illustrate what this looks like across different engineering contexts.
A product feature team might have an objective like "Improve the checkout experience to drive revenue growth." Their key results might be: increase checkout completion rate from 65% to 78%, reduce average checkout time from 4 minutes to 2 minutes, reduce checkout-related support tickets by 50%. Notice that none of these key results mention specific features. The team might ship a redesign, or add saved payment methods, or fix bugs, or simplify the form—whatever actually moves the metrics. The OKR doesn't constrain how they achieve the outcome.
A platform team might have an objective like "Make deployments fast, safe, and effortless." Key results might be: 95% of deployments require zero manual intervention, reduce rollback time from 30 minutes to under 5 minutes, developer deployment confidence score improves from 3.2 to 4.5 (internal survey). These key results measure whether deployments are actually better, not whether the team implemented specific tools.
An SRE team might have an objective like "Deliver reliability that customers can count on." Key results might be: achieve 99.95% uptime (up from 99.8%), reduce mean time to recovery from 45 minutes to under 15 minutes, zero customer-facing incidents caused by deployment failures. These measure reliability outcomes—what customers experience—not reliability activities.
A team focused on technical debt might have an objective like "Reduce the friction that legacy systems create for development." Key results might be: migrate 40% of traffic to the new architecture, reduce new feature development time by 30%, improve developer satisfaction with the codebase from 3.8 to 4.3 (survey). These measure whether the technical investment actually paid off in reduced friction.
The OKR Anti-Patterns
Certain patterns consistently produce bad OKRs.
The task list disguised as OKRs is the most common. Every key result is a deliverable: "Ship X by date Y." The OKR system is being used as a project tracking tool, which defeats the purpose. Projects belong in your project tracker. OKRs should describe what success looks like, not what you're building.
Sandbagged goals show up when teams set OKRs they know they'll achieve. Everything is committed work relabeled as objectives. There's no stretch. The 100% achievement rate at the end of the quarter proves nothing—it just proves you're good at estimating what you were already going to do.
Metrics without meaning happen when teams measure what's easy rather than what matters. "Achieve 80% test coverage" sounds measurable, but test coverage doesn't correlate reliably with quality. You can have 80% coverage with tests that don't catch bugs. Better: "Reduce regression bugs by 50%"—that measures what you actually care about.
Top-down only OKRs come when leadership dictates objectives without input from teams. Teams don't own goals that were assigned to them without consultation. Effective OKR systems involve bidirectional input—leadership sets direction, teams propose how they'll contribute.
Set and forget is the pattern where OKRs get written in week one and revisited only in week twelve. Without regular check-ins, OKRs become disconnected from actual work. Weekly or biweekly progress updates keep OKRs relevant and surface problems early.
OKRs tied to performance review create gaming. If my bonus depends on my OKR score, I'll set easy OKRs to ensure I hit them. OKRs should be decoupled from individual performance evaluation—otherwise the stretch goal system breaks.
Running the OKR Process
The mechanics of how you run OKRs matter as much as the content.
Quarterly cycles work well for most engineering teams—long enough to make meaningful progress, short enough to adjust to changing circumstances. Some teams use six-week cycles for faster iteration; some use annual cycles with quarterly check-ins. The right cadence depends on your context.
The setting process should be collaborative. Leadership provides context: what are the company's strategic priorities? What are the big problems we need to solve? Teams draft OKRs that contribute to those priorities based on their unique perspective and expertise. There's back-and-forth—alignment sessions where teams present their draft OKRs, others ask questions, conflicts get resolved.
Few OKRs is better than many. Three to five objectives per team, with two to four key results each, is plenty. More than that fragments focus and creates cognitive overhead. If everything is a priority, nothing is.
Regular check-ins prevent drift. Weekly is common: quick review of progress on each key result, surface blockers, note if adjustments are needed. Monthly is a deeper look: are we on track? Do we need to change our approach? This isn't bureaucracy—it's the accountability that makes OKRs work.
Scoring at quarter end should be honest. Score each key result based on achievement: 0.0 means no progress, 0.7 means strong achievement, 1.0 means complete achievement. Average scores around 0.6-0.7 indicate healthy calibration. If your team averages 0.9+, you're not stretching. If you're averaging 0.3, something's wrong—either the goals were unrealistic or execution failed.
The retrospective matters more than the score. What did we learn? What would we do differently? What surprised us? OKRs are learning tools as much as planning tools. A failed OKR that teaches you something is more valuable than an achieved OKR that teaches you nothing.
OKRs and Your Roadmap
OKRs and roadmaps serve different purposes, and teams that conflate them get confused.
OKRs describe what you want to achieve—the outcomes you're driving toward. The roadmap describes how you plan to achieve it—the projects and features you'll build. OKRs are outcomes; roadmaps are outputs.
The roadmap should serve the OKRs. You choose projects because you believe they'll move the key results. If the roadmap changes—you discover a better approach to the outcome—the OKRs should stay the same. If the OKRs change, it means your strategic priorities changed, which should be rare.
When your roadmap succeeds but your OKRs don't improve, that's important information. You built what you planned, but it didn't have the expected impact. Now you need to understand why and try something different. This is the feedback loop that makes OKRs valuable.
Don't turn OKRs into a roadmap. "Launch features X, Y, and Z" as key results means you've just renamed your project plan. Keep OKRs focused on outcomes and let the roadmap be where you track the work.
Making OKRs Sustainable
OKR fatigue is real. Teams that experience OKRs as bureaucratic overhead disengage. Keeping the system sustainable requires ongoing attention.
Keep the process lightweight. If OKR setting takes more than a day of effort per quarter, it's too heavy. If check-ins take more than thirty minutes a week, streamline them. The goal is useful structure, not administrative burden.
Connect OKRs to real impact that people can see. When a key result improves, celebrate it—not because you achieved a number, but because something in the world got better. "Our uptime improvement means customers experienced 80% fewer disruptions last month." That connection to impact makes the process meaningful.
Allow for imperfection. OKRs will never capture everything that matters. Some important work doesn't fit neatly into the system. That's fine. OKRs are a tool for focus, not a comprehensive accounting of all value.
Adapt to your scale. A five-person startup doesn't need the same OKR infrastructure as a 500-person organization. Start lightweight and add formality only when it becomes necessary. It's easier to add structure than to remove bureaucracy.
The team that achieved 100% of their OKRs while getting worse? They rewrote their OKRs the next quarter. "Increase checkout conversion from 65% to 78%"—an outcome—replaced "ship checkout redesign by March"—an output.
They hit 65% of their new OKRs. Conversion reached 74%, not 78%. But 74% was real progress—real impact on revenue, real benefit for customers. They learned that some of their assumptions were wrong, adjusted their approach, and set new OKRs for the next quarter.
"We achieved less on paper," the VP observed, "but we actually accomplished more. That's when I understood what OKRs are for."
References
[^1]: SmithSpektrum engineering leadership advisory, OKR implementation, 40+ companies, 2019-2026. [^2]: Doerr, John. "Measure What Matters," 2018. [^3]: Wodtke, Christina. "Radical Focus," 2016. [^4]: re:Work by Google, "Guide to OKRs."
Implementing engineering OKRs? Contact SmithSpektrum for goal-setting and organizational design.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum