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:
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:
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:
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?
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.