OKR (Objective – Key Results) were “invented” by Andy Grove at Intel in the 70’s and took their triumph as an agile planning and management approach at Google. Some say that Google’s success is not due to their products but to the use of OKR and its radical focus!
OKR are very lightweight in their implementation and yet, as with other approaches, you can misunderstand or simply misinterpret some things when implementing OKR. Learn here how to avoid the 5 typical errors when using OKR!
What are OKR anyway?
Essentially, OKR can be described by these characteristics:
- Iterative & incremental approach: With OKR, a planning and processing cycle is completed/started at regular intervals (ideally/normally) every 3 months or every quarter.
- Continuous workflow improvement: Each completed iteration is followed by a retrospective, which is intended to optimize the process based on current knowledge and flow into the next run.
- Fuzzy planning: Artifacts of the OKR are “reduced” to objectives (“one sentence description” of the project) and gradually measurable key results to be achieved. Initiatives complement both and can be understood as e.g. epics in a product backlog. More is not planned!
- Forced reduction: There is no exact target, but you should not define more than 4-5 Objectives with 3-4 Key Results each. The rule is: The optimal level of project is reached when the selection has hurt right (really right)!
- “Shoot for the moon” goals: Goals and key results in particular are planned in such a way that they go beyond what is actually feasible! 70% goal achievement is the previous 100%, so that one lies with a 100% goal achievement with OKR already far over the feasible!
Therefore here are the 5 typical errors in the OKR implementation and how to avoid them!
1. to take OKR for MbO
Management by Objectives, introduced by Peter Drucker in the 1950s of the 20th century, is a management method in which a superior (directly) defines objectives to be achieved with a single employee, usually long-term goals (1 company year). Keywords here are: directive, per employee individually and long period.
While in a time of command & control this may still function adequately for managers and employees, it is completely “outdated” in the digital and rapidly changing present. Goals miss their targets, employees are demotivated and companies are not very successful in the MbO model. Objectives of the OKR are therefore not mixed up with the objectives of the MbO!
Recommendation: Objectives should not be (pre-)formulated in a directive way at OKR, but should ideally be developed in the collective between the leads and the teams. The power of the objectives lies in the strong “buy-in” effect through the participation of teams and employees. A joint balancing and “struggle” for the best and most motivating goals brings the breakthrough! In addition, the time horizon for achieving the goals should not be too long. 3 months have proven to be ideal. 6 months are sometimes also possible, but beware: always choose the shorter range!
2. no achievement of incremental implementation
As known from other agile procedures such as Scrum, the complete independence from planning and implementation cycles is essential for agile work. Just as a sprint of e.g. 2 weeks has to produce a self-contained (partial) piece of software, OKR cycles also have to be technically completed.
OKRs are not an annual plan divided by 4 and each iteration then yields 25% of the annual target! If you think this way, you will fall short of the big added value of the OKR: the possibility to change your strategy quickly and easily! What is worse than to find out that you can’t adjust anything, because you have to finish the original plan first!
Recommendation: With OKR each planning cycle starts with a white sheet of paper or an empty backlog. In the implementation and planning you should pay a lot of attention not to have any overhang from the previous cycle. OKR planning therefore does not have to be filled with implementation tasks until the last day of the iteration. Rather, it is advisable to either prioritize projects of a cycle hard (e.g. with the MoSCoW prioritization) or to “reserve” the last weeks within a quarter for optimization tasks to achieve the defined key results.
Important note: it is not about creating buffers, it is really about doing everything to achieve the measurable key results. A final release on the last day of the iteration doesn’t help any more!
3. link bonus direct to goal achievement
A still present approach to (wrong) employee motivation is the monetary bonus, linked to (individual) goal achievement. At least since Daniel H. Pink’s book “Drive” it should be clear to every leader that this procedure can turn into the direct opposite.
OKR take a substantial part of their power from the “Shoot-for-the-moon” goals, i.e. the shifting of the target line beyond the actual 100% of what is realistically achievable! However, employees only get involved if they are free of fear when it comes to defining the goal. Bonus payments immediately cause the natural “cover-my-ass” effect, which drives us humans to define goals in such a way that we reach our promised reward (safely).
Recommendation: OKRs encourage top performance and must therefore be decoupled from direct remuneration. Either you eliminate this nonsense in general (my preferred approach) or goals & bonuses are decoupled and the bonus is paid if, for example, the company was successful overall (measured by e.g. sales or EBIT).
4. no use of gradually measurable key results
What you can’t measure, you can’t improve! OKR go further and describe: What cannot be measured gradually can only be achieved with difficulty!
Key results of the OKR are like measuring the water level in a continuously filling glass. At regular intervals it is checked how far you have come, whether the path is the right one or whether adjustments are necessary.
Recommendation: In order to see real progress in the implementation and to make the effects of your own work visible, you should always define Key Results with gradual or linear numerical changes. Percentage or absolute key figures such as sales increase by x% or reaching at least x units of y can be used. A “digital” measurement (i.e. 1 or 0) is always bad, e.g. creation of a concept or execution of tasks. Just because you’ve completed a checklist doesn’t mean you’ve reached a goal!
5. process daily business and OKR separately
OKR must represent the most important plans of a company, an area, a team in order to develop their power! However, this also means that the majority of the working time and other resources must flow into the implementation of the OKR!
If OKR are defined as “Nice-to-have” tasks or even additionally on top of the activities of a team, they will on the one hand always lag behind and on the other hand quickly cause disappointment. How is one supposed to fly to the moon, if one works on this goal besides or shifts into possible overtime hours.
Recommendation: Employees & teams must be encouraged to give their full resource & time to the OKR in their planning. The more the better! This works best in Product or Scrum teams as they fill their backlogs based on the OKR. In administrative areas such as financial accounting, optimization-OKR may make more sense (e.g. reduce processing time by x%).
Summary
OKR are a great framework for agile strategic business management and for planning program and portfolio management.
OKR, however, develop their full “impact” best when they have a high level of employee or team participation in the definition and do not represent a “false” MbO. Make sure that you can complete each iteration completely and define correct, i.e. gradually measurable key results. Finally, and most importantly, do not define individual bonus targets and focus fully on the implementation of the OKR, including all resources.
And if you also need competent support with your OKR implementation: Contact me today!
