5 learnings from adopting OKRs at the team level
Main learnings of a Product Manager and a Scrum Master after 6 months working with Objectives & Key Results.
Next month (July 2022) will be ManoMano’s third-quarter working with OKRs. ManoMano is leveraging OKRs to foster the focus and alignment of the company’s strategy. We want to share our main learnings as a Product Manager (Christian Palou) and as a Scrum Master (Alec Roy) in our respective teams after the first 6 months:
- Avoid setting features as objectives
- Key results are measurements, not a To-Do list
- Move from lagging indicators to leading indicators
- Avoid using company strategic KRs as team Objectives
- Regularly inspect OKRs to measure progress
All OKRs used in this article are made-up examples to illustrate the learnings.
1. Avoid setting features as objectives
What we saw. Some teams’ objectives were a summary of the planned features for the quarter. They were output-oriented:
- “Launch the new unified return flow”.
- “Block WISMO (Where IS My Order) contacts for orders not shipped”.
- “Migrate ECS to EKS”.
- “Migrate ms.payments from PHP to Java”.
By setting features as objectives, the objective will be achieved as soon as you deliver the feature. The problem is that you are not taking into account that your ideas might fail, you will have the feeling that the work is done without measuring the results or outcomes of the feature.
What we believe is better. Objectives should be memorable, qualitative descriptions of what you want to achieve to be one step closer to your vision, they must be outcome-oriented. Teams must think about what human behaviour(s) they want to have an impact on, to create value for the users (outside or inside the company). The previous examples could be rephrased like this:
- “Make it easier for customers to return a product”.
- “Reduce customer contacts to sellers and customer service”.
- “Streamline infrastructure costs” or “Ease infrastructure scaling”.
- “Improve code base stability to solve customers’ problems faster”.
These are not linked to solutions and they open doors to several ways of achieving them.
Tips to change behaviours. When defining an objective, team members should ask themselves “Why are we doing this?”, “What impact are we trying to make?” and “What behaviour are we trying to change?”. Answering these questions will bring them closer to their true objective.
2. Key results are measurements, not a To-Do list
What we saw. Some key results were set as (chronological) steps or tasks strongly linked to the features:
- “Highlight the last order on my account page”.
- “Improve cross-sell email layout”
- “3/3 microservices plugged into Kong”.
By setting tasks as key results, the objective will be achieved when you finish all the tasks. You are not going to have metrics to assess if the tasks were the right ones to achieve the objective.
What we believe is better. Key results help assess the progress toward the objective, not reflect what the team will do during the quarter.
They’re called key results, not key activities
If all the tasks (KRs) are delivered and nothing improves, is the goal achieved? Never forget that plans might fail, KRs should help you find out that the objective won’t. Key results should be measurable expected outcomes:
- “Reduce the time it takes for a customer to find out the status of their order from 10 seconds to 5 seconds”.
- “Increase from 10% to 25% the post clicks in remarketing emails”
- “From 70% to 100% of our microservices are accessible through the unified API management system”.
Tips to change behaviours. “What KPIs help me assess that I have (or not) reached my objective?”. This is the question the team should ask itself when writing key results. Another tip is to follow Marissa Mayer’s recommendation “It’s not a Key Result unless it has a number”.
3. Move from lagging indicators to leading indicators
What we saw. Some teams formulated KRs using lagging indicators, such as repurchase rate, NPS or revenue. These kinds of metrics are called lagging indicators because it’s hard to change them, it takes time to move them forward and often teams don’t have direct control over them.
- “Increase GMV (Gross Merchandise Volume) by 10%”.
- “Increase net promoter score from 45 to 50”.
- “Increase repurchase rate from 32% to 35%”.
What we believe is better. Teams should use leading indicators and metrics that quickly respond to their impacts. Leading indicators measure a specific change in human behaviours that will eventually drive lagging indicators, they are predictors of future success.
Let’s imagine we are the team in charge of the after-purchase experience in ManoMano and we want to impact the NPS. The NPS score is influenced by several factors (payment options, product quality, speed of delivery, customer support quality,…) and is measured monthly; it’s a lagging indicator.
Deep diving into the NPS comments, the team discovers that it’s difficult for customers to track the transport status of their orders. Instead of using the NPS to measure the progress, let’s use leading indicators that define a good order tracking experience:
O: Offer a delightful delivery experience to our customers
KR1: “Increase from 92% to 95% the ratio of orders with the tracking link provided by the seller”.
KR2: “Increase from 90% to 94% the ratio of orders tracked by Aftership”.
KR3: “Reduce from 15% to 10% the contact rate for WISMO (Where Is My Order)”.
The team has a direct impact on these metrics and we will be able to measure the impact in a short period.
Tips to change behaviours. Discovering the leading indicators that will drive your lagging indicators is not an easy task. Teams must go through their mission, strategy, NSM and users’ journeys to ask themselves “Which human behaviours will we have to create/change/remove to move our lagging indicator?”.
4. Avoid using company strategic KRs as team Objectives
Context. At ManoMano we are using three levels of OKRs: Strategic OKRs (at the company level), Train Aggregated OKRs (at the teams of teams level) and Team OKRs (at the team level).
What we saw. Teams doing strict cascading OKRs definition. They were using KRs from the company’s strategic OKRs as their own team’s objective. Considering this company’s strategic OKR:
O: Accelerate B2B growth through acquisition and loyalty
KR1: Increase repurchase rate from 30% to 35%
KR2: Increase GMV (Gross Merchandise Volume) through coupons on pros from 5% to 7%
KR3: 900K new pro customers by the end of 2022
We saw the Return’s team OKRs like this:
O: Increase repurchase rate
KR1: Increase repurchase rate from 30% to 35%.
Using a strict cascade will limit your key results, as you will only be able to use lagging indicators in your team KRs (3rd learning). In addition, it could wrongly lead you to add outputs as key results (2nd learning).
What we believe is better. Align your team’s OKRs on company strategic OKRs instead of cascading them. Let’s say that one of the main assumptions of the returns team is that making it easy to return a product will increase customer satisfaction and remove blockers to buying again, that will be the team objective:
O: Make it easier to return a product for our B2C & B2B customers
KR1: Reduce the customer contact rate (returns reasons) from 5% to 2%
KR2: Reduce the refund lead time from 8 days to 5 days
KR3: Increase the Returns CES (Customer Effort Score) from 2/5 to 3/5.
In this example, we are creating a weak link between the team OKR and the company OKR.
In adition, moving from only 1 lagging KR to 3 leading KRs will make easier for the team to find solutions to move those KRs: “Give more visibility about the return status to reduce customer contacts”, “Create some rules to automatic refund customers for low value items”, “Improve the return instructions”….
Tips to change behaviours. Take a deep look at your product mission and think about how inside your specific scope you can have an impact on the company’s strategic OKR. Don’t hesitate to make assumptions if needed. The KR of the strategic OKR will validate or invalidate this assumption. The lagging indicator will tell you if you are on the right path.
5. Regularly inspect OKRs to measure progress
What we saw. During the first OKR usage iteration, some teams defined their OKRs during the PI Planning and looked at them again at the end of the quarter to see if they succeeded.
What we believe is better. OKRs help teams inspect their progress and adapt their plans if necessary. OKRs should be monitored at least every sprint. This framework is made to help teams define a destination and ways to validate their progress regularly. Without regular inspection, and maybe adaptation, using OKRs will be meaningless. When we mention adaptation, we mean plan or KR adaptation. Teams should change their KR if they are not relevant anymore.
Tips to change behaviours. One of the assumptions could be that teams don’t watch them because they don’t see their usefulness (maybe because the team is more output-oriented than outcome-oriented). You need to highlight this.
A low-level solution would be to ask the team to update the OKRs progress at the end of the sprint, and to discuss it during the first 15 minutes of your team retrospective or review. This will “force” the team to inspect their progress, maybe more as a constraint than a benefit first. For instance, we are using a Jira plugin to track the progress on our side at the company, train and team levels. If you are interested in our feedback or want to know more about this plugin, please let us know in the comments.
As a team leader, you can also adopt a higher-level solution by asking regularly the question “How are we on our OKRs?”, during the sprint review, for instance. You will need to repeat it again and again before it becomes a habit. You will probably need a difficult situation, where the plan needs adaptation to get back on track, for the team to understand the usefulness of OKRs. If you are encouraging the team members to ask themselves the question, it will become a habit for them.
Conclusion and worthy reads
What do we learn from all this? Using a new framework is a journey. We try and learn. The important thing here is to learn and share the learning inside and outside our organisation. What is important both when implementing OKRs and defining them is to keep an open mind and think outside the box.
What do we want you to take away from this? Whatever you want and need. Maybe you will have different conclusions on our tips, please share your feedback. Maybe you will use them and it will work, please share your experience. Even if it doesn’t work.
Finally, here are some interesting articles we read during the redaction of this article, maybe they will inspire you as well:
- How to measure the progress of OKRs using Leading and Lagging Indicators by Tim Herbig
- A Practical Guide to Using OKRs in Product Management by Tim Herbig
- 7-common mistakes YOU WILL DO when writing OKRs by Vinicius Castro
- 4 key lessons I’ve learned about OKRs by Richard McLean
- The Good, the Bad and the Ugly of John Doerr’s OKR Book by Felipe Castro
- How to Avoid OKR Fake News — Keynote at the OKR Forum Amsterdam 2019 by Felipe Castro
- The Art of the OKR by Christina Wodtke
- OKR mistakes and how to fix them by Christina Wodtke
- Objectives and Key Results (OKRs) in Gitlab
- Cascading vs. aligning OKRs by Tability
- Cascading OKRs at scale by Christina Wodtke
- Stop Cascading OKRs, Start Aligning Goals by Weekdone
We ❤️ learning and sharing
We took a lot of pleasure to write this article, feel free to post your feedback below and reach out to us on LinkedIn (Christian — Alec). Whether you had a similar or totally different experience, we’d love to hear about it.
