Objectives & Key Results for Different Company Levels

In this article, I share the most common choices for where to create objectives and key results (OKRs) within an organization, including at the company level only, or for the company and business unit, or for the entire organization. However, just because these are common choices doesn’t mean they’re right for you.

When it comes to deciding where to begin OKRs for your organization, you should give careful consideration to the best group or groups to lead the way on your implementation. That decision will hinge on the following:

• The amount of sponsorship you have at the top
• The availability of strategic background materials
• Your desire to foster collaboration
• Your philosophy on individual involvement in OKR setting

I cover your primary options, those used by most organizations, in the following sections.

There are other areas where OKRs are useful, including pilot groups, projects, and support groups, and while this article doesn’t cover those, you can learn about them in my book OKRs For Dummies.

Creating OKRs at the company level only

First, let me define some terms. When I say “company-level,” I mean OKRs that would exist at the very highest level of the company. So whether you’re General Motors, Netflix, or Uncle Morty’s Wax Emporium, company-level OKRs are those created and used to gauge execution at the very top of the house. Whenever possible (and sometimes it isn’t, as I’ll explain), drafting OKRs at the company level is the preferred way to kick off your efforts.

Some benefits to starting at the top level

Starting at the top has several benefits. Foremost is the fact that OKRs you create at this level make it crystal clear for your entire employee population what you consider to be the most important items for the organization to focus on in the days ahead.

Also, I can’t overstate the communication value provided by these OKRs. Keeping in mind how few people can name their company’s top goals, by creating a small number of OKRs at this level, you send a powerful signal of what employees should pay attention to. You also provide the context that all lower-level teams require to create their own, connected OKRs.

I was going to continue on to drift into my next point but I’m not sure you’d be with me. Your eyes may be seeing the words but your brain may be stuck on something I slipped into the last paragraph: “small number of OKRs.” You’re wondering, “What does he mean by ‘small number.'"

Allow me to turn the tables on you. What do you think is a small but appropriate number of OKRs at the company-level? If you’re like most of the CEOs I’ve worked with, your estimate of the appropriate number of OKRs at the company will be very low, maybe two or three. If so, it’s likely because you want to instill the discipline of focus in your organization, and you’d be correct in wanting this.

However, when it comes to actually drafting the OKRs, if you attempt to tell your story of success with such a succinct number of them, the tendency is to lump concepts together or devise such generic OKRs that they could fit any company in the world, Uncle Morty’s Wax Emporium included.

The number is also impacted by your current situation. If you’re in crisis mode and mere survival is your goal, perhaps one or two well-chosen OKRs is exactly what you need. If, however, you’re in steady-state, moderate-growth mode, you may be able to balance four to seven OKRs.

The old adage “less is more” applies to company-level OKRs. An abundance of OKRs at this level results in a lack of focus and prioritization, causing confusion and skepticism in your employees as to what truly matters.

More benefits of starting at the top

Having settled the number of OKRs quandary, you can consider a couple of additional advantages of starting at the top level. An obvious benefit is the accountability that it yokes to your executives. It is their responsibility to see these OKRs through, demonstrating success that lifts the entire company.

Also, wins at this level will go a long way in generating enthusiasm for OKRs throughout the company. After people see the impact of OKRs at the very top, they’ll be anxious to create their own OKRs, making it clear for all to see how their unique piece of the puzzle fits into place.

Now for the disadvantages of top-level OKRs

Although beginning at the top with your OKRs offers some clear benefits, you should also consider some potential disadvantages before automatically making it your default choice:

• The potential of creating generic OKRs that could apply to any organization: The lack of specificity will greatly reduce the power of those OKRs to inspire lower-level teams, and may in fact signal to everyone that the status quo is just fine and your company’s biggest aspiration is to be like everyone else.
• The possibility that your OKRs will be irrelevant: This possibility comes into play if yours is a very large organization with dozens (or more) of business units around the world, each the size of significant businesses on their own. Think conglomerates with assets spanning the globe. For these companies, job one of the corporate group is allocating resources effectively, and most if not all of the metrics are financial in nature, providing little in terms of guidance or inspiration for lower-level groups.

Prerequisites for company-level OKRs

If you determine that company-level OKRs are the way to go for you, be aware of a couple of “must haves” before convening your C-suite colleagues for a drafting session. The first requirement is access to, and the participation of, your CEO. If you can’t rouse the sincere support of your CEO, you should reconsider not only starting at the top, but starting OKRs at all.

A second prerequisite for company-level OKRs is the existence of some form of strategic plan for the organization from which you can derive the OKRs. They shouldn’t be created in a vacuum. If you’re sitting around a boardroom table engaging in blue-sky brainstorming and pondering, “Hmmm, what should we do?” you have a problem.

OKRs will help answer the question, “To successfully execute our strategy, what has to happen?” but only if you have a strategy in the first place. The word strategy can be tricky, though. You don’t require a 300-page leather bound, gilt-edged report from the head office of a global consulting firm. Some answers to basic questions like, “What do we sell?” will get you on track.

OKRs are a strategy-execution system, not a strategy-formation system. If you’re relying on the process to help you create a strategy, you’re putting the cart before the horse.

Creating OKRs at both the company and team levels

A second option for where to create OKRs is at both the company and business unit or team level, which provides the obvious advantage of involving lower-level groups, thereby upping the odds of execution because more people within the organization are creating aligned OKRs.

Although this section’s heading suggests that OKRs would be created simultaneously at both the company and team levels, there should be some lag time between those efforts. Company OKRs are written first, widely communicated to ensure understanding, and only then, after that context has been created, should team-level OKRs be considered. Most of my firm’s clients choose this option (company and team OKRs) when embarking on an OKRs process.

Deciding which teams and units to include

Should you decide to go the route of OKRs at both the company and team levels, your next order of business will be defining the word team. I’m using that word in a very generic sense because as far as I know, no universal terms exist for creating a company’s organizational chart. For example, engineering and IT may be business units at your company, or they may be called departments, squads, or teams.

Rather than focus on the titles appearing on your org chart, a simpler approach is to determine how far down the chart you want to go with your initial foray into OKRs. Maybe it’s the first level, those reporting directly to the CEO; or perhaps you’ll go two levels down on the chart. The obvious caveat is that the deeper you go, the more complex your rollout becomes, and you need to carefully consider how much complexity you can take on as you’re getting your feet wet with OKRs.

A phased approach, going one level at a time, is the most conservative and likely the safest route; my experience shows that most organizations are excited to expose as many people as possible to the power of OKRs. Thus, going deeper faster has major appeal.

Deciding between following the org chart or linking dependent teams

If I had been writing this book back in, say, 2016, this section probably would have ended right here. Pick your teams and swish-boom, move on to the next section. But having worked on hundreds of engagements with organizations all over the world, I know it’s not that easy.

You have another fundamental question to answer after you’ve chosen who will create OKRs at the team level: Do you write OKRs based simply on titles in the org chart? For example, Sales would create Sales OKRs, Marketing would create Marketing OKRs, and so on. Given its simplicity, this approach was the default answer for many organizations as OKRs rose to prominence, but a downside quickly emerged: Creating OKRs in this way had a tendency to reinforce silos and discourage cross-functional collaboration, which is anathema to the spirit of OKRs.

Simply following the org chart may not be your best alternative for drafting team-based OKRs. Another option is to find teams that are highly dependent on one another and create OKRs for the merged entities.

For example, in most organizations, the Sales and Marketing teams must work closely together in order to drive demand and revenue. Marketing finds the leads and supplies media and collateral, which supports Sales’s efforts to convert interested onlookers into paying customers. In this case, it could make sense to create OKRs for Sales and Marketing as one cross-functional unit, which of course enhances collaboration and diminishes the silo mentality.

A potential challenge with the dependent-teams approach is the fact that in modern organizations, the pairings aren’t likely to be so clean because of the vast web of interconnectedness among most teams operating today. When I ask teams who they depend on for success, they rarely isolate their response to one other team. There’s often a dominant partner, but other dependencies exist as well.

In deciding whether to use the dependent-teams method, determine whether the core relationship or partnership among two teams is strong enough to warrant working together on creating merged OKRs. In other words, if they can’t be successful without one another, there is a legitimate case for merged OKRs.

Creating team OKRs for customer segments

And now, in the spirit of a 3 a.m. infomercial peddling that hydrospa hand massager you just can’t live without: But wait, there’s more! You may also want to create team-based OKRs in reference to specific customer segments, or points along the way of the customer’s journey with your company.

An online retailer, for instance, could create OKRs for teams aligned with the checkout process, or the subscription process, or something else. Doing so has the advantage of driving collaboration among teams devoted to a specific outcome, but on the flip side it’s not immune to the difficulty of ensuring that the relationship between the groups is strong enough to warrant shared OKRs. (In case you’re wondering, I didn’t make up the hydrospa hand massager; QVC really did sell them at $40.)

Creating individual OKRs for the entire organization

Encouraging OKRs at the organization-wide level includes, of course, the controversial practice of having individual OKRs. You may be thinking, “Google uses individual OKRs, right? So shouldn’t everyone?” And besides, is the question of using individual OKRs even up for debate, and what makes it a “controversial practice”?

Yes, Google does it, but you may not want to

Google, the poster child for all things OKRs, does have a history of using the framework at the individual employee level, but you have to keep in mind that OKRs were literally baked into the culture of Google practically from day one through John Doerr’s influence with the founders.

The system grew along with the company and has become an ingrained part of their culture, which is something most organizations cannot say. But even within the Googleplex, there are whispers of discontent over the practice, and some question its value. Most organizations should consider individual level OKRs optional, if they consider it at all.

If you do believe that individual OKRs are right for your company, it’s most likely because you can envision the system driving alignment throughout the entire enterprise. You also likely subscribe to the notion that giving employees the chance to write an OKR will boost their support of the system because they will no longer see OKRs as a “corporate thing” but something that they themselves engage with and can potentially benefit from. Both are valid points, but on the “pro” side of the ledger, that’s all I’ve got. Switching to the “con” side, however, reveals a host of potential problems with individual level OKRs.

I’ll use an example of an individual OKR to introduce some challenges with the practice. Following is one from a software engineer — and I’m not picking on engineers; I’ve seen similar (in tone, style, and direction) from finance professionals, marketers, HR staff, you name it:

Objective: Improve my programming skills to help the company release products faster.

Key results:

1. Read the five most popular books on programming on Amazon.com.
2. Take three courses on programming languages.
3. Attain Oracle MySQL certification.

When charged with creating OKRs, most individuals will automatically default to personal development goals like those above. Absolutely nothing is wrong with personal development, and of course everyone should be actively encouraged to set goals for improvement.

However, if you’re hewing to the true intent of OKRs, your aim is to demonstrate business impact. The key results in the preceding example are binary “outputs” that fail to demonstrate how this programmer is contributing to the company’s goal of releasing products faster in a quantitative fashion.

Determining and communicating your OKRs philosophy, whether or not you’ll allow personal development goals as part of OKRs, will help ensure consistency in the OKRs created across the organization.