Panji Gautama

Talking about OKR

Why do we care about OKR ?

Managing a company’s performance relative to goals is important. OKRs (Objectives and Key Results) have been found by the tech industry to be a good way to do that. See https://en.wikipedia.org/wiki/OKR for a history of OKRs. See Measure What Matters, by John Doerr for a great read on how they started to be used at Google.

By using OKRs correctly, we can align both within groups and across the company on our strategic direction and our tactical implementation of that direction. We can also chart how that direction changes during a period, and we can measure ourselves on how we did. Just like a feedback-and-performance culture is imperative to have at the individual employee level, it’s also essential to have at the team/group/org/company level.

OKR Creation

Creating OKRs should be a natural part of leading your team. OKRs, at their essence, are a way of understanding company priorities, planning what you’re going to get done, communicating that to others, tracking what others say they’re going to get done, and then everybody getting together and saying how they did. That’s just good leadership.

An OKR list can be in the Wiki / CODA, a downloadable Google Drive Word Doc or Excel sheet, or a Gdoc file, among other things.

Definitions and Guiding Principles

Grading OKRs

Objectives are not gradable, as they are meant to be worded in a way which doesn’t reduce to numeric or binary measurement but is instead visionary. However, each Key Result must be gradable - to see whether the “Key Result” was achieved.

When choosing the value of the KPI(s) to be used to grade the KR, the value(s) should be set slightly above what the teams think they can achieve with the current and expected/planned software quality and operational procedures. Achieving this result means the KR has been achieved. Most KRs should have a (subjective) 70%+ chance of being achieved i.e. they should not be certain, but still be somewhat stretch goals. In return, leadership and stakeholders understand that the business goal of KRs is not to grade employees, which will produce negative outcomes, but is instead to produce both the right leaning forward behavior and won’t look for more than 70% completion as successful delivery. I.e. a culture of being proud of being right and proud of being aggressive on goals vs a culture of being scared of being found wrong and graded - which will produce a culture of sand-bagging and conservatism. Nothing we do at our current company is sure, and pretending that we can set goals that are sure of being achieved is the path towards slowness and mediocrity . If something that would not have been reasonably predicted and was largely out of your control happens that makes you miss a KR or Objective that you and your team won’t be unduly penalized.

Each team is also encouraged to put forth Aspirational Key Results (AKRs), which are results which would happen if either the team was very lucky, or if their operational excellence efforts paid off handsomely. The AKR is meant to be the North Star of what the team would like to achieve to delight customers.

One incorrect assumption is that each KR should automatically be better/more strict than the period before. This is not true. For the good of our business and our customers, we may make short-term decisions to sacrifice small amounts of stability for longer-term/strategic goals. Or, we may make a mistake and deploy something which makes the service fundamentally less stable - and need to fix it. As stated above, the goal of the KRs is to reflect the reality of what our current software and operational procedures can provide, while incenting every team to be better in order to delight our customers.

Writing OKRs

Writing an OKR is reducing to written form what you probably already know on your head. That said, having something that you can focus on, track, and that others focus on and track the same way can be challenging. It breaks down into 1) What Objectives are you trying to accomplish, 2) What Key Results will you create to show you have? I.e. what do you need to change to accomplish that, and 3) What Key Performance Indicators will you use to prove the Key Result has been achieved?

What Objectives are you trying to accomplish?

These are your Objectives.

What Key Results will you create to show success?

In order to accomplish your Objectives, something almost always needs to start, stop, or change in some way:

These are your Key Results.

Note that even for these, you should resist the urge to get too much into the “how” - i.e. specific features. Delivering a Feature or Task list is not a Key Result - rather, the outcome of the Feature or Task list should be. Deriving the feature or task list that will achieve the Key Results should be left to your team and you as your brainstorm and should be flexible during the OKR period. Using the example above, if you think that you can increase the NPS by doing one thing, but halfway through the period, you come up with another way, that’s totally ok (and in fact encouraged) - because you’re still accomplishing the Objective - and the Key Result was to increase NPS.

Resisting making your KRs a list of tasks or features is the hardest part of writing OKRs for most people.

What Key Performance Indicators will you use to prove the Key Result has been achieved?

Things that can be easily and precisely measured and that show whether a Key Result has been achieved are your KPIs.

<< Previous Post

|

Next Post >>