This book should’ve been a long blog post. At its core, it contains valuable advice about the power of OKRs (Objectives and Key Results) as a mechanism to help get everyone in a company moving in the same direction. Unfortunately, this nugget of wisdom is wrapped in loads of generic business book jargon, scattered through chapters that seem to be organized randomly, and padded out with lots of case studies, which while sometimes interesting, are not terribly useful, and often written in an unnatural style that sounds like an infomercial (“and all of this was only possible thanks to… OKRs!!!”).
So, here, without all that extra padding, I’ve copied in my notes that contain most of the important takeaways from the book:
What are OKRs
OKRs = Objectives and Key Results.
- Objectives are the “what” you’re trying to achieve (e.g., become the best X in the world)
- Key results are the “how” you’re going to achieve it (e.g., X million page views per month, Y revenue per year, etc).
Why you should use OKRs
If the company’s goals are not clearly defined, then everyone ends up working towards different goals, pulling in different directions, and all the vectors will cancel out to 0.
- Analogy. You decide that your goal is to meet up with a bunch of your friends in “Central Europe.” The result: some people end up in Germany, some in Italy, and some in France, whereas you really meant Switzerland. This is a bad result, due to unclear goals.
- OKRs are about setting clear goals. OKRs are a way to make sure that your most important goals and the means of accomplishing those goals are clear, transparent, and visible to everyone, so everyone is aligned, and moving in the same direction.
Types of OKRs
There are two types of OKRs:
-
Committed OKRs.
- Critical business goals.
- You intend to accomplish these 100%.
-
Aspirational OKRs.
- Goals designed to stretch you.
- You expect to fail at many of these goals (~70% success rate with high variance).
- A big, bold, audacious goal is valuable in getting the best out of people.
- Many studies have shown that people produce far more/better output when they aim for goals that are well beyond their current abilities—especially if those goals are written and shared publicly.
You can have OKRs for the entire company, OKRs for each team, and personal OKRs. They should all be interconnected (e.g., team OKRs must support those of the larger organization).
OKR process
All OKRs should be:
- Developed openly
- Written down
- Shared publicly within the company
Everyone should:
- Commit to them publicly
- Review them publicly
- Ideally, you should see them every day as you work
Regularly review how you did against your previous OKRs and to come up with updated ones. At Google, each employee scores themselves against their OKRs:
- 0 - 0.3 means you made no progress towards the OKR
- 0.4 - 0.6 means you made some progress, but you’re not done
- 0.7 - 1.0 means you made great progress or got the whole thing done
Alternatively, you can mark each OKR as red, yellow, or green.
Tips on defining OKRs
-
Key results MUST be measurable and preferably time-bound.
- In fact, the typical phrasing for an OKR is “ as measured by “.
- E.g., “We will become the premier photo hosting website in the world as measured by getting to 100 million users and 1 billion photo uploads by the end of the year.”
- They should be clearly defined (e.g., the “100 million users” in the previous example is ambiguous—is that monthly active users? daily active users? registered users?), so there’s no ambiguity when reviewing the results later of whether you accomplished them or not.
-
Objectives should be defined based on their impact.
- They should not be defined based on what you’re building.
- Bad: “ship feature X.”
- Better: “ship feature X to increase sign-ups by 25%.”
- Even better, “increase sign-ups by 25%.”
-
When the key results are done, the objective is done.
- The key results must be defined in such a way that when they are complete, the objective is completed.
- If you mark all the key results as “done” but you don’t feel like the objective is accomplished, you didn’t pick the right key results.
-
Try to balance key results.
- Try to balance the key results to avoid incentivizing the wrong behavior.
- Example 1: a key result like “make $X in revenue by date Y” could lead to negative behavior when someone is trying really hard to make their numbers (e.g., ripping customers off to boost revenue in the short term), so you can try to offset this by also having a key result like “customer NPS score of Y.”
- Example 2: a key result like “ship feature X by date Y” could lead to cutting a lot of corners as date Y approaches, so try to balance it by also having a key result like, “with fewer than X bugs per 1,000 lines of code.”
-
Less is more.
- You want no more than 3-5 OKRs per quarter and no more than 3-5 key results per OKR.
- Anymore and it becomes hard to focus and decide what really matters.
-
It takes time to get good at OKRs.
- It can take a long time (1-2 years) for an organization to get good at using OKRs.
- It’s a skill that you must develop.
OKRs are a tool
They are a great way to get everyone aligned, but they are not the end-all, be-all of decision-making.
- If an OKR clearly cannot be accomplished, or the outside world has changed and the OKR no longer makes sense, it’s OK to change it or discard it.
- Don’t be dogmatic about it.
Don’t tie OKRs directly to compensation
- Otherwise, employees will fear taking any risks and will sandbag all the key results, only promising what they know they can easily deliver as to ensure they get their bonuses.
- If you want people to try for big, crazy, game-changing ideas, you need to expect that failures will happen, and you have to provide an environment where failing is not punished.
Other thoughts on the book
The rest of the book mostly feels like fluff. Moreover, it fails to answer critical questions such as:
- How do you implement OKRs at a company that hasn’t used them before?
- How often should you review and update OKRs?
- What’s the process for creating company OKRs, team OKRs, and personal OKRs, and having them cascade all the way down?
- OKRs shouldn’t be tied directly to compensation, but it seems impractical to ignore them completely too. How do you balance that?
- How do you deal with failure? The book explains that failure for aspirational OKRs is expected, but many people are not used to failing—especially publicly, as is the case with OKRs—so how do you help them get used to that?
One of the most useful parts of the book is an appendix that contains an excerpt from Google’s OKR playbook. In fact, that website is arguably more useful than the book itself, so check it out!
