OKR (Objectives and Key Results)
Idea: OKR stands for Objectives and Key
Results, a goal-setting framework used by individuals, teams, and organizations to
define and track outcomes. An Objective is a qualitative, inspiring goal –
"what" you want to achieve, and typically is short, memorable, and
actionable. Key Results are a set of specific, measurable outcomes that, if
achieved, demonstrate progress toward or fulfillment of the objective – they answer "how"
you know you achieved it in concrete terms.
OKRs operate usually on a quarterly cycle (in many companies) and are meant to create
alignment and focus. The concept was pioneered at Intel by Andy Grove and popularized by
Google and John Doerr (who wrote "Measure What Matters"). The power of OKRs is in linking
high-level aspirations (objectives) with tangible, trackable results (KRs). They push teams
to be ambitious (often using stretch goals) and to focus on outcomes rather than tasks.
Structure:
-
Objective: a brief statement (often starting with a verb) that is
ambitious and time-bound. For example, "Improve customer satisfaction in support
services." Objectives should be qualitative and motivating – something people can
get excited about.
-
Key Results: typically 2 to 5 per objective (more than 5 and no one will
remember them). Each KR is quantitative (numeric target or clear yes/no
achievement). They should be outcomes, not tasks. For the above objective, KRs could be:
"Increase average support survey score from 3.5 to 4.5 (out of 5), Reduce average first
response time from 24h to 4h, Resolve 90% of support tickets within 48h." If by end of
quarter those numbers are hit, presumably customer satisfaction improved as intended. If
not, objective likely not fully achieved.
Properties of OKRs:
-
They are usually set a level or two down. Company might have OKRs, then departments,
then teams. They aim to align – e.g., team OKRs contribute to department OKRs, etc.
-
OKRs are often aspirational. Many advocate for setting them such that
achieving ~70% of a KR is considered good (to encourage aiming high without fear). Some
OKRs are committed (must hit 100% by necessity), but many are stretch
goals. For example, Google might set an OKR to achieve a crazy tech breakthrough knowing
100% might not happen, but aiming moves them farther than a safe goal.
-
They are transparent. Usually, all OKRs are visible across the org,
fostering alignment ("oh, this is what that team is striving for, how does our work
support that or avoid conflicting?").
-
OKRs are not tasks or to-do list. E.g., "Launch new website" is not a good KR because it's a task, not an outcome. Better KRs would be around what the new
website should accomplish, like "increase site traffic by X" or "decrease bounce rate by
Y%." A common mistake is listing activities ("conduct 5 workshops") which might not
guarantee progress toward the objective. Instead, focus on the result ("team proficiency
increased as measured by X").
-
They are periodically graded/evaluated (often end of quarter). Each KR
might be scored 0.0 to 1.0 or 0-100%. Then objective gets an average or consideration of
all. The scoring is used for learning, not directly for performance evaluation in many
implementations – to allow taking risks. That being said, some companies tie them to
performance, which is debated.
Examples:
-
At a personal level: Objective: "Get in great physical shape by end of 2025." Key
Results: "Run 5K in under 20 minutes, Bench press 100kg, Reduce body fat to 15%." – These
are specific and measurable (and ambitious for many). If you hit those numbers, you
likely achieved the objective.
-
At a product team level: Objective: "Make onboarding of new users delightful and
frictionless." Key Results: "Increase Day-7 user retention from 40% to 60%, Achieve
an average user satisfaction score of 9/10 on onboarding experience survey, Reduce
average time to complete onboarding steps from 5 minutes to 3 minutes." These KRs are
clearly tied to onboarding success. Note none says "build onboarding tutorial" – that
might be one solution, but the KR is about the outcome of better retention etc. The team
might try various tasks (tutorial, emails, UX tweaks) to hit those KRs.
Usage in planning: Typically, leadership sets some top-level objectives
(e.g., "Increase market share in Asia" with KRs like "open 3 new stores" etc. – though even
that example has a task-like KR; better might be a market share percentage). Then teams
set their own OKRs aligning upward. During the quarter, teams track progress (like "KR1 is
50% achieved as of mid-quarter"). If something is off, they can adjust efforts. At quarter
end, review and maybe carry over or adjust for next quarter.
Benefits:
-
Alignment and Focus: By having a small set of OKRs, it forces
prioritization. Work that doesn't contribute to these goals is questioned or postponed.
Everyone knows what the main priorities are (no laundry list of 20 goals – if you have
20, you effectively have none).
-
Clear success criteria: People aren't doing tasks just for sake of
doing; they know what metric they want to move. This encourages thinking about impact.
For instance, developers might think "Will this refactor help one of our KRs (like
performance or reliability)? If not, maybe it's not needed now."
-
Engagement: Because OKRs often are made a bit ambitious, teams can feel
challenged in a motivating way and celebrate partial successes. They can also derive
creative solutions – not told how to meet the KR, just told "here's the number to move,"
which invites innovation. Studies have shown clarity on goals (like OKRs provide)
improves performance and motivation.
Common Mistakes/Pitfalls:
-
Output vs Outcome confusion: As mentioned, writing key results that are
actually tasks ("Launch X feature, Hire 2 engineers") rather than outcomes ("X% growth,
project completed by date with Y result"). The reason: completing the action doesn't
guarantee you achieved what you ultimately wanted. E.g., launching a feature doesn't
guarantee it's used or beneficial. It'd be better to say "Feature X achieves 10k daily
active users" as the KR – that judges the impact of launching it, not just the act.
-
Too many OKRs or KRs: Some eager teams set like 10 objectives each with
5 KRs – impossible to track or focus. Simplicity is key: 3-5 objectives, each with 2-5
KRs (some sources say no more than 3 objectives per level).
-
Not truly measurable KRs: e.g., "Improve customer happiness" as a KR.
That's vague. Needs a proxy measure (NPS score from X to Y, or reduce complaints by Z).
-
Set and forget: If you write OKRs then never check until quarter's end,
you lose the agility to course-correct. Many teams do mid-quarter check-ins or even
weekly mention of OKRs in meetings ("what progress on our KRs have we made?"). If a KR
is trending poorly mid-quarter, maybe pivot strategy or acknowledge it. OKRs should be
somewhat visible, like a dashboard or Google Sheets that updates.
-
No bottom-up involvement: If management imposes OKRs without team
input, teams might feel disconnected or find them unrealistic. A better practice is for
teams to propose their OKRs aligned to high-level ones (a negotiation). This increases
buy-in.
-
Linking to compensation incorrectly: If hitting OKRs = big bonus or
failing = punishment, people may sandbag (set easy KRs) or play safe. Many companies
(Google famously) separate OKRs from performance review directly. Instead, they use
OKRs to stretch and learn, not purely to judge employees. This encourages honesty in
scoring (you won't lie that you hit 1.0 when you hit 0.6). If tied to performance too
tightly, people set conservative OKRs to ensure good rating, defeating the aspirational
purpose.
-
Not aligning across teams: If one team's OKR inadvertently harms
another's (e.g., sales team's OKR to sign as many customers as possible vs. support
team's OKR to keep satisfaction high – sales could onboard bad-fit customers leading to
support nightmares), that's a conflict. Ideally, leadership ensures OKRs complement
rather than conflict. This is why transparency and periodic alignment meetings exist.
-
Changing OKRs mid-cycle too often: There's flexibility, but if you
constantly revise them, it might indicate poor planning or reactiveness that defeats
focus. Generally, set them and stick for that period unless something truly major shifts
(like pandemic hits, etc.). Minor adjustments can be okay early if a KR was clearly
mis-targeted or unmeasurable.
OKR Example with Bad vs Good KRs:
Atlassian gave an example: Objective "Reduce data errors." Bad KR: "Install latest
software version" – that's an action, not telling if errors reduce. Good KRs: metrics on
errors reported, etc. They illustrate that installing the software is not proving success;
measuring error reduction is.
Relation to Agile/Scrum: OKRs operate at a higher level than individual
stories or sprints. However, teams can tie them in: when planning sprints, consider "Will
this story contribute to our OKRs?" – ideally yes. If you find you're doing work unrelated
to any OKR, question its priority. Some teams even label backlog items with OKR tags to
show alignment. At sprint reviews, you might reflect on progress toward OKRs not just
story completion. Agile's inspect/adapt can then consider adjusting backlog if OKRs are
behind.
Wrap Up: OKRs drive a results-oriented culture. Instead
of measuring success by "did we do tasks?", you measure "did we achieve meaningful
results?" They also encourage collaboration (if multiple teams share an objective, they
must work together). When implemented well, OKRs can galvanize teams with a clear purpose
and drive significant improvements. They require discipline to craft well and follow
through, but many credit OKRs for substantial performance gains in tech companies and
beyond. John Doerr's mantra is "Ideas are easy, execution is everything – it takes a team
to win." OKRs provide a framework for that execution by focusing on the what and how to
measure success, leaving teams creative freedom in how to execute to get those results.
In conclusion, OKR is a framework that ensures all possible efforts are funneled towards
clearly defined, value-adding goals, and it is adaptable – you set new OKRs each cycle,
learn from previous ones, and gradually aim higher or adjust strategy as needed, staying
agile at the strategic level.