Much ado about OKRs

Much has been written about OKRs already, so I can't claim to offer any new insights. What follows is a "cheat sheet" of sorts I use for myself and to share with my teams. Obviously, this article assumes familiarity with the OKR framework. Taken almost verbatim I shared at work sometime back.

What are OKRs good for?

1. Alignment: OKRs don’t represent everything that we’re working on, but they help get the whole organization on the same page about what’s most important in a given quarter.
2. Accountability: We want to foster a greater sense of accountability across the company. No one enjoys talking about a missed KR, but it’s important. Conversely, it’s also important to celebrate when we hit our goals!
3. Track our progress: OKRs offer a useful short-hand to quickly track progress, especially across teams and projects in a large organization. Independently, just going through the motions – planning, discussing priorities, gathering status – build valuable muscle in the organization.

What are OKRs NOT good for?

• OKRs != roadmaps: OKRs are not meant to be exhaustive or comprehensive. They will not capture everything we do, likely not even all the important projects. That’s alright, so long as we all acknowledge this will happen and not rely exclusively on OKRs for signaling impact. For instance, some devops work might be hugely impactful and important, yet not show up on any OKR.
• OKRs should serve us, not the other way around: OKRs are just a tool. Teams should never strive to “hit” an OKR if that KR is no longer valid, not a high priority or needs reframing. Sometimes our priorities will change and we should be OK changing our OKRs to reflect that. As time goes on, we will get better at planning and this should happen less frequently.
• Working on OKRs won’t (necessarily) get you promoted: We are a small team and can’t really afford to work on low-leverage / low-impact projects. But as discussed above, not everything you do will be an OKR, and that’s OK. If you’re not clear on the impact of something you’re working on, ask / escalate!
• OKRs tend to focus on “new” outcomes: sustaining activity, even if critical, often gets overlooked in OKRs — e.g. availability / reliability, NPS, growth metrics etc.

Guidance for Objectives

• Ideally we should target 3–5 Objectives. Any more than that and it becomes hard to treat them as priorities — if everything is important, nothing is.
• Objectives should reflect the desired goal / priority of the organization – focus on capturing the impact (why) and not on pinning down exactly what success would look like (what).
• Objectives can (and often should) span more than 1 quarter.
• Objectives will end up being a combination of top down and bottom up — I typically find Os tend to be more top down while KRs tend to be more bottoms up.

Guidance for KRs

• Consider using the SMART criteria: specific, measurable, achievable, relevant, time-bound
• Ideally no more than 3-5 KRs for each Objective
• Each KR should have a clear owner or DRI (Directly Responsible Individual)
• Focus on outcomes, not activities: KRs should be framed to articulate what success for a given O looks like (what), not spell out the “how”.

Setting Effective KRs

In a small organization, you can probably get by with fuzzy Os and imprecise KRs. As an organization grows, you may get greater utility from crisp, well articulated KRs. But setting good KRs isn't just word-smithing: well written KRs can be a focus-amplifying lens for teams; while poorly written KRs can send teams down unproductive and demotivating rabbit-holes.

Some tips:

• Be careful with the metrics: if you chose the wrong metric, you can create perverse incentives.
• As mentioned above, focus on outcomes, not activities: think of the Objective as a black box, which KR would most credibly demonstrate progress against that objective?
• Try to capture actual value delivered: for instance, KRs framed as “launch X” or “build / deploy Y” can be improved by further articulating the why. What do you expect to happen when you launch X (increase page views, decrease latency etc etc)?
• Avoid composite KRs (“ship X and deliver Y”) and complex metrics.
• On the other hand, when aiming to move one metric up, consider pairing with a "guard-rail" metric to avoid regressions (e.g. it's easy to increase page views if you don't care about engagement)

Fin

Like any other tool / process, OKRs are not perfect. Every organization will adopt them with their own tweaks and quirks. One area I didn't dig in here is "grading" of OKRs – a topic fraught with confusion, angst and failure modes pretty much everywhere I've used OKRs. Perhaps in another post. Meanwhile, re:Work from Google has a good guide on Goal Setting with OKRs.