OKRs HowTo
Objectives and Key Results (OKRs) are a standard tech industry tool that teams use for quarterly goal setting. Despite the mangement-speak name, they can be a useful tool if used well — but they are often not used well. Having used them for 15 years at Google and other places, here’s my guide to doing them well.
OKRs are primarily for you, not others
The most important idea is that OKRs are a tool for your team to use to drive quarterly alignment. Their primary purpose is not to report to other people.
They describe results that you want to exist
OKRs should not be a list of tasks (e.g. ‘Complete Deep Learning module’). Task lists can be useful, but they are a different thing. OKRs should be a set of states of the world that you want to exist — they don’t describe how those states come about. So e.g. ‘1 customer using our product in daily workflow’ is better, because it describes the outcome that we all care about.
They should implicitly answer ‘why?’ questions about the project
Writing OKRs once a quarter is valuable because it makes us answer the question ‘why are we doing this’. OKRs are focussed on outcomes, not processes, so we need to understand what we’re trying to achieve.
You should always go an extra step or 2 on the why question. Just writing down something measurable isn’t enough (‘achieve AUC of 0.9’). One always needs the context of why that’s important (e.g. ‘100 clinicians using our tools to make decisions weekly’).
They should be understandable outside of your team
Even though they are a tool for you as a team, you should take the opportunity to ensure that someone reading them from outside the team has a good chance of understanding them, and of understanding whether they are good OKRs. This means e.g. glossing Three Letter Acronyms, and linking to other explanatory documents where appropriate (while thinking about whether those explanatory documents are accessible outside the team). This exercise also helps drive clarity of thought, and helps new team members get up to speed quickly.
There shouldn’t be very many of them
When you look at OKRs in this frame (as descriptive of outcomes you want to exist) you’ll realise that you don’t need a lot for each quarter. Resist the urge to make a long list (remember, it’s not a task list). Task lists are useful, but a different thing. Typically you will have 2 or 3 Objectives, each of which has 1–4 Key Results associated with it. Having just 1 KR per Objective is absolutely fine (and indeed just 1 Objective). In fact less is more — it drives focus. The team should be able to keep all the KRs for the quarter in its head, keeping that alignment stong.
You should score them at the end of each quarter
At the end of the quarter, you should be able to measure how much each Key Result has moved in the direction desired, and give yourselves a score out of 1.0 (with 1.0 meaning it was completely achieved, and 0.0 meaning the metric didn’t change at all).
You will often read that you should aim for an average of about 0.7 across your OKRs, to ensure you’re being ambitious but realistic. I don’t think that really matters. What matters more is that you learn to calibrate your team from quarter to quarter, so that if you’re hugely missing them you can asks yourselves why, and be a bit more defensive next quarter, and similarly if you’re achieving 1.0’s across the board, are you being ambitious enough ? Remember this is a discussion within the team.
Objectives are long term direction of travel, Key Results are outcomes to measure by the end of the quarter.
OKRs look like something like this:
Objective: Increase rate of customer target commitment
- Q1 Key Result 1: 2 targets from our systems have been approved by Customer’s Commit to Target Validation board
- Q1 Key Result 2: Experimental Cycle time for validation reduced by 20%
The Objectives are often long lasting goals that will go across more than 1 quarter (in fact you ideally don’t want to be chopping and changing them too much). Against each, the Key Results are measurable outcomes you want from the next quarter.
