Guide
Setting Engineering OKRs
A practical guide to writing engineering OKRs that map to outcomes, not output - with objective patterns, outcome metrics, and a cadence that keeps them honest.
OKRs - Objectives and Key Results - are a goal-setting framework: a qualitative Objective describes where you want to go, and 3-5 measurable Key Results tell you whether you got there. The framework is simple. Applying it to engineering is where most teams quietly fail, because engineering output is easy to count and engineering outcomes are hard to define.
The failure mode is predictable. A team writes "ship the new billing service" or "close 40 tickets" as a key result. Those are activities. They can be fully "achieved" while the customer, the business, and the codebase are no better off. Good engineering OKRs describe a change in the world - faster delivery, fewer incidents, lower cost, higher adoption - and let the team choose the work that moves the number.
This guide covers how to write objectives that matter, how to pick key results that measure outcomes instead of effort, and how to run the cadence so OKRs stay useful instead of becoming a quarterly ritual nobody trusts.
Separate outputs from outcomes before you write anything
An output is something you produce: a feature, a migration, a refactor, a dashboard. An outcome is a resulting change in behaviour or state: reduced cycle time, higher activation, fewer paging incidents. OKRs should target outcomes.
Run a quick test on every draft key result - ask "could we hit this and still have wasted the quarter?" If yes, it is an output in disguise.
- Output KR (weak): "Migrate three services to the new auth library."
- Outcome KR (strong): "Cut auth-related P2 incidents from a baseline of X to Y."
The migration may well be the right work - but it is the plan, not the result. Keep it in your roadmap, not your key results.
Write objectives that a stakeholder would actually care about
An objective is a memorable, qualitative statement of intent. It should be inspiring enough that a non-engineer nods, and specific enough that the team knows what "done" feels like. Limit yourself to 2-3 objectives per team per quarter - more than that and nothing is a priority.
- Good: "Make deploying to production boring and safe."
- Good: "Give customers a checkout flow that never makes them wait."
- Weak: "Improve engineering." (Too vague to disprove.)
- Weak: "Complete the Q3 roadmap." (That's a task list, not an objective.)
If your objective could be copy-pasted into any team at any company, it is too generic. Anchor it to something your team uniquely owns.
Pick key results that are measurable, baselined, and honest
Each key result needs a metric, a starting baseline, and a target. Without a baseline you cannot tell progress from noise, and "improve X" becomes unfalsifiable.
Strong engineering metrics to draw from - most of them industry-standard:
- Delivery: the four DORA metrics - deployment frequency, lead time for changes, change failure rate, and time to restore.
- Flow: cycle time, PR review time, and work-in-progress limits.
- Quality & cost: escaped-defect rate, incident count, on-call load, and infrastructure or token spend.
- Customer: feature adoption, activation, p95 latency, error rate.
Aim for 3-5 key results per objective. Fewer and you're betting the quarter on one number; more and you dilute focus. Mix a delivery metric, a quality metric, and a customer metric so you can't win by trading one against another.
Set targets that stretch without being fiction
Classic OKR doctrine says a "good" score lands around 70% - if you hit 100% every quarter, your targets were sandbagged. That works for aspirational company goals. For engineering reliability and safety metrics, be careful: you do not want a "stretch" change-failure-rate target that quietly normalises shipping bugs.
- Use stretch targets for improvement metrics (cut cycle time, raise adoption).
- Use commit / threshold targets for guardrails you must not regress (uptime, security SLAs, change failure rate).
- Ground every target in a benchmark or your own trailing baseline - not a number someone liked in a planning meeting.
Never present an illustrative planning number as if it were measured data. Label assumptions as assumptions.
Keep AI-assisted output out of your key results
As teams adopt coding agents and copilots, there's a strong pull to make "lines of AI-generated code" or "PRs shipped with AI" a key result. Resist it. Volume of generated code is an output, and an especially misleading one - more code is often a liability, not an asset.
Instead, measure whether the AI-assisted work produced better outcomes: did cycle time drop, did code quality hold, did review time fall without a rise in escaped defects? Measuring AI-generated code by its outcomes keeps your OKRs honest as your tooling changes.
- Weak KR: "60% of PRs authored with an AI agent."
- Strong KR: "Reduce median cycle time from X to Y with no increase in change failure rate."
Assign ownership and connect OKRs to the roadmap
An objective owned by "the whole org" is owned by nobody. Give each objective a clear team owner and make the team - not a single manager - accountable for the key results. That's what keeps OKRs from becoming a top-down report card.
Then link every roadmap item to the key result it's meant to move. If a planned project doesn't map to any KR, either it's important enough to justify a new objective, or it's discretionary and should be treated as such. This is also the moment to sanity-check capacity against your sprint planning so the OKRs and the calendar agree.
Run a lightweight cadence: weekly check-ins, quarterly reset
OKRs decay the instant they're written and forgotten. Keep them alive with a rhythm:
- Weekly: a 15-minute confidence check - for each KR, is the team more or less confident it'll land? Confidence dropping is a signal to change the plan, not the target.
- Mid-quarter: a course-correction review. Kill work that isn't moving the metrics.
- End of quarter: score honestly (0.0-1.0), write down what you learned, and reset. A 0.6 with a clear lesson beats a 1.0 you gamed.
Automate the measurement. If someone has to hand-assemble a spreadsheet every Friday, the cadence dies. Wire your delivery and quality metrics into a live metrics view so the numbers are always current and nobody argues about the source of truth.