What I hate about OKRs, and what to do about it.

5 tips on operating with OKRs.

Note: it turns out writing a newsletter with a full time job can have its ebbs and flows, first post in a while!

---

Like many leaders, I have a love/hate relationship with OKRs. At the same time, I’ll assume they’re here to stay in many organizations, so this post focuses on what I dislike and pairs that with tips on how to handle.

1. OKRs often get confused for strategy. One of the most common mistakes I’ve seen is teams that confuse their OKRs for a broader strategy. If you observe this happening in your organization, my advice is to suggest that the two rituals get disconnected from each other. Defining strategy comes first. If you’re doing some version of M-Shaped planning, the strategy often comes in the form of top-down guidance. Either way, your strategy should be an intentional and principled answer (or a clear hypothesis) to a challenge facing the business. Your OKRs are the actions you’ll take to deliver on that strategy.

2. OKRs can facilitate tree-gazing, while the forest burns. Another failure mode of OKRs is being overly focused on finishing the OKR you set 2 months ago, while new or more important fires have started to burn. Great product teams learn new things each week, which means OKRs can become less important or obsolete. My advice here is to have a clear process for OKR changes that occur mid-execution. To do so, teams should be un-apologetic in removing OKRs where priorities have changed and setting new ones based on the latest game on the field.

3. Your OKR planning takes too long. It’s a natural tendency to want to forecast accurately and set good goals. But if it causes planning to drag on, it inhibits execution. My advice is to be wary of when you’ve reached the point of diminishing returns on goal setting, and don’t let perfect be the enemy of good (and executing). My Engineering partner, Oliver Heckmann, and I talk about the 10% planning rule to enforce this principle. It’s a good constraint to put on your planning and OKR process.

4. Implementing metrics for OKRs often takes disproportionate time. If you’ve regularly set OKRs, you’ve seen the pattern of having X’s and Y’s as placeholders for numbers. And a common question in our OKR reviews is — ‘when will we have X and Y filled in?’ If setting and implementing metrics is taking a disproportionate amount of your execution time, you often have two main options. First, you can get more people or resources focused on data. Or, you can choose a smaller set of metrics to implement and track. In my experience, the latter is almost always the better path.

5. Too often, OKRs are eagerly set and promptly forgotten. Ever looked at your OKRs mid-quarter and realized, ‘shit we haven’t done anything about this one.’ You’re not alone. My advice for preventing this pattern is to bring OKRs into the same place where your team is doing the work. For teams using Coda, that often means embedding company tracked OKRs into their team hub. There are many ways to do this, but you’ve got to figure out some way of pulling OKRs into the ongoing cadence and artifacts that the team lives in everyday. Another way is to automate sending out your metric or OKR dashboard, instead of relying on busy people to regularly visit it..

If you’re interested, I also compiled other planning learnings in the the Product Handbook we compiled in the last few months.

What’s your experience with OKRs? What do you dislike and how do you get around it?