Building Strong OKR’s

Problem

Teams say that they want to be empowered, but when everything is in front of you, it's really hard to make decisions, defend them, and show how you measure against them.

Actions taken

• The simplest OKR's are the best ones. I spend a lot of time with my teams distilling down their OKR's. I steer them away from flashy words and big adjectives that take them away from what they are actually doing.
• We participate in OKR drafts in a Google Doc that everyone reads and comments on so that it is understood in simple terms by all.
• With metrics, I like to put myself in the mindset of a product manager and work with my product counterpart to decide how the feature is being used and what is most important. I then use that as part of my key results for the things I want to measure while trying to achieve those objectives.

Lessons learned

• The two questions of 'what you are doing' and 'how you will measure it' are extremely powerful. Those who are really good at explaining the impact know how to write their OKR's in a way that is simple and easy to measure. If a non-technical person can't understand what you are doing you have not written your OKR well. Technical background or not, we are all shareholders and fully empowered to make the decisions around what we want to build within a set of constraints and governance.
• I have been in organizations where you do the feature and then you make sure there are enough metrics on it. It doesn't work that way. Unless you've defined the business impact of what you are looking for in your metrics and logs, then it's just a bunch of garbage data that is being spewed out.
• I am really impressed with how many conversations that were originally happening after features had already been built are now part of a Google Docs document early on in the cycle.

"The simplest OKR's are the best ones."

"The two questions of 'what you are doing' and 'how you will measure it' are extremely powerful."