At the most basic level, the “Objectives and Key Results” (OKR) framework helps organizations hit agreed-upon goals. Most people know that Google has embraced OKRs and the company’s leadership has been a vocal evangelist, but the framework itself dates back to the 1970s Intel.

I don’t purport to have something novel to say about OKRs, but I have found most of the literature is downplaying one aspect of the framework. In organization after organization I’ve seen leadership get excited about OKRs and go full steam on their implementation, only to have the practice fizzle within a year or so. What’s going on and is there anything organizations can do to avoid this fate?

Tech ❤️s OKRs

It’s not surprising that many tech organizations love OKRs. Google (and other companies that these organizations look up to) uses them. The framework seems sensible – fairly simple to describe and use, flexible to adapt to any organization, yet recognizable by most leaders. Maybe most notably, it is a technocratic framework – as the mantra goes, you can’t manage what you can’t measure, and who wouldn’t like to build a system organizing work around these units of measurement?

Yet so often OKRs end up forgotten, or – worse – maintained as a kind of ghost ritual; countless leaders and project managers going through motions not getting any apparent value. The uncomfortable truth is that companies find it easy to cargo cult OKRs, believing that they will achieve success if only they follow the mechanics. OKRs might be easy to understand and track, but is it surprisingly difficult to make them an integral part of a company’s or a team’s operations.

What usually goes wrong

Over years of doing post-mortems, I’ve identified some themes:

• Most often, OKRs are disconnected from what teams actually do, day to day. They form a parallel track for a number of reasons – because the department head asked to have them, or because the team wants to appear mature, or because everyone genuinely wants the framework to be helpful, but they don’t know how. If your team finds itself switching context when talking about OKRs, it has probably decoupled the OKRs from its operation. A good litmus test is to ask yourself how much of what you (or your team) does every day actually rolls up to one or more key results. Note that it’s not necessary to have a perfect overlap – OKRs are not meant to be an exhaustive list of work – but if the intersection is small, you may want to rethink your OKRs
• The OKRs are poorly framed – either too vague to be useful (it’s unclear what success looks like, or they don’t help teams make decisions), much out of the team’s control, or too aspirational. With OKRs, there definitely is an art of fine-tuning their many parameters. I’ll touch upon it later. A good way to detect this failure mode is to watch for the number of miscommunications and misunderstandings around the meaning of the OKRs and the team’s standing relative to them
• Teams give up too soon – they don’t adjust their framework (or even the goals themselves) and become disillusioned with OKRs’ ability to align their work. There is, I believe, a misconception that once established, both the goals and the framework itself are set in stone. This couldn’t be further from the truth. Especially early on, as the team calibrates their OKRs, changes are both fair game and likely expected. A more prosaic issue is teams simply not finding the time (or the discipline) to learn from their experiences
• Most fundamentally, teams often simply don’t know what the OKRs are supposed to be used for. Often, it’s well-intended ignorance: teams believe OKRs are a management tool, or a tool to “report upwards”. They see it as a way to standardize progress across departments. Sometimes, they suffer from the “zealot” problem – one team member is so invested in the OKRs that they end up imposing too much of their own understanding on the OKRs, thus losing the rest of the team in the process

So, what are OKRs for?

Read the book, it’s good. But if I were to summarize in a way most helpful to me and my teams, OKRs are a class of strucures that aim to

• Align teams externally (between each other in case of dependencies, to clarify the mutual commitments) and internally (so that everyone rows in the same direction). Specifically they can be a good mechanism for leaders to streamline the communication of top priorities and progress
• Help teams be more intentional about what they do (including helping them answer the question of what not to do)
• Be a forcing mechanism for work that would otherwise not get done, either because it’s “important but not urgent” or because it may otherwise slip through cracks
• Be a forcing mechanism for teams which are not innately metric-driven and are challenged by tackling vague goals, or by a lack of conviction in whether the work they did is “complete”
• Hold teams honest about committing to real work, and help them assess objectively how they did

Ask yourself: What do you want to get out of OKRs? My advice to teams is to avoid the kitchen sink problem – the OKRs seem robust and versatile enough that they could be used for any of the number of purposes, but that doesn’t mean that they should be used for all of them. Of the goals above, think about what you would most like to accomplish. Start with this, set up and fine-tune your OKRs accordingly, and then evolve them as your needs change.

OKRs are flexible, offering a number of degrees of freedom. The downside is that sometimes you may find yourself wondering if you need a PhD in OKRs to make them work. Don’t overdo it – focus on the biggest levers first, and then fine-tune later. To begin with, questions you should ask yourself are:

• What is the time horizon? Do we set monthly goals, quarterly, or annual?
• What is the reporting unit? Are OKRs individual, specific to a team, or the entire department (or a company)? Are they supposed to “cascade” between levels?
• What does success mean? Is it accomplishing 50% of the key results? 75%? Is it okay to accomplish all the key results but fail at the overarching objective?
• What are the semantics – what “goes into” OKRs? Is it all the work we do? Work that affects business outcomes? Work that the team wouldn’t normally get to?
• Should the objectives / key results be in our control or not necessarily?
• How many should we have?
• How frequently should we update them and talk about them?
• How strictly quantifiable should they be? Are “zero-to-one” key results okay? Is it okay to ask for sentiment?

Often I’m asked for what the answers should be to these questions. While each organization likely has its own “sweet spot”, here are some guidelines around these based on what I’ve seen to work particularly well most of the time, regardless of circumstance:

The foundation

• Purpose: I like to use OKRs to capture work that would otherwise not happen, and work that requires above-average coordination. I ask myself “what would the team achieve in a scenario where we didn’t have OKRs?” and make sure the OKRs add value incremental to that picture
• Semantics: Objectives capture outcomes which are meaningful to the business or department, and are not necessarily fully in the team’s control. The key results are always quantitative (but could be a binary metric “this thing was shipped” or a sentiment “when surveyed, 80% of developers agreed with…”) and are mostly in the team’s control. It is therefore possible that all the key results are complete, but the objective is not met.
• Definition of Success: If the team accomplished 75% of the key results, I would consider that a success. The benefit of having a “stretch zone” is that it makes it less like that the team under-shot, but 75% is still high enough where getting there feels like an accomplishment.
• Length: 3-5 objectives, 3-5 KRs each. Ideally not more than 20 total. It is tempting for teams to inventory all work they have to do as OKRs. This is missing the point. A long list like this is challenging to maintain, difficult to get an intuitive grasp of status of, and likely means that the team isn’t seeing the bigger picture and instead is focusing on a “laundry list” of tasks
• Scope: Individual OKRs feel too technocratic. Department-wide may be helpful, but they will be definition play a different role – for example, they will likely emphasize work that is horizontal/shared between groups. The area where OKRs are probably the most natural fit is at a level of a business unit, or a sizable product team
• Frequency: Quarterly feels like the right sweet spot of “able to move the needle” and “able to iterate on and get learnings from".

Rough guidelines

In addition to this, I often share my advice with teams. These probably vary a lot more from team to team.

• Don’t try to be too cute connecting company OKRs to team OKRs. It’s helpful if there is a “by and large” connection, and it’s OK if you need to use a narrative to make that connection. After all, that is one of your jobs as a leader
• However, it’s very helpful if you are able to use the same set of OKRs across different functions responsible for an outcome. For example, inside a business unit, I like having a single set of OKRs, rather than “business OKRs” separated from “tech OKRs”.
• Penalize unfinished work. Given that our goal is to get to 75% of all key results, it’s okay to be a bit more strict on the completion criteria for a given key result. A binary score (team gets credit only if they hit a target) helps teams design more robust key results
• Don’t fall in love with what’s measurable. Often teams consider only key results which they can access the metrics for. While this is often good, there are times where the lack of an already-exposed metric makes you consider suboptimal key result framing
• Don’t fall in love with the tooling. There are a lot of tools on the market that let you manage OKRs. Fortunately, you don’t really need high tech for this – a simple spreadsheet will do. In fact, sometimes leaders get enamored with fancy tooling, which distracts them from needing to come up with solid OKRs
• Finally, consistently with the spirit of post•technical, don’t overgeneralize the objectives. You don’t have to frame an objective in the most generic way possible, and you don’t have to be consistent between objectives. Objectives which are too abstract won’t be understandable and you’ll lose your audience.

Communicate and over-communicate

Another mistake teams make early in their OKR journeys is thinking of the framework as something to set up and keep on autopilot. A major factor (and obstacle, if not done well) to adoption is continuous messaging and weaving of the OKRs into the team’s day-to-day. This includes:

• Spending enough time educating the team about what OKRs are for, why they matter, and what the various terms mean. This includes ongoing onboarding of new team members. Setting aside enough time to answer any questions they may have
• Sunsetting any other “general planning” frameworks that are different from work backlogs. Any other “goal” framework is likely to confuse the team and cause “administration fatigue” This poses a potential dilemma where some goals from your alternative framework are omitted because you’d want the OKRs to be manageably small. One technique is to try to use aggregate key results in the OKRs that capture several of these goals. Another option is to rethink which goals you really need to track and why
• Make sure you format your OKRs as a one-pager that is easy to project on a screen. Any reasonable opportunity you get, put the OKRs up for the framework to “burn in”, include in status update emails, keep up on a monitor in the office
• Celebrate OKR wins – if a key result was met, or if the team hit the 75%
• Bringing up OKRs as a way to help the team make prioritization or scoping decisions
• Using the language/concepts implicit in the OKR framework in everyday meetings and communication

Iterate

Finally, it’s important to realize that OKRs are not an overnight success. It takes approximately four iterations to get it right. Ask yourself if you have the patience, and if you can guide your team to show patience as well. (Alternatively, if you are looking for a quick win, maybe you would be better served by a different framework).

Do retrospectives after each cycle – not just about the goals themselves, but also about the framework. Was it easy to absorb and use? Did it confuse people? Did it achieve its stated purpose? Overall, did OKRs provide value to your team? A good way to answer that question is to envision what would likely have happened if you didn’t have the OKRs written down and tracked. Ask your team members for specific feedback (anonymous if that gets more candor); ideally, they would be able to share specific, personal anecdotes and learnings.

★ ★ ★

OKRs are a great framework that has stood the test of time. They are deceptive straightforward – there is a lot of nuance and complexity in the various parameters you are able to tweak. They do take some effort to maintain, but when done well, they are worth the investment. They can help you align your team members and other teams, convey the goals to your team, and get you results that would otherwise not happen. While OKRs generally don’t “backfire”, there is a decent chance that they will end up being a waste of time for you and your team, so it’s worth shaping them with your team in mind and organically integrating them into your team’s day-to-day operations. And if you do it well, the best endorsement of the framework’s success in your organization is having your teams adopt them voluntarily and unprompted; and the framework feeling obvious and boring yet essential like your email or a chat system.