Pros and cons for implementing OKRs

02 September 2014

A year ago, the startup I was working at decided to adopt the Objectives and Key Results system, or OKRs, to help us set goals and manage projects. This was an interesting change to watch, especially because it was a significant transition from our previous system, which was much less formal. I wanted to jot down some notes and thoughts I had about both the OKR system and transitioning to it, from the point of view of an employee.


The OKR system (Wiki here) was invented by Intel and has been used by other tech giants like Google. It involves setting some major Objectives that the company wants to achieve, with each Objective having some Key Results that, if achieved, will mean that you achieved the Objective. The Objectives are meant to be larger ideas that you want to achieve and do not necessarily have to be quantitative. For example, one might be to "Diversify our sources of revenue", but another could be "Double revenue". The Key Results are meant to be quantitative goals in pursuit of the Objective, such as "Establish one new revenue stream worth $10,000 per month."

There are a couple of additional nuances that make OKRs unique. One is that Objectives are not meant to be 100% achieved. In fact, they're supposed to be ambitious, representing "stretch" goals that are on the edge of being impossible. Key Results can be similarly ambitious, but must be measurable, in order to provide objective grading.

Another nuance is that OKRs are nested both in terms of time and in terms of who holds them. Temporally, a company might set an annual OKR, which is then split up into quarterly OKR cycles. After a company's OKRs are set, groups / departments within the company set their OKRs in a way to best help the company achieve the overarching OKRs, and then individuals set their own OKRs accordingly to support their team's.

At the end of the OKR cycle, you grade your performance towards your OKRs on a scale of 0 to 1 for each Key Result and Objective. Because the goals are all supposed to be ambitious, Google targets scores of 0.6 - 0.7. But in reality, the scores aren't supposed to matter as much as the thoughtful process of setting goals and using them to guide your work.

The startup I worked for used to have a much more informal system to deal with this kind of goal-setting. There were certainly company-wide goals, but these were not necessarily publicized that well. We had two-week sprint cycles, and the projects for every cycle were determined somewhat by the leadership (who knew what should be prioritized, and who had new ideas to try) and the employees (who could submit ideas and request to work on certain areas). There was not as much public, collective thinking about what the company's medium-term goals were, and not as much deliberate planning as what OKRs encourage.


Our company learned a lot about setting and working towards OKRs. We kind of dove right into the system on fairly short notice, and we were eager to iterate on the process and improve on it every quarter. Here are some key learnings that I saw, both from watching the company transition and from being an employee who worked under the new OKR system.

If you're still a young startup, or coming from a much less formal goal-setting system, you should probably not set annual OKRs at the beginning.

It's tricky to set annual Objectives for the company, since a year is a long time for a startup. If you didn't have something like annual goals before implementing OKRs, you might consider starting with just a quarterly OKR, so that everyone can adjust to the new system. By trying to work towards just a quarterly OKR, you will probably also learn what is truly important to your company at this stage, which will better inform annual OKRs.

Objectives should be implementation-agnostic.

What I mean by this is that specific projects or feature ideas should probably not be explicitly built into Objectives. Rather, they should be Key Results to support a more abstract Objective. For example, something like "Build a Bayes Classifier-powered tagging system" shouldn't be someone's Objective, because who knows, maybe a Bayes Classifier isn't the right way to go about the problem. Instead, the Objective might be "Make our content database richer", and a machine learning-powered classifier can be a Key Result to support that Objective.

Any metrics referenced in Key Results should be very clearly defined.

Some metrics, like "AWS Costs" for example, can be straightforward. Others, like "Revenue" are generally straightforward, but might require some clarification (e.g. do you only want recurring revenue, or are one-time items going to count as well?). Then there are metrics like "Search success rate" which your company needs to define and then periodically measure. Any of these metrics are fine to use, but everybody has to be on the same page about them.

People need to have access to frequently updated OKR metrics.

This is a no-brainer, but if your OKRs rest on certain metrics, people in the company need to know what those metrics are. This can be tricky for metrics that are hard to calculate in real-time, or which require a lot of manual work to calculate. But without this knowledge, people can't be sure if their efforts are making any difference.

"Joint" OKRs are ok, but clearly define how the relationships work.

Sometimes it's unrealistic to give a project to just one person. A new feature, for example, might require input from a designer and an engineer. In cases like these, two or more people can "share" an OKR, as long as the involved parties understand how the relationship is supposed to work. Is the designer going to come up with all the mockups first, and then the engineer comes in? Are two engineers going to pair code on the project together?

The numbers you use in OKRs probably won't add up, but it's ok.

You might set a quantitative OKR, such as "Increase revenue by 50%" this quarter. When you're setting Key Results, you might be tempted to assign each Result a target percentage of growth; perhaps you have five Results that each contribute 10% growth to revenue. You will then enter a strange zone where you spend time thinking about how to distribute the overall 50% among the different Results. This is ultimately not that useful, because why should one result reduce the potential revenue goal of another? It's fine to have the cumulative impact from all the Results add up to more than the Objective. You don't want the opposite situation though, where your Key Results don't cumulatively add up to the Objective.

Get input from your employees; more input is needed the closer you get to that employee.

Company-level OKRs will probably be set by the leadership of the company, because they have the highest-level view of what everyone is doing and the different pressures on the company. However, as you set group- and individual-level OKRs, you will want to get more input from the relevant employees. The leadership can try to just dictate all OKRs at all levels, but I bet employees will find this demoralizing and confusing. There is potentially a lot of upwards feedback that can be very useful in establishing OKRs.

You have to move quickly during transitions between OKR cycles.

By the temporal nature of OKRs, you will have to announce when OKR "cycles" end. However, this means that everyone will know exactly when a cycle ends, and when that last day comes, they will want to know what happens next. Reflection on last period's performance is integral to the OKR period, but this reflection needs to be fairly snappy. Be careful about losing all momentum between OKR cycles, as people slowly finish up "old" projects and hesitate to start "new" projects without knowing what the new OKRs are. If the OKR cycles are quarterly, for example, having even a week of reflection and re-orienting between cycles might be too much time.

Be careful in how you define OKRs for "scrappier" projects, so as not to stifle innovation.

OKRs are good for established areas of the company, but they're not as good for the unknown. Perhaps your company is looking for the "next big thing", and you have a couple of ideas that you are trying to validate and build out in a scrappy, lean way. If that's the case, be careful about how you define OKRs relating to those less-established ideas. You don't want to necessarily elevante an unvalidated idea to the level of an Objective, because perhaps the idea will be dead in two weeks.

OKRs will set the priorities and thus the tone of the company for significant periods of time, so be careful.

OKRs are a powerful communication tool, so you have to be careful about what your OKRs are saying. For example, it's completely sensible at certain times in a company's life to set revenue-based Objectives for the entire company. But, setting a revenue-based OKR means that in that time period you will frame your decisions based on revenue. You can see how this might have negative implications for the product if carried to an extreme. In a situation where product or UX considerations are at odds with revenue considerations, there's usually some compromise needed or a sensible middle ground that can be taken. However, the company's current OKRs might be enough to tip the calculus, because people will (rightly) be influenced by what they think they're being measured on. That's why choosing the OKRs, and how those OKRs are phrased, is a very important and delicate exercise.

comments powered by Disqus