I’m a big fan of Objectives and Key Results (OKRs). Having worked both at companies that do and do not rely heavily on OKRs, I see the problems that occur when not using OKRs and the successes from using them.
Note: there are many resources on OKRs. My thinking is heavily informed by Rick Klau, Google, and Michael Dearing. For intro to OKRs, see here. This post is a collection of my most salient OKR thoughts.
Problems in organizations that OKRs help solve :
- Cross team visibility. What is Andy’s team working on? What about Joe’s? OKRs make answering these questions straightforward for anyone in the organization.
- Expose duplicative efforts: Once you’ve clearly articulated what each team is working on, teams working on related things are exposed.
- Prioritization: Writing OKRs is a forcing function: e.g. will we really work on the Slack integration?
- Vertical alignment: Does an individual team’s work contribute to their broader team’s OKRs? And do subteams’ and individuals’ work contribute to their team’s OKRs?
- Revenue is generally not a good key result, because it is a trailing indicator.
- OKR newcomers frequently write “launch product X” as either an objective or a key result. Both are bad. Your objective should answer “why are you launching the product in the first place?”, and your key results answer the question: “If we achieve our objective, what would be true?”
- Key results are not todos, but rather indications that you’ve met your objective.
- Rule of thumb: 3-5 objectives per team. This forces focus.
- Rule of thumb: 3-5 key results per objective. Having 1 key result can lead to over optimization on one measure, and having too many can make measuring success difficult.
 Other goal setting frameworks exist and can be successful. But most other goal setting frameworks are really OKRs by another name.