It’s the end of another quarter and your department just struggled to fit the list of initiatives they would either like to do or have been asked to do by their stakeholders into the OKR (Objectives and Key Results) structure because management has noticed that companies like Google and Spotify and using it and reaping benefits. However, after the OKR sessions, everyone is exhausted and frustrated because what they just did doesn’t seem of value. Sound familiar?
OKRs are not for every team or organization. Unless you’re given the autonomy and alignment to try and accomplish outcomes rather than crank out features, OKRs may not be right for your team. Your current OKR process may not seem valuable for a number of reasons. Amongst them could be the following:
- Management is using it as a medium for judging individual performance.
- It’s easy to point to a date and ask for a binary answer: Is it completed, yes or no?
- Management is using it to micromanage initiatives; or worse, HiPPos are placing their personal “OKRs” or Initiatives on the team lists.
- Teams don’t understand the OKR model. They’re confused between key results and KPIs, Initiatives and every day tasks. What to include in OKRs? What to leave out?
- There is no product vision, mission, or strategy to derive good objectives from.
And the list goes on…
To brush up on the basics of OKRs and look at good and bad examples, I suggest looking at my colleague Tim Herbig‘s detailed post on Product Goals and OKRs and Jeff Gothelf‘s writeup on OKRs and heuristics. Amongst them are good practices such as having Initiatives roll up to non-binary Key Results that show progress of a KPI rather than a binary (and often subjective) “Yes, it was completed” or “No, it wasn’t completed”. Another good practice for writing key results is having the metrics you measure be something that the outside world or customer cares about. For example, if the objective is customer service related, one of its key results could be “Decrease call-back time from 72 hours to 48 hours.” This is a metric that your customer can directly feel and would support.
What I sometimes find missing in current OKR literature is an “OKR Definition of Ready”, so to speak. Below are some of my general prerequisites for successful OKR implementation:
- Have a product vision, mission and strategy in place. This is key for deriving good objectives from. Product vision is the future state of your product, the tomorrow. Product mission and strategy are what you’re currently doing to work towards that vision, it’s the today. Marty Cagan has nice writeup about the differences between the three.
- Collaboration between all parties that are working on the product. At the enterprise scale, collaboration becomes harder as teams grow in numbers and often specialize on a specific subset(s) of the product. Sales, product, tech, business markets, management, need to work together to define the customer problem(s) they would like to focus on and work collaboratively throughout the quarter to achieve this rather than checking at the end or delivering a set of outputs from their department and tossing the rest of the responsibility to another department. If a team doesn’t have ownership or a strong influence on their product/service and process, then they will always have dependencies and might not be able to move the needle as they hope to. How can the different parties collaborate? Quarterly kick off meetings, participating in weekly planning and demos, using something like the Dual Track Single Flow model so that each team’s work is towards a common goal.
- Have measurements in place. Too often, teams try to come up with Key Results, only to realize that there are no measurements in place to assess the success/failure of initiatives. Ensure that your team can measure these metrics as frequently as possible so that they can know when and how to adjust. Teams should start planning for every iteration by looking at the Os they want to achieve and KRs they would like to influence. At the Sprint Review (or its equivalent session), teams should see if they’ve moved the needle on the most important KRs. If they haven’t this is a good chance to adapt their plan for the upcoming iteration, or perhaps consider the validity of the KR(s).
- Foster experimentation. No matter where the “solution” comes from, the first iteration is often not ideal. Teams need to be given time and space to do discovery and experiment to understand and validate the problem space before creating solutions and outputs.
- Management being open to product teams solving problems after the intent has been agreed on. Stephen Bungay’s Mission Briefing model and L. David Marquet‘s submarine video are a great examples of leading with intent. Once the intent has been communicated clearly, teams (who are the experts) can then figure out the right tactics necessary to accomplish the intent. This often means moving away from time-based roadmaps towards theme-based roadmaps and problem-based roadmaps. In the latter cases, teams are not responsible for shipping features. They are responsible for delivering customer outcomes that impact the customer problem. Often, I encourage teams to look back at their roadmaps (whichever flavor they’re using) and try to evaluate the success of their roadmap. If that’s something they’re not proud of, it could be time to use another approach. If they don’t know whether they were successful or not, then the writing is, ironically, on the wall.
- Radical candor. Teams and management should freely, and openly, debate and discuss what they want to achieve together. The team needs to be open to talk with management about expectations without the fear of judgement in order to reach the right objectives and key results. Without radical candor, a vicious cycle of micro-management, padding estimates and planning sessions, and gaming the system are all common symptoms that can occur. Teams may under-achieve and play it safe rather than aim for stretch goals, as objectives are supposed to be. At its core, OKRs rely on a culture founded in radical candor.
Once the things above are in place, you then have a good platform to build your team’s/organization’s OKR process on. This includes agreements on what and how OKRs will be used for, people’s roles, having a common language (initiatives vs milestones vs tasks), progress checks, iteration length, quarterly reviews, other necessary sessions, and prep work for each of the sessions. Don’t try to have an ideal OKR process in place from the get go – this will almost never happen. Use a lean approach and start with some necessary discussions and sessions, gather feedback on them, iterate in the next quarter, and continue on with a kaizen mentality.
Rahul Bhattacharya 
2 thoughts on “Prerequisites for introducing OKRs”