I'm Brett Slatkin and this is where I write about programming and related topics. Check out my favorite posts if you're new to this site. You can also contact me here or view my projects.

15 January 2014

Do OKRs work?

Recently a friend asked if Objectives and Key Results (OKRs) actually work. Presumably their startup is considering using them. Google is well-known for using OKRs (video and helpful summary). I guess I've formed an opinion about OKRs from the experience of using them in different ways on multiple teams over 8 years.

Here's my reply to that email with some edits for clarity:

Overall yes, OKRs work. Transparency is good. OKRs are a good way for team leads to express vision to a whole group and make it clear what your combined goals are.

The real purpose of OKRs, in my view, is to make it so the members of your team can anticipate what to work on next, or what is the highest priority, or why you're making the choices you're making. You never want someone to ask "what should I be doing next?" or "is A more important than B?". That should always be obvious based on the vision you've agreed to as a team. If it's not clear that's your fault not your teammate's.

I find OKRs on smaller teams lead to micromanaging (especially personal OKRs). OKRs are stupid when the key results are "launched" or "project does not fail". If you have sales numbers then it's easier (Objective: Grow revenue by 50%; Key Results: Sign up 200 Llama video producers, Increase viewership by 10x).

I believe quarterly goals are too slow. On my team we do 6 week milestones. We have a list of "must have", "would like", and "nice to have" goals for each period. The lists are primarily key results because objectives are obvious. Each milestone is the exhaustive list of everything we should be working on as a team, including stretch goals. If it's not on the list, you probably shouldn't be working on it (unless it's a bug, interrupt, 20%, prototyping, etc).

We don't expect to finish everything. That lets us reset our trajectory as we go along. Any faster than 6 weeks seems too often because shit just takes about that much time to actually do. Any slower is too infrequent and people end up adrift or over-designing things.

We've tried to grade the milestones like OKRs. They end up being 50-60% complete (as OKRs often are). So we usually shoot for getting ~2/3rds done. We're often pretty close, so that part of the exercise is less important, but it helps transparency for the team to understand our velocity.

As my friend summed it up:

  • OKRs are an effective tool for communicating priorities to teams.
  • Be wary of using them when things are too early to measure effectively.
  • 6 week timeframes work better for smaller teams in my experience.
  • The difference between "key results" and "objectives" can be confusing.
© 2009-2016 Brett Slatkin