At its core, OKR is about planning and execution, which is represented by 2 important sessions: OKR Setup and OKR Review. If you pay attention closely, the whole OKR practice can be summed up as a continuous cycle of planning and reviewing.
However, it doesn't mean we keep doing the same thing over and over again. What we should do instead, in the words of Christina Wodtke (the author of Radical Focus), is to "track closely what works, and what does not, and you do more of what works and less of what doesn't."
The key is by examining each KR during the OKR Review and identifying the lessons learned by looking at the related progress, score, and self-assessment.
Let's look at the 4 cases below.
Case 1: high progress, high score
People tend to overlook the lessons learned when the KR has high progress and score. This is a missed opportunity to implement what went well on that particular KR to another KR for the next cadence.
In the example above, the DRI ("Ben") was from the Human Capital (HC) Team and he wanted to create a dashboard. He was aware that data visualization might not have been his team's strength.
By consulting with the Data Team and writing the necessary initiatives he'd need to do, Ben was basically informing his team about the procedure one should take when they wanted to create a dashboard or other data visualization tools. A particular question from the Data Team ("Would this be a real-time dashboard?") also helped him to think of the little details that had never occurred to him; making this a valuable information for his peers as well.
Case 2: low progress, high score
Keep in mind that progress and score are not directly proportional. It's entirely possible for the DRI to have low progress, but a high score. Two possibilities that can lead to this scenario: underestimating the scope of the KR or dependency on external factors. The reasoning, whatever it might be, should be written down in the self-assessment column.
Looking at what Ben wrote, there are 2 lessons learned that we can identify:
a. While it's true that Ben could not foresee 2 candidates would cancel last minute (nor would he be able to prevent that from happening), he could have mitigated the situation had he scheduled more than 5 interviews. The lesson learned here is to always have a back-up candidate, especially for key positions.
b. The fact that 1 out of 3 candidates showed high potential could nudge Ben to figure out what the determining factor was that separate this candidate with the rest. Was it her education? Did he find this candidate from another recruitment channel? Or was it just a coincidence? The answer to this question could help Ben to narrow down his search when looking for other high potential candidates.
Case 3: high progress, low score
This case gives a clear signal that the DRI would need to stretch, because the complexity of her KR was not as high as she thought it would be. This KR usually requires a certain degree of honesty from the DRI to admit that the effort and/or the quality of the actual outcome from her KR was not as expected.
Looking at the self-assessment column, the DRI ("Trisha") mentioned the expected outcome (i.e. the integration timeline from Imperial Noodle is received) was achieved without putting much effort.
The lesson learned here is that Trisha could have achieved more in that particular week, had she not overestimated the complexity of her KR. In other words, the scope of her KR should not have stopped at receiving the integration timeline. She should have aimed for the next step instead (e.g. the integration timeline is approved by the Engineering Team).
This knowledge would come in handy for similar KR she'd encounter in the future.
Case 4: low progress, low score
This case is the one that requires the utmost attention. Any KR that has low progress and low score is a signal that something didn't go as expected. It is the team lead's responsibility to uncover what happened behind the scenes.
In this case, the DRI ("Trisha") mentioned she had no time to work on that particular KR. For reflection purposes, her team lead could use these several probing questions to figure out what exactly had happened:
- What was your plan to execute your OKR for this cadence?
- Which KR took the longest time and effort to work on?
- Did you have any ad-hoc requests in the middle of the OKR cadence?
- Did you have the right resource to work on that KR?
If Trisha was mindful enough, she could also ask those questions to herself before the cadence started and wrote down the answer on the self-assessment column. That would be the lessons learned that she could bring to the next cadence to prevent the same cause or issue from happening again.
Want to find out more:
If you're interested in articles like this, you might want to check out our writings on Medium and LinkedIn. It covers a diverse topics of Product Management, People Operations, and everything in between.