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. 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 seem not valuable for a number of reasons. Amongst them could be the following:
- Management is using it as a medium for judging 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. 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.
- 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 later 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.
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.