Are you doing OKRs right?

I recently caught up with a ex-colleague of mine, Ken Norton. I’ve always admired Ken and I’ve learned a ton from him over the years. In this interview, we go deep on one of Ken’s area of expertise: How to set great OKRs (Objectives and Key Results) for your team.

Ken Norton is a Senior Operating Partner at GV (formerly Google Ventures). He works with portfolio companies on areas related to people, process, product. Before GV, Ken was a product manager at Google where he was responsible for Google Docs, Google Calendar and Google Mobile Maps for Android.

BK: How did you get involved with helping companies set OKRs?

My role is predominantly to work with the 300+ companies in the GV portfolio. It tends to be a lot of coaching of founders and CEOs. And it’s a lot of help thinking about hiring and organizational structure, particularly as it relates to product leadership, engineering, and design.

As companies grow, they reach a stage where there are just a lot of people. It becomes harder to make sure that everybody in the company is rallying around the things that are really the most important. I spend a lot of time with these companies thinking about how to do that. One tool is OKRs, which we've used for a long time at Google.

OKRs make sure the company is staying ambitious, setting objectives that are measurable, and that everybody in the company knows the few things that are most important.

OKRs should be focused, ambitious, and measurable

BK: What makes a good set of OKRs?

I think whether it's OKRs, or something else like OKRs, they accomplish a few things:

1. OKRs are a way for the CEO to set direction for the company — the very small number of things that are most important for anyone to be focusing on. OKRs aren't a big task list. They're not a project plan. They're very, very few in number.

2. OKRs are really ambitious. They're things that are not easy to achieve. They're not sales targets. They're not quotas. They're big, hairy, audacious things that you want to force everyone to aim for, knowing that it's outside their comfort range.

3. OKRs are actually measurable, so you'd know when you got there. It's not, “We want to have a happier user population” or, “We want to have a more delightful user experience”. Those are great, but unless you know how to measure them, you don't know whether you accomplished them or not. A key component of OKRs is that you can look back and say, “Did we achieve it and how much of it did we achieve?”

Whether it's OKRs or something else, if a company has a way to consistently set priorities, measure them, and make sure that they're ambitious, that has a kind of trickle-down effect.

Build OKRs with a combination of top-down direction and bottom-up feedback

BK: You mentioned that OKRs are a good way for CEOs to set the priorities of the company. Are OKRs a top-down tool for dictating what teams do? Or is there a component of bottoms-up as well?

OKRs work most effectively as a combination of both top-down and bottom-up. It’s a combination of the CEO setting direction, and the team responding by deciding what that means for their individual products or business.

Ultimately there is a top-down part to OKRs because the CEO's job is to lead the company and to decide what direction the company is going. If that doesn’t happen, the bottom-up part is not going to work.

OKRs can't be purely top down because that feels dictatorial and it doesn’t lead to an engaging and fun place to work. And OKRs can’t be only bottom-up because there has to be a sense of direction and strategy for the company.

In the early days of a company, everybody kind of gets everything through osmosis. You're around the CEO, you sit next to each other, you're all friends. Everybody knows what's in the CEO's mind. But as the company starts to grow, that just inevitably becomes impossible because there are just too many people.

Resist the urge to make OKRs too granular

BK: How many levels of OKRs should a company have?

OKRs really shouldn’t go too deep. For most teams, company-level OKRs are probably fine. As the company starts to grow, it may make sense to do team level OKRs. But those teams should not be functional teams, they should be product or mission teams.

Don’t create engineering OKRs, product team OKRs, and marketing team OKRs. That doesn't make sense.

BK: But a lot of companies do have OKRs for each function. Why doesn’t this make sense?

I've seen it create two problems: One, it starts to disconnect the functions. We don't work by separating ourselves into functions and going off in a corner to do engineering, or design, or marketing. We do work by getting together and actually building something.

The more the team construct looks like the way your users or your customers see the world, the easier it is to remember to focus OKRs on what ultimately matters for that. If you decompose OKRs too much into these functional parts, you start to lose sight of the ultimate goal. What are we really trying to achieve? What problem are we trying to solve?

BK: I've noticed that OKRs tend to get more granular over time. A company might start with company-wide OKRs, but in a few years they’ve expanded to hundreds of tiny team-level OKRs. Why does this happen?

To a certain extent, the reason OKRs become so granular is that you become drunk on them.

It intuitively makes sense that we should write down all the things that are important. But as you start to get deeper, as you start to get lower, there’s a temptation to expand one company-level OKR into five more. That has a compounding effect. And when there are literally a thousand OKRs in the company, it doesn't help.

There’s also another danger: The more you start to get toward individual OKRs, the more inevitably they become individual performance metrics.

Part of what makes OKRs powerful is they're completely divorced from individual performance reviews and performance incentives.

OKRs should feel like a team is coming together and being ambitious. But if OKRs determine whether I'm going to get my bonus, or if I'll get a raise, then OKRs won’t be as ambitious.

I usually advise starting with company-level OKRs, particularly companies that are under 100 people or so. Just do company level OKRs. That’s enough to give people a sense of how they should be focusing their time. Yeah, that means that there may be some people in the company who can't directly trace what they're doing to an OKR. That's okay. OKRs are not a task list. They’re where we want to go.

A good OKR is directional: “By the end of the quarter, we’ll have reached the summit of Mount Everest.” Yeah, you'll probably need to buy a tent, and you'll have to figure out where the food comes from, and how many base camps you’ll have. But those are details. They’re tasks.

The OKR is that we're going to reach the summit. If you remember that, it's a lot easier to let go and remind yourself that there are projects and tasks and burn-down charts and all that kind of stuff. Of course that all still needs to be done. But it’s done in service of reaching the objective.

You still need good discipline in terms of day to day task management, prioritization, who's doing what, and dependencies. But OKRs aren't meant to do that.

You still need to project manage. What's changed with OKRs is all of that project management is in service of a larger objective that you know how to measure and you know how to accomplish.

Setting OKRs will surface tensions, and that’s a good thing

BK: What are some misconceptions people have about OKRs?

I think there's such a sense that OKRs are powerful that people get disappointed when they're not a silver bullet.

It actually takes a few cycles to feel OKRs working. I always ask the companies, “Promise me you'll try it for at least two quarters.” Because the first quarter you'll realize there's a bunch of different ways you would have rather done it. You'll feel like you messed up on some. It's really the second quarter when OKRs start to really work and you realize what they’re doing for you.

The other thing is that OKRs aren't going to compensate for your culture. If you have a culture where people are apathetic or nobody's bought into the vision, OKRs won’t help. If you see OKRs as an instrument to get people to do what you want them to do, they’re not going to work.

OKRs are only as good as your culture.

OKRs are not going to compensate for fundamental issues with communication or dysfunction. In fact, they’re going to cause some of those issues to rise to the surface. And that's good. Part of what makes OKRs great is that they force a discussion.

If you have two teams that won't talk to each other or two dysfunctional managers that are passive-aggressive with each other, an OKR process is going to bubble that to the surface quickly. That can cause people to feel like OKRs didn't work, that they just create all this chaos. But the problem isn't the OKRs. The problem is that you have organizational issues that need to be resolved.

BK: You mentioned earlier that OKRs should be cross-functional. Does that help surface and resolve some cross-department tensions that would otherwise fester?

Yes. I'll give you an example from a portfolio company we worked with. It was the first time they'd ever done OKRs, and we had the entire leadership team there. The challenge they had, like other companies their size, was that they were trying to do too many things.

We started by listing all the priorities that the company had. We put them all up, and there were 12 different things. We needed to figure out how to narrow it down to 3-5 priorities.

The CFO believed strongly that cutting costs was a big priority. But it clearly was not. This was a fast-growing startup, and nobody else thought cutting costs should be a priority. She didn't like learning that. But she was much happier learning it at the beginning of the year. That’s so much better than expecting something to be a priority and finding out at the end of the year that nobody cared about it.

To go back to your point about the functional areas, I think if there had been engineering OKRs and finance OKRs, we may not have uncovered that disconnect.

Part of what's great about OKRs is it forces cross-functional disconnects out into the open so that you can confront them, and you can decide how to resolve them.

Aim for the moon

BK: What one idea about OKRs would help companies the most?

Ambition. If there's one consistent piece of feedback I give when I see OKRs it’s that they don't feel ambitious enough to me.

I’ve always felt like the right sense you should have when you come out of an OKR meeting is that everybody should feel really nervous, but not hopelessly nervous. You want OKRs to feel, “uncomfortably exciting”.

You want this sense that these OKRs aren't just tasks. They’re ambitious objectives you're probably not gonna achieve. Yeah, you're probably gonna whiff on this OKR and totally miss the boat on that OKR. But the huge leaps happen when you really set the bar high.

Being ambitious doesn't always come naturally. CEOs often don't feel comfortable setting objectives that the team may not achieve, because either they don’t want to burn people out, or they don't want to look like a failure. But you have to get past that.

It's only when you set out to do something that seems impossible that you can accomplish something truly heroic.