
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:
-
OKRs = Objectives and Key Results. Objectives are the “what” you’re trying to achieve (e.g., become the best X in the world) and the 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 you decide to meet up with a bunch of your friends in Central Europe, and some people end up in Germany, some in Italy, and some in France, whereas you really meant Switzerland, you won’t be particularly happy. A company is like that: if the company’s goals are not clearly defined, then everyone ends up working towards different goals, and all the vectors will cancel out to 0. 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.
-
There are two types of OKRs: committed OKRs, which are critical business goals that you are intended to accomplish 100% (e.g., improving security), and aspirational OKRs, which are designed to stretch you, and therefore, you expect to fail at many of them (~70% success rate with high variance).
-
You can have OKRs for the entire company, OKRs for each team, and personal OKRs. They should all be inter-connected (e.g., team OKRs must support those of the larger organization).
-
For aspirational OKRs, 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.
-
All OKRs should be developed openly, written down, and shared publicly within the company. Everyone should commit to them publicly, review them publicly, and, ideally, you should see them every day as you work. Clear, written, public commitments to big goals are an incredibly powerful tool.
-
The 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.
-
The objectives should be defined in how the impact they have, not the thing you’re building. E.g., “ship feature X” is not nearly as good of an objective as “ship feature X to increase sign ups by 25%” or even better, “increase sign ups by 25%.”
-
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 the key results to avoid incentivizing the wrong behavior. For example, 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.” Another example: 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.”
-
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.
-
Less is more. You want no more than 3-5 OKRs per quarter and no more than 3-5 key results per OKR. Any more and it becomes hard to focus and decide what really matters.
-
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.
-
It’s a good idea to 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; and 0.7 - 1.0 means you made great progress or got the whole thing done. Or, analogously, you can mark each OKR as red, yellow, or green.
-
OKRs should not be directly tied 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.
That’s pretty much it. 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. You can also find it online here: https://www.whatmatters.com/resources/googles-okr-playbook. In fact, that website is arguably more useful than the book itself, so check it out!
Rating: 3 stars
Yevgeniy Brikman
If you enjoyed this post, you may also like my books. If you need help with DevOps, reach out to me at Gruntwork.