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 [1]:

  • 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?

Tips:

  • 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.

[1] Other goal setting frameworks exist and can be successful. But most other goal setting frameworks are really OKRs by another name.