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 fit your goals into the OKR format, this post is for you. Part 1 discussed the basics: what are OKRs and how do they work? Part 2 discussed how to write good OKRs. As with Part 2, the opinions expressed here are my own. If you disagree, I'd love to discuss it in the comments!

My Objectives can't be completed in a single planning period. What do I do?

It's okay to allow Objectives to span multiple periods, but it's better to break down the long term objective into milestones that you can fit into a single period. For example, a two-quarter Objective "XYZ legacy infrastructure is shut down" could be broken down into "Remove dependencies on XYZ" (Q1) and "XYZ is shut down" (Q2). This communicates to your stakeholders that you are making progress towards the long term objective and allows your team to feel a sense of accomplishment every quarter.

My team has lots of metrics with goals for each. How can we make KRs for these without having too many KRs to be manageable?

Write a KR that encompasses all of them together with a link to a supporting document. For example, it's fine to say, "Our team meets on call SLOs as defined here." This does dilute your ability to report on them: does an 80% score on the KR mean you met the SLOs in 80% of escalations or that 80% of the SLOs were met 100% of the time? But it may be an acceptable tradeoff.

We can't be expected to hit our SLOs 100% of the time, can we?

Well, you can, but you probably don't want to. A common way to approach this is with percentiles: "Our service will have latency <1 second, 99% of the time." "99% of the time" is the same as saying "the 99th percentile", which can be shortened to "p99". p80, p90, p95, and p99 are all common choices. The higher percentile number you choose, the more responsibility you're taking for worst case performance. p50 is the median and is also very common because it reflects typical performance. Average is usually not a good metric because it mingles normal cases with outliers without providing insight into either. It's usually better to set separate goals for p50 and p99. Setting good SLOs is hard - a subject for a future post!

My team doesn't have readily available metrics. How can my KRs be measurable?

Being measurable does not require a quantitative goal. It's perfectly fine to have a KR like "XYZ legacy infrastructure is shut down." or "We have a plan for building ABC next quarter". Either you have a plan or you don't - that's measurable. Be especially careful to define these precisely - do you just want a draft of the plan or does it need to be signed off by stakeholders?

We're undertaking a research project where the outcomes aren't clear, so we can't set KRs for it at the beginning of the period, right?

Research projects still have goals. Typically you aim to identify some potential courses of action, try some of them, select one as the winner and implement it, or identify that no fruitful path forward exists. Each of these can become a KR:

1. Identify 3 possible solutions.
2. Perform proof of concept for at least 1 solution and make go/no-go decision.
3. Deploy chosen solution to achieve <business goal>.

My team doesn't control the work to achieve a business result that is important to us, so we shouldn't have a KR for this because it's not Actionable, right?

Having an Actionable KR does not mean your team has to do all the work: you can take a KR that depends on another team's work, but by doing so you're accepting responsibility for ensuring that they complete that work. (ref: Extreme Ownership) In fact, if the KR is truly necessary to achieve your Objective, it doesn't matter whether your team controls it or not - it has to get done. You can ensure a good outcome by obtaining their management's buy-in, monitoring their progress, escalating problems, and developing backup plans. Teams often resist taking KRs that they don't have complete control over, but if a thing is necessary to achieve the Objective, then it's necessary, so take ownership, take the KR, and make sure it gets done.

What are some interesting scenarios you've encountered in OKR planning? Let's discuss them in the comments.