A Leader’s Guide to Implementing OKRs

I’m a firm believer that Objectives & Key Results (OKRs), the goal-setting framework invented at Intel and popularized by Google and John Doerr, can be a highly effective leadership tool for a team of any size. When done right, they help drive focus, alignment, accountability, and an outcome-orientation throughout the organization. However, too often, OKRs are implemented poorly, resulting in the promised benefits never being realized. After spending the last 8 years implementing OKRs at both large organizations like LinkedIn and small startups like Notejoy, I wanted to share what I’ve come to appreciate is required to develop an effective OKR program.Writing Effective OKRs
Start by defining each of your objectives. An objective details what you hope to accomplish with a given initiative. Great objectives are significant, concrete, finite, action-oriented, and inspirational.Objective examples:

• Launch an edit button on Twitter
• Redesign Facebook’s profile page
• Build the world’s best web browser at Google
• Launch a redesigned signup flow that reduces the number of steps required on Amazon

You then define one or more key results associated with each objective. A key result defines a numerically-based expression of success or progress towards an objective. Great key results are specific, time-bound, measurable, and verifiable.

Key result examples:

• Increase weekly active users by 20%
• Achieve 20M activated users
• Launch the new feature by 7/31
• Conduct 50 customer interviews

Measure Outcomes, Not Output

The most valuable key results measure meaningful user or business outcomes as opposed to simply the output of one’s work. For example, “publish 15 blog posts” is a useful key result, but you’d also want to pair it with a key result that speaks to the outcome you hope to drive from publishing these blog posts. For example, “add 1K new subscribers”, “reach 10K monthly pageviews”, or “drive 500 referral signups”.

The reason this is so critical is that when you review your OKRs at the end of the quarter, you’ll now be able to reflect on not just whether you achieved the output you were seeking (the 15 blog posts), but whether that output actually generated the expected outcome. And if it doesn’t you can have a meaningful discussion on ways to improve the quality of the output to generate better outcomes in the future or decide whether this initiative is even valuable for achieving those stated outcomes. It’s this reflection that happens during OKR reviews that helps to calibrate what initiatives in-fact get you closer to your intended outcomes and thereby helps build your team’s product intuition.

As another example, folks will often have a key result like “launch feature by 7/31”. While that’s a useful key result to have, it should again be paired with an outcome-oriented key result. How do you expect this feature will impact users? Maybe it is expected to “increase D7 retention by 5%” or “increase weekly active users by 10%” or “reduce monthly churn by 15%”.

The reason that teams often only include output-oriented key results instead of outcome-oriented key results is that it’s so much harder to estimate what the outcome will actually be than to estimate the output. The key is to accept that you are going to be wrong a lot and it’s only through going through cycles of OKR reviews that you will improve your forecasting ability.

There are so many types of outcome-oriented key results that you could include. At LinkedIn, we tried our best to tie our OKRs back to one of the top 5 business metrics: signups, monthly active users, sessions, bookings, or EBITDA. Sometimes though, more specific measures associated with a given initiative are more appropriate. For example, maybe you are trying to reduce confusion associated with a given user flow and in that case, a reduction in the number of support tickets received on that issue could be an appropriate measure.

Now it’s not always possible to have an outcome-oriented key result with every objective, especially for initiatives that span multiple quarters. But whenever it is possible, it’s paramount to do so.

Quarterly OKRs

I’ve seen teams define new OKRs every month, every quarter, or every year. I’ve found quarterly OKRs to be the sweet spot. Annual OKRs are too infrequent as you’ll want to update them more frequently based on what you are learning from customers and the market. It also significantly slows down your learning cycle as you’ll only be doing OKR reviews annually. At the same time, implementing an OKR program does introduce overhead. And paying that tax every month is often needlessly expensive and not worth it as you rarely are moving fast enough to see the achievement of outcome-oriented key results in that timeframe. That’s why I’ve always implemented quarterly OKRs to give you the ability to update and reflect on your OKRs often enough while giving your initiatives enough time to actually achieve meaningful key results.

3-5 OKRs

Any team within an organization is best served by having no more than 3-5 OKRs. Part of the value of OKRs is creating focus within a given team. This is only possible if you make the hard trade-offs of which OKRs to include and which to exclude. Keep in mind, OKRs are not a representation of your entire product roadmap, which is often longer. They simply represent the top 3-5 initiatives that are paramount to accomplish. Some folks try to take it to an extreme and only have 1 OKR that the entire team is focused on. I’ve found this to be far too simplistic in practice as any ongoing business has at least several initiatives it needs to make progress on in any given quarter.

Draft Reviews

One of the most important benefits of OKRs is their ability to drive alignment, especially across partnering cross-functional teams. However, to achieve this benefit, alignment has to be baked into the process. I’ve found the best way to do this is for all teams to publish draft OKRs and then allow a one week period for review and feedback. During this review period, it’s important for every team to verify that any dependencies they have on other teams are reflected as a priority in that team’s OKRs. For example, if the product team has an OKR to launch a feature this quarter, you’ll want to ensure the product marketing team also has an OKR to support its launch. Or if the product team is planning on putting together a spec for a new product, you’ll want to ensure the UX research team has an OKR to support any user research requirements needed.

Too often I’ve seen teams just publish all their OKRs at once without this draft period, missing the entire benefit of ensuring alignment across cross-functional teams.

Consistent Scoring Guideline

It’s important that you establish a single consistent scoring guideline across the entire team so that anyone can reliably score OKRs and so the definitions are consistent and clear.

I like to use the following scoring guideline based on achieving each OKR’s key results:

• Green = 100%+ achieved
• Yellow >= 70% achieved
• Red

Read the full article