OKRs are often done wrong. I would not go as far as call them "bullshit" or useless. Just because many people are doing something incorrectly, does not mean that there is no way of doing it well in a way that provides value. The biggest bullshit with OKRs is that many organizations go through the motions of doing OKRs, but are actually just making up numbers and sweating through the end-of-quarter presentation hoping no one asks hard questions.
One of the things that is wrong with OKRs is that people often focus on the wrong thing. There is a lot of room in how to do OKRs. People pick some of the fringe things and focus on them as if they are the most important thing.
This article cites two of such things.
While many people do say that OKRs should be ambitious, there is no fundamental rule that says that OKRs need to be ambitious. It's perfectly OK to do OKRs where you aim for 100% success. Or you can use OKRs to get the ball moving and overcome static friction on an initiative and be happy at the end of the quarter that things got moving. Or you can aim for 70% completion like many people do. The key thing is that "aiming for 70%" is not a defining characteristic of OKRs. It's one way of doing them, but it is not a defining feature of OKRs.
The article also says that OKRs need to cascade. Again, this is flavor of doing OKRs. OKRs should support higher-level organizational goals. However, making them cascade perfectly through multiple levels of an organization is "hard mode". In many companies, there is a stated top-level goal, and then OKRs need to support it in some way, without necessarily cascading. That's fine. It's also perfectly OK to use OKRs in isolation in some department to advance toward an important goal, even if no one else in the company uses OKRs.
If these are not defining characteristics of OKRs, then what is?
Here's how I implement OKRs on my teams. These are the three golden rules of OKRs:
1. The objective (O in OKRs) sets the direction in which you are going
2. The key results (KRs in OKRs) are the rulers which measure your progress
3. MOST IMPORTANT: You must update your OKRs every week, come hell or high water. If you cannot update the value, add a note about what kept you from updating it, and spend time working on that. This rule is the forcing function that will make your OKRs work well eventually.
Start like that. It's hard enough to follow these core rules. Adding alignment, flowery language, reach goals, and whatever else comes on top of it makes OKRs more complicated. Once you get the basics down and you get a feel for OKRs, you should improve your OKR game. But start small.
So yeah, the way many organizations do OKRs is bullshit. However, OKRs are not bullshit in general.
I'm kind of passionate about OKRs in engineering. I've spent a decade at 15Five building a system for tracking OKRs, and getting teams to use them well. Here are some things I wrote about how to get OKRs working in an engineering team.
One of the things that is wrong with OKRs is that people often focus on the wrong thing. There is a lot of room in how to do OKRs. People pick some of the fringe things and focus on them as if they are the most important thing.
This article cites two of such things.
While many people do say that OKRs should be ambitious, there is no fundamental rule that says that OKRs need to be ambitious. It's perfectly OK to do OKRs where you aim for 100% success. Or you can use OKRs to get the ball moving and overcome static friction on an initiative and be happy at the end of the quarter that things got moving. Or you can aim for 70% completion like many people do. The key thing is that "aiming for 70%" is not a defining characteristic of OKRs. It's one way of doing them, but it is not a defining feature of OKRs.
The article also says that OKRs need to cascade. Again, this is flavor of doing OKRs. OKRs should support higher-level organizational goals. However, making them cascade perfectly through multiple levels of an organization is "hard mode". In many companies, there is a stated top-level goal, and then OKRs need to support it in some way, without necessarily cascading. That's fine. It's also perfectly OK to use OKRs in isolation in some department to advance toward an important goal, even if no one else in the company uses OKRs.
If these are not defining characteristics of OKRs, then what is?
Here's how I implement OKRs on my teams. These are the three golden rules of OKRs:
1. The objective (O in OKRs) sets the direction in which you are going
2. The key results (KRs in OKRs) are the rulers which measure your progress
3. MOST IMPORTANT: You must update your OKRs every week, come hell or high water. If you cannot update the value, add a note about what kept you from updating it, and spend time working on that. This rule is the forcing function that will make your OKRs work well eventually.
Start like that. It's hard enough to follow these core rules. Adding alignment, flowery language, reach goals, and whatever else comes on top of it makes OKRs more complicated. Once you get the basics down and you get a feel for OKRs, you should improve your OKR game. But start small.
So yeah, the way many organizations do OKRs is bullshit. However, OKRs are not bullshit in general.
I'm kind of passionate about OKRs in engineering. I've spent a decade at 15Five building a system for tracking OKRs, and getting teams to use them well. Here are some things I wrote about how to get OKRs working in an engineering team.
https://koliber.com/articles/opinionated-essential-guide-to-...
https://koliber.com/articles/top-okr-mistakes
https://koliber.com/articles/reduce-tech-debt-with-okrs