Not Everyone Needs Objectives and Key Results (OKRS)

People Vary, Teams Vary, Goals Vary

Christina Wodtke
6 min readNov 25, 2021


I’ve been writing about Objectives and Key Results for about ten years. The mistakes companies make have been fairly typical most of that time: Sandbagging, Overreaching, Set and Forget… until recently. Over the last year or so, I’ve noticed managers are trying to give every one and every group their OKRs. It seems like a kindness but it’s a mistake. It will destroy your OKRs’ effectiveness and create busywork.

Basically, managers have been treating OKRs like they are truffle salt and sprinkling them everywhere. Truffle salt, you ask? Well, when I first got a package of truffle salt from the San Francisco salt company, I was in love! It was so earthy, so salty, so good. I put it on everything. My kiddo loved it too. For awhile. Then they said to me, “Mom, everything tastes the same.” We started using other salts: smoked, lemon garlic and plain (both fine and coarse. We love salt.) And finally the truffle salt started to be good again. It’s great on eggs or lobster bisque but it’s way too intense for every day.

OKRs are really effective in a handful of situations. The best use of OKRs is to focus the organization on supporting a strategic goal. By strategic goal, I mean a goal that has has no external pressures to deal with right now but you still need to achieve it for the long term well being of the company. In the Eisenhower matrix, it’s referred to as “important but not urgent” and you’re told to “schedule it.” Will you? OKRs take something that might be forgotten in the crazy rush of everyday life and remind everyone this goal matters also. The focus of a single OKR set¹ aligns the company. The simplify of the format helps everyone in the company remember what is critical to accomplish. The cadence of check-ins makes sure forward motion is made.

There are other scenarios where OKRs can be useful. When you need everybody in the company to make a big push in the same direction. When you need a serious change that you know the company will resist, like a pivot (just make sure the incentives are aligned with progress toward that goal! Nothing undermines a goal like having incentives that reward the opposite behavior.) And OKRs are great to add to any project² to make sure it has a real purpose.

But demanding that every team have OKRs is like salting everything with truffle salt. Often I see the giant spreadsheets of OKRs and I wonder how anything gets done. You’d spend so much time setting, tracking and digging through those goals to find out what you were supposed to do you wouldn’t have time to work! Most of those companies simply need the help of good product management. I recommend MTP, Marty Cagan, or Teresa Torres if you want to learn more about it. Trying to use OKRs before you understand modern Product Management is like trying to make a soufflé before you know how to scramble eggs.

Who Doesn’t Need OKRs

There are teams for whom creating OKRs are just one more hoop to jump through. Any team that does not own its time³ is going to struggle. It’s rough for technology or design teams. It’s near impossible for Customer Support or HR to make progress on team OKR sets(though HR may lead company culture OKRs.) Sales has its own way of working, and often needn’t bother with OKRs.

Part of the problem is that that management wants everyone to feel special. But are OKRs the solution, or is treating everyone is a full member of the company doing critical work the answer? Could you keep your customers without customer support? Could you keep them loyal without design? Could you offer them anything without engineering? Could you even keep the lights on without finance, IT and Ops?

This work is often called BAU- business as usual. This name dismisses how critical the work is. You could call it critical operations instead. Or you could call it what I’ve started using: Heartbeat work.

Quick sketch of types of work in a given organization. You’ll have a ton of metrics to track in a number of different ways at the bottom, quite a few midway and then a very few at the top.

It’s time to make sure everyone knows how important they are to the company success. If a service group wants to use OKRs for a project such as changing benefits or building a pattern library AND they have capacity for it, that’s fine. But if they are busy trying to keep the lights on or meeting their team’s goals, don’t impose more work on them. Especially if its to set goals they know they’ll never have time to achieve. That will kill morale.

I was talking to a HR manager, and when I said they didn’t have to do OKRs they gave a big sigh of relief. They were too busy recruiting and responding to management needs to be excited by a new effort. They were happy just to be a critical part of their company’s success and their CEO always made sure they was appreciated. A day might come when OKRs made sense for the HR group, but it wasn’t that day.

If you are just starting out with OKRs, I’ll give the same I advice I give everyone. Go slow. Start with one or two multidisciplinary project teams. See how they adapt the OKR cadence to your culture. Roll out to a few more teams and then a few more. After all the teams that build features and products have OKRs, pause and ask, who else might benefit now that I understand what OKRs bring to my company. Put off individual OKRs, preferably forever.

But most importantly, before you do anything else, make sure everyone knows they are valued. That may be all you need for extraordinary results.

For Jeff , who asked. Check out his writing!

Learn more! Buy Radical Focus

  1. A big company may have an OKR per business unit and only occasionally have one for the entire company in times of radical change, like “digital transformation” or “Get Serious about Social.”
  2. Too often projects “drift” away from their original goal as people get caught up in all the tasks that need to be done and all the fun ideation to make the project great. OKRs can remind people why they are doing the project as well as what they need to put in V1 and what they can leave in V2.
    Project based OKRs are also a great way to get teams to learn how tobe result-focused.
  3. By own their own time, I mean decide what priorities should be worked on. A designer or an engineer might set priorities in context of a project but not in the scenario of wanting to do something they think the company might benefit from.
    The exception is when those teams get big enough to have dedicated resources. Design ops or tech ops will have dedicated headcount and then can set OKRs to become the kind of team the company needs to make the company OKRs.