The 8 worst ways to work with OKRs.
No doubt, OKRs are trendy. When there is a call for transformation, teams and organizations seem to be very open to hopping on all sorts of trends out there. It's a big business, so there are books, coaches, consultants, webinars, meetups, trainings and I can become an OKR Expert for $99 with a 90 minutes multiple-choice test. As OKRs are open source, there is quite a bandwidth of different interpretations, adoptions and process variations out there.
Some are pretty close to the initial idea of OKRs, which is simply to focus, execute and align better and to use your employee’s brainpower by involving them in the process and agree on outcomes.
"More than 60% of all organisations larger than 500 employees who are using OKRs are actually not doing OKRs, but MBOs"
I want to use simple words. As the initial idea was pretty simple as well. And as far as we know from Google, they are pretty good at making things simple, right? So Google’s and Intel’s intention definitely was not to overcomplicate things.
Some other interpretations of OKRs out there are just the opposite. They are nothing else than MBOs (Management by Objectives) with the look and feel of OKRs. Based on my assessments over the past 7 years, I would state that more than 60% of all organisations larger than 500 employees who are using “OKRs” are actually not doing OKRs, but MBOs.
Here are descriptions of the worst OKR interpretations we've seen at how-to-okr.com
1. MBO – OKRs
Definitely the biggest group out there and easy to recognize. You will find loads of KRs which are actually broken-down budget numbers or KPIs by quarter. Furthermore, it is only allowed to add contributing OKRs from departments and teams when the Leadership Team has defined and communicated their next OKRs. Very often these contributing OKRs are already pre-defined and handed over towards departments and teams. Everything must actually be connected and all contributions should make total sense, but somehow this is becoming a processual nightmare each and every quarter. The yearly strategy consists of top-line revenue and the Northstar vision is to become Market Leader. Managers who are in these companies for many years are wondering why there is a hype around OKRs because they have worked like this already for ages – back then it was just called differently.
Trade off:
- slow process
- no/ low involvement of employees
- low empowerment and engagement
- low level/ speed of change and improvements
- low impact
2. Two-timers
Two-timers do OKRs only every 6 months, so 2 times per year. In rare cases, this group has started with 6 months cycles from the beginning. They started with quarters and then recognized that it’s more difficult than planned. Formulations took way longer than expected. Then someone in the leadership team stated that the industry they are working in is actually not as agile as all the tech folks around them. Also, their clients work with totally different and longer cycles, so it’s better to do this new thing called OKRs only every 6 months in order to get a bit of relief and make things easier.
Trade off:
- few chances to pivot priorities
- less tangibility in expected results
- process to define OKRs is probably still too long
3. Take a break
This group is actually similar to the 2-timers, as their origin story is pretty much the same. But as the time to review, write and align OKRs always took way longer than expected and the pain got bigger, they made a different decision. Let’s not change the way we do OKRs. Let’s give us more time and take a 1-month break between our OKR cycles to properly review the last cycle and write the new OKRs.
Trade off:
- 1-month of executional downtime
- process to define OKRs is probably still too long
4. Cycle mess
This phenomenon is mainly seen at larger enterprises with big business units mostly in traditional business models. Some of their units are working already in a pretty agile environment. Some others are the complete opposite with a mindset of year-long development cycles, long projects, and hierarchical decisions. No doubt, OKRs for them is quite a stretch and will probably take more than the typical year to be adopted. In order to lower the “stress level of change”, OKRs are introduced across the whole organization. The modern parts of the organization follow quarterly cycles, whereas the more traditional parts are open for longer cycles like 4 months, 6 months or even 9 months. Another version of this, not to call out any cadences at all and leave it open for teams to decide on all sorts of different target dates per OKR.
Trade off:
- a nightmare for all horizontal alignment efforts (cross-functional dependencies)
- losing the effect of a common-mode system
- measurability and tracking of long-term projects will not improve
5. Task – OKRs
This one is actually pretty common as it is one of the key changes in mindset. But there is a weird twist of it I’d like to tell you. Let’s start with the common part...this group never gets to the step of defining actual outcomes and, instead, uses a list of tasks and activities. Now the weird twist of it is to define a rule that their Objectives are describing the expected outcome at the end of the quarter and the KRs attached have the purpose to describe the different steps in order to get there, which is a predefined task list.
Trade off:
- low empowerment and engagement
- low level/ speed of change and improvements
- low impact
6. Managers writing all OKRs
Team- or Department Leaders of this group are usually very close to giving up on OKRs. They are fed up and they don’t understand how companies like Google can work with such an administrative monster. These managers are writing all OKRs for all their team members every quarter after they have received the necessary input from their managers. The final OKR versions are then called drafts to be able to sell them easier to team members and presented (handed over) to the respective team members. Usually, these OKRs are full of task descriptions.
Trade off:
- low empowerment and engagement
- low level/ speed of change and improvements
- slow process
- ineffective usage of managers time
- low impact
7. Over engineered metrics or formulations
Being a German, I do admit that this group is often connected to German companies. It seems like writing an engaging Objective is easier in English. German language leads to longer and often less catchy objectives. But quite often they are simply overdone with explanations and add-ons. Some teams spend too much time looking for precision and forget to balance it against time-spent and pragmatism. For example, while we don't recommend binary OKRs, it is ok to have them sometimes. This group usually is starting with OKRs and will have a problem to decrease the time spent to create new OKRs over the course of the first two or three iterations.
Another version within this group is to pre-formulate up to three weirdly graded results per KR. Here are two examples:
KR: Sign up 100 new clients
50% achievement = 50 new clients ( ...well, this still makes sense)
70% achievement = 65 new clients (serious? why?)
100% achievement = 100 new clients
KR: Project X contract signed
50% achievement = V.2 of contract is at client to review
70% achievement = all mark-ups and discussion points solved
100% achievement = contract signed
Despite the questionable purpose of doing this, imagine that all KRs in all teams and departments have to be pre-graded and formulated 3 times!
Trade off:
- long definition process with low chance to become faster
- low motivation and engagement
- high administrative effort
8. Over engineered grading
This group is having check-ins and retros on OKRs which eat up way too much time and as a consequence, the support behind OKRs is decreasing. This group sees grading and progress check-ins as a mathematical exercise. A discussion of whether a KR is currently at 0.3 or 0.4 takes up to 45mins and no-one is raising the hand to remark the important point: “we are behind and let’s decide what can we do as a team to get this thing moving”. Often there are philosophical discussions about the status of binary KRs, i.e. whether a contract is signed or almost signed. Well, this is the reason why binary KRs are not as good as metrics. I’m not saying that binary KRs are not allowed, but as long as it is not signed this KR is simply not accomplished.
Trade off:
- long check-in process with low chance to become faster
- low impact of check-ins
- low motivation and engagement
- high administrative effort