OKRs: Doing It Right (Part 2)

OKRs: Doing It Right (Part 2)

Part 2 of 3 in my OKR series discusses how to write good OKRs. Part 1 discussed the basics: what are OKRs and how do they work? Part 3 discusses some interesting situations you might run into. This post reflects my opinions, experience, and things I've read, but is certainly not definitive. If you disagree with something I've said here, I'd love to discuss it in the comments!

TL;DR:

KRs should be Specific, Measurable, Actionable, Realistic and Time-bound: a neutral observer should be able to tell whether you met the KR by its due date, and it should be possible for your team to meet the KR. KRs should be necessary and sufficient to achieve the Objective.

TL:

Objectives are fundamentally a communication tool. They should be inspiring to the team, something that makes people excited to come to work every day. They should be immediately comprehensible to anyone in your broader organization. Objectives may or may not be something that you can finish: "GeneriCorp is a great place to work" is an inspiring and clear Objective, even though you can never call it done and go home (ref: The Onion). They may or may not be measurable, though measurable Objectives tend to be more clear and more inspiring. If you have more than about 4 Objectives, it becomes hard to communicate about them, so you generally want to limit their number and consolidate if you have too many. Objectives are less important than KRs.

KRs are what you will be held accountable for, which is why they matter more than Objectives. KRs should be SMART:

  1. Specific: there should be no question about what the KR means. "GeneriCorp is a great place to work" is a fine Objective but a terrible KR. "A great place to work" means different things to different people. "GeneriCorp is on the Forbes Top 100 Best Companies to Work For list" or "Average score >4 on Employee Survey question 'GeneriCorp is a great place to work.'" are much better.
  2. Measurable: There should be no question whether you met the KR or not. An independent observer with no specific knowledge of your team should be able to tell whether you succeeded.
  3. Actionable: You have to be able to materially affect the outcome of the KR. A KR like "Our stock price is higher than MainCompetitor's" is not a great one for most teams because you have very little control over your stock price and even less over MainCompetitor's. Focus on what you can control: "Our team's revenue contribution increases by 10%". "What you can control" is a spectrum, so it's not always obvious whether a KR is sufficiently Actionable. This will be discussed in Part 3.
  4. Realistic: Don't set KRs you can't meet - even if your manager wants you to. It's okay to mark a KR as a [stretch]. Some orgs incentivize risk taking and ambitious goals by aiming for a completion rate like 70% rather than 100%. In these cases, you want to set your KRs so that if everything goes very well, you'll get 100%. You should not include "sacrificial" KRs that you expect not to meet - it doesn't reflect management's goal to incentivize risks and sets you up to fail if you screw up the KRs you actually did plan to meet.
  5. Time-bound: It needs a due date. Most companies enforce this as a natural part of the planning cycle.

KRs should be necessary and sufficient to achieve the Objective as written. If they really aren't necessary then you shouldn't do them. If they're necessary in reality but not for the Objective as written, you should rephrase the Objective or create a new one. Meeting all the KRs should be sufficient to achieve the Objective in the relevant planning period.

Some good tests for your KRs:

  1. Can we fulfill the text of this KR without actually meeting the business goal it's supposed to represent?
  2. Can we meet the business goal without satisfying the text of the KR?
  3. Would a neutral observer be able to determine whether you met the KR?
  4. Would multiple neutral observers always agree whether you met it or not?
  5. Do we really, truly believe we can do this?
  6. Can we achieve the Objective without meeting every KR?
  7. Can we meet every KR and still not achieve the Objective?

Where it's not obvious, the KR's text should explain its connection to the Objective: "XYZ legacy infrastructure is shut down to save $100k/year compute costs". There is often debate about whether the rationale should come first or last: "XYZ is shut down to save $100k" or "Save $100k by shutting down XYZ". I think this is totally unimportant. A team should just pick one consistent way to do it and spend their time on things that matter.

You generally want to have no more than about 6-8 KRs per Objective. If you have more, it becomes very time consuming to write them well and to evaluate them over time. This is less true of quantitative KRs like "Respond to X% of tickets within Y minutes with Z% CSAT". It can be helpful to combine related KRs, such as by having one KR for "Meet SLOs as defined here" rather than "Meet SLO for WhizBang service", "Meet SLO for SizzlePop service", etc.

Projects

It's really easy to write bad KRs that are actually projects, like "Ship WhizBang feature." You don't actually care about shipping WhizBang, you care about whatever customer or business benefit WhizBang is supposed to achieve. With a KR like "Ship WhizBang", you can ship a piece of junk that everyone hates, but you met your KR. If the project is WhizBang, the KR might be "Satisfy the #1 customer feature request by shipping WhizBang with 90% customer satisfaction rate." or "Save $100k by shipping WhizBang".


Once your OKRs are set, you should only change them if:

  1. You realize the text doesn't capture what you meant it to,
  2. You realize the KRs aren't the right ones to achieve the Objective, or
  3. You realize the Objective isn't the right one for the business.

In all cases, you should get management buy-in before making a change. You should not change your OKRs because you aren't going to meet them (and your management shouldn't let you).

It's important to score your KRs at the end of the period. I've seen several orgs put a lot of effort into defining KRs up front but never reviewed whether the KRs were actually met. Scoring doesn't need to be a super rigorous exercise. It is better to be roughly right than precisely wrong (Carveth Read). The point is to determine which goals you did and did not meet, to hold people accountable where appropriate, and to communicate to your organization how well you did. Don't forget to celebrate all of the wins!

If you fail to meet your OKRs, you should figure out why: did you take on too much, have an underperforming team member, fail to manage dependencies, etc.? The end-of-period KR review is a good place to conduct this postmortem. If you're a manager, you should make it okay to miss an OKR or two, holding people accountable only when they consistently or badly miss. If you are too rigid, people will softball their KRs, fudge metrics, and otherwise try to game the system.


That's my take on how to write good KRs. What do you think?

Leean Saveker

Strategic & Operational Risk Management @ Robinhood | Senior Commissioned examiner@ Federal Reserve System | Duke MBA

1 年

Best OKR article I have ever read. I can’t wait to read the part 2.

要查看或添加评论,请登录

David Seidman的更多文章

  • My to-do list method

    My to-do list method

    I have a very simple to-do list process that makes an enormous difference in my organization and productivity, so I…

    10 条评论
  • My Career Planning Process

    My Career Planning Process

    Over the years I've put together my own career planning process, which combines the best parts of the processes I've…

    5 条评论
  • OKRs: Interesting Scenarios (Part 3)

    OKRs: Interesting Scenarios (Part 3)

    Part 3 of 3 in my OKR series discusses some situations that often trip up OKR planners. If you've ever found it hard to…

    4 条评论
  • OKRs: The Basics (Part 1)

    OKRs: The Basics (Part 1)

    OKRs are a common way to set goals in the tech industry, but I've never seen an article about them that I really liked…

    4 条评论
  • The inherent tradeoff of technical management

    The inherent tradeoff of technical management

    A commenter asked, "how do you become a strong manager while still maintaining technical mastery?" The answer is that…

    6 条评论
  • Downsizing

    Downsizing

    I spent 15 years of my career at tech giants (Microsoft, Google and Salesforce). Then, 18 months ago, I joined…

    11 条评论
  • How to pick a project

    How to pick a project

    Last week I posted about how to become a manager. I was asked a follow up question: how can I find impactful leadership…

    3 条评论
  • How to Become a Manager

    How to Become a Manager

    A question I often get from early career folks is, "How did you become a manager?" Usually what they really mean is…

    9 条评论

社区洞察

其他会员也浏览了