An organization is much like an orchestra: you need highly skilled individuals working together in an aligned and transparent way according to a common heartbeat. Focus will in this post primarily be on OKR and Product.
Objectives and Key Results [OKR] has become a wide-spread and popular heartbeat-driven agile goal-setting and management framework creating alignment in organizations, vertically and horizontally.
This post will discuss the use of the OKR framework in general, and specifically in the context of high-tech product-led organizations
Note: Some of my inspirational background is found below.
Executive summary
The OKR framework is one among many goal-setting frameworks. It has become widespread and popular among especially high-tech companies with a fast-paced technology and business context.
Where e.g., KPIs and Balanced Scorecard focuses on Lag Metrics (looking in the rear-view mirror with clear goals for longer time frames), OKR has its focus on Lead Metrics and a strategic direction. What also characterizes OKR is the Agile mindset with relative short OKR cycles enabling integration of new learnings and insights.
What comes closest to OKR is probably the Hoshin Planning framework, though OKR is far more lightweight.
Christina Wodtke: “OKRs are simple and hard. Running a marathon is also simple and hard. You don’t try to do it in one go. You build up to it“. The best implementation strategy is to start small, gain insights and expand the use of OKR from there.
OKR - in general
The OKR framework has these overall characteristics:
Objective - where you want to go
- Is qualitative
- Must be easy to understand
- Short and to the point
- Describe what needs to be achieved and importantly – why – the rationale
- Be inspiring and motivating
- Aspirational & challenging
- 1-4 objectives per team
Key Results - how you measure the progress towards the Objectives
- Is an outcome
- Specific and time-bound
- Measurable and verifiable
- Aggressive – yet realistic
- Is quantitative, preferable as “from to”
- 1-5 KR per Objective
Initiatives / key actions
Some organizations use the notion of Initiatives in addition to OKRs being actions derived from the OKRs stating how to reach the goal.
- Activity
- Measurable output
- Directly controllable
Not easy - but worth the investment
Some companies try to jump into the deep end of the pool with OKRs.
Christina Wodtke, RADICAL FOCUS second edition p. 149
In essence what Christina Wodtke says, is that
- you’ll most likely fail the first time trying to implement OKRs
- you should start small with a pilot / experiment (entering at the shallow end of the pool)
- you should learn, reflect and show tenacity until OKRs are working for you
- you’ll want to keep it simple avoiding process bloat!
As with all frameworks it poses challenges in its implementation. Done right, the OKR framework promises
- alignment and synchronicity in the organization, both vertically and horizontally
- a bi-directional top-down and bottom-up planning approach rendering a number of advantages like
→ nurturing teams’ self-organization through empowerment
→ having teams (vertically) align with higher-level OKRs
→ having teams (horizontally) align with other team’s OKRs - transparency in who (teams) are working on what goals and in the progress to meet these goals
→ the OKRs are visible to everybody - embracement of ambitious / stretch goals driving the innovation and growth in the organization
→ the OKR framework encourages experimentation and fast learning loops - agility
→ the regular review of goals ensures that they adapt (being agile) and not become static and stale - focus (note the name of Christina Wodtke’s books “RADICAL FOCUS”)
OKRs are a framework for creating and ensuring focus on what really matters, but they don’t work if you stuff them full of every single business-as-usual initiative you have going.
Christina Wodtke, RADICAL FOCUS second edition p. 134
You’ll have to watch-out for the pitfalls, some of which being
- OKRs only cascaded from top to bottom
→ this will undermine the trust in real empowerment - OKRs used for performance evaluation
→ this will quickly lead to teams under-promising thus rendering the notion of aggressive – yet realistic – OKRs void - OKRs used for “business-as-usual” goals
→ this would undermine the point of OKRs having a growth-oriented purpose - OKRs used as a to-do list
→ remember that OKRs are about providing outcome and not output as would be the result of to-do lists - OKRs at the level of individuals when the primary modus operandi is for people working in teams
→ use team OKRs and only in special cases also personal OKRs - too many OKR sets for the individual to understand and navigate among. Below is an example of a de-focused use of OKRs. Even though we assume the OKR-alignment between levels, it still results in a massive number of data points for the individual to navigate among.
- OKRs only cascaded from top to bottom
- Because focus is so fundamental for OKR to work, Christina Wodtke recommends only having one OKR set per company / business level per quarter. Marty Gagan similarly promotes focus in product-led organizations suggesting only 1-2 OKRs per team – and no personal OKRs.
Christina Wodtke, RADICAL FOCUS second edition p. 139
The rhythm seen from a helicopter perspective
Highly inspired by Christina Wodtke, this is an example of the overall and general hierarchical structure of OKRs:
You might be thinking “this has clear similarities to some of Scrum’s ceremonies”. Yes – you are right, but OKRs do not have Scrum as a prerequisite, or the other way around for that matter. When it comes to implementing OKRs in an organization using some form of e.g., Scrum / Kanban you’ll of course need to define an relevant implementation strategy ensuring synergies and not overlap between frameworks.
Later in this post we’ll shortly discuss the scenario implementing OKRs in a product-led organization already experienced with Scrum.
The OKR cycle good practice is to have four cycles per year – not too many and not too few.
Each OKR cycle starts with OKR Planning. As stated above, the planning should be a combined top-down and bottom-up approach.
Christina Wodtke suggests having a weekly Monday OKR commitment aligning all on the intention for the week (and celebrate the achievements in the coming weekly Friday check-in).
The weekly OKR team check-in will typically have a structure well-known from the daily Scrums:
- What is being worked on?
- What is the status of our Key Results?
- Are there any impediments or dependencies that are blocking the work?
The OKR review at the end of the each OKR cycle will often have a structure well-known from Sprint Reviews in Scrum:
- Presentation of the results
- Recap of the learnings and their implications
- Questions and feedback
The OKR Retrospective has the same purpose as the Sprint Retrospective in Scrum – integrate learning with the purpose of doing even better in the next cycle. You’ll find many creative examples of how such Retrospectives are done. I’ve found the “should-did” method effective (maybe a future post will elaborate on the method):
An often-cited example from Google
Supporting the work on the Chrome browser, the Google team used OKRs and Initiatives. This story is also mentioned by John Doerr in the TED Talk video below.
- Objective: Develop the worlds most successful browser
- Key Results: At least 20 million active users per week end of 2008
- Initiatives: Develop (also) a version running on Macs
As explained by John Doerr in the video, the KR ambition was raised a number of times:
OKRs in a product-led organization
The OKR framework is a general tool from used in our personal lives to strategy alignment in very big organizations. In this example we’ll assume the specific context of a product-led organization, highly inspired by Carty Cagan. Below is a general structure of such an organization – here with a certain size calling for numerus engineering and product directors / managers and multiple product teams. To quote Marty Cagan:
Marty Cagan
Should you not agree with this quote, I suggest reading EMPOWERED. You’ll come to realize that an organization definitely needs strong leaders/managers. Note that there is no natural law stating that bureaucracy is a consequence – but if you do not pay attention to the built-in autopilot, then you will grow bureaucracy.
Product Team
The key organizational concept here are the Product Teams, each often responsible for some significant part of the organizations product offerings or technology.
Marty Cagan supplies these characteristics of such a Product Team:
- is stable and cross-functional
- is autonomous (though some dependencies will exist in practice)
- is self-organized
- is given a (hard) business / customer problem to solve
- is empowered to Discover the right solution to the problem
- is measured & held accountable for the Outcome (business result)
- perceives itself as a group of missionaries with a cause
Marty Cagan
Strategic Product Leadership
In this earlier article, you’ll find a description of the Head of Technology and the Head of Product. The essence is that they’ll provide the strategic context / North Star for the product teams. Yes – the product team is highly empowered to discover the right solution to a given problem, but it needs to be within an agreed strategic context.
Tactical Leadership / Management
These people-managers have a number of important responsibilities e.g.,
- staffing of Product Teams in accordance with the Team Topology as decided in the Product Vision
- coaching
- agreeing on and tracking (typically on a weekly basis) Team Objectives / OKR
- 1-2 objectives per team spelling-out the problems they are being asked to solve
- teams must propose clear measures for success (KR) and discuss with management
Product Team OKRs
Marty Cagen is very explicit when the use of OKRs makes sense:
Marty Cagan in Radical Focus second edition p. 165
Highlights on OKRs from Marty Cagan's books INSPIRED and EMPOWERED
Good Objectives
- Must describe problems to solve – some are customer problems, some are business problems
- Qualitative
- 1-2 objectives (less is more) per team spelling-out the problems they are being asked to solve. Note: Enforcing Christina Wodtke’s point on the need for focus.
- Will often require cross-team collaboration to achieve
- Longer-term objectives need to be broken-down the work into intermediate product results
Good Key Results
- Tells us how we define success
- Must be defined by business results (outcome) – not just output
- 2-4 KR per objective. The first KR is normally the primary measure
- One or more KR as a measure of quality [guardrail / backstop KR] because the primary KR must not be achieved by hurting something else. Note: Christina Wodtke uses the term “Health Metrics” for these quality KRs
- Best OKR comes in active dialogue with the team. Teams must propose clear measures for success (KR) and discuss with management with the purpose of ensuring a strong ownership in the team. Leaders to provide guidance on how aggressive the team should be in pursuing solutions
- Be aware of the temptation for teams to define a KR that is easy to measure vs what is most meaningful to measure
Assigning work
- We’re asking teams to solve (hard) problems – we’re not asking empowered teams, held responsible for the Outcome, to build features
- It is the responsibility of the Leaders to decide which problems should be worked on by which Product Teams. Objective assignment often requires iteration with leadership and team contributing in a mixed top-down / bottom-up process. Note: As mentioned above, one of the pitfalls to be avoided is a top-down only cascading approach
- The objectives are determined from the Product Strategy being part of the strategic context provided by Strategic Product Leadership. Four main reasons for the importance of sharing the strategic context (vision / strategy) with the team:
- The goal and the why
- We’ll assign work to those closest to the problem and with the needed skills
- Because we’re asking teams to solve problems, the teams must take responsibility and be accountable for the desired outcome
- Teams are provided space for and empowered to Discover the right solution for the problem
- An empowered product team will not stop (as a feature team would) if first solution does not work … it’ll continue to iterate
- Teams are not “only” responsible for team objectives – critical fixes, responding to customer issues, providing assistance to other teams, technical debt etc. are also included. Marty Cagan calls this “keep-the-light-on” work
- It is a leadership responsibility to set the level of ambition (in Discovery work), which is all about risk-management ranging from “roof-shots” to “moon-shots”. Leadership needs to communicate very clearly on this level of ambition
- Sometimes high-integrity commitments on dates are required from the Product Team. High-integrity commitments must be the exception; not the rule (which would bring us back to the roadmaps)
Product Vision and -Strategy as the context of planning OKRs
The Product Vision serves the purpose of
- providing meaning
- keeping us focused on the customer
- acting as a North Star providing the overarching / common goal / larger purpose across the organization
- helping teams understand how their work contribute to the large whole
- inspiration for ordinary people to create extraordinary products (note the sub-title of Marty Cagan’s EMPOWERED)
- providing enough clarity enabling the product organization to have an architecture in place – but – do not build a full architecture in one massive effort (start with a Minimum Viable Architecture)
- a primary driver for deciding the team topology; especially the platform teams are heavily impacted by the vision & architecture
- an evangelism tool
Elements in the creation of the Product Vision
- leverages industry & technology trends
- if done well, it’ll be compelling, inspiring and empowering
- needs not to be too detailed / prescriptive which can be a challenging balance
- has a 3-10 years scope
- is owned by The Head of Product – sometimes called the Chief Product Officer [CPO]
- includes a description of the future situation which could include conceptual high-fidelity prototype (realistically looking but only smoke & mirrors), video, storyboarding, prototypes used in product discovery etc.
What the Product Vision explicitly is not
- a roadmap of features & projects
The Product Strategy serves the purpose of
- guiding which problems should be solved
Elements in the creation of the Product Strategy
- tough choices on what is really important (the important focus as highlighted by Christina Wodtke)
- generation of insights
- quantitative insights: Product data, hypothesis test on data
- qualitative insight: User research
- evaluative insight: Result from tests
- generative insight: Did we uncover new opportunities?
- technology insights: The empowered engineers are often the best to spot new enabling technologies
- industry insights: E.g., follow the best industry analysts
- active management (Servant Leadership not to be confused with micro-management): The product leaders must connect the dots / insights in various ways resulting in action; that is, which team should solve which problem (the Objective in OKR)
- remove impediments
- 1:1 – weekly tracking (e.g., OKR) and coaching
Logically the Product Strategy can be seen as a four-step process;
- focus, that is select a small number of truly important company objectives driving the Product Strategy
- generate insights
- action by deciding which Product Teams will work on which Objectives (Problems), allowing a mixed top-down and bottom-up approach
- active management
What the Product Strategy explicitly is not
- a blank check for the teams to do what they prefer to do
Example OKR process with inspiration from EMPOWERED
This fictive company is a job-portal, serving companies and job-seekers.
Examples of some of the team OKRs are shown here:
OKR and Agile frameworks
OKR is based on cycles with different frequencies. So are the various flavors of Agile frameworks. We’re not here to have meetings for the sake of meetings because some framework bible says so. We do not want two overlapping framework tracks with OKRs and some Agile framework. Our aim is to find a balance creating synergies.
OKR and Scrum
The rhythm in Scrum “classic” is given by the its ceremonies, most of (Product Backlog Grooming is not shown) which are found here:
- Sprint: often 1-3 week timeboxed
- Sprint planning: before a sprint starts, the Scrum Team together with the Product Owner (being the one owning the Product Backlog) sets the goals for the sprint and the activities to achieve these goals as Sprint Backlog Items [PBI]. Note: before the sprint planning meeting the Product Owner might have arranged a Product Backlog Grooming session
- Daily Scrum: as the name says – daily (short) meetings
- Sprint Review: each sprint ends with this review in which the team elaborates over / shows the achievements
- Sprint Retrospective: will often be held directly after the Sprint Review with the purpose of structuring newly gained insights to be integrated in the next sprint; making the team perform even better
Below is a suggestion on how to merge the OKR and Scrum frameworks in a pragmatic way:
Pragmatism:
- by only having OKR ceremonies every 2nd week
- by having the OKR ceremonies merged with the Scrum Review and Retrospective ceremonies during the OKR cycle
For each OKR cycle the individual (product) team faces the challenge to meet the agreed OKRs by planning and executing the right work in the six sprints within the OKR cycle.
As elaborated earlier in this post, it is a product leadership / management responsibility to agree OKRs with the product teams for each OKR cycle.
Teresa Torres, Marty Cagan and others describe the product team as “a trio” with a Product Manager, A Product Designer and a small team of Engineers. As described to great depth in INSPIRED and EMPOWERED, the Product Manager role is an especially challenging one. Note that we do not have a Product Manager and a Product Owner. The role as Product Owner is a part of the much larger role as Product Manager. As Marty Cagen outlines here, far too many organizations erroneously believe that getting certified as a Scrum Product Owner at the same time enables the person to act as a Product Manager.
Role
Primary responsibility
Product Manager
Solutions are valuable and viable.
Product Designer
Solutions are useable.
Engineers
Solutions are feasible. In some cases you’ll find senior level engineers taking the role as Tech Lead with additional responsibility of participating in the ongoing product discovery work.
For each sprint the team will agree which items from the Product Backlog (owned by the Product Manager) to pull into the Sprint Backlog. As described earlier – like here, the product team will typically have a dual-agile approach, iterating between Product Discovery and Product Development. Some teams prefer “pure” sprints with either Discovery or Development. Other and more mature / experienced teams are able to shift focus between Discovery and Development within the same sprint. Under all circumstances the team has a guiding star in their OKR set.
In organizations having grown beyond the start-up stage, the Product Managers can reach a stage of saturation with (project management like) activities impeding their primary focus. Some organizations mitigate these impediments by introducing Delivery Managers.
These delivery managers are typically also the Scrum Masters for the teams (if they have that role).
If your company does not have delivery managers – by whatever title – then this work typically falls to the product manager and the engineering managers.
Marty Cagan, INSPIRED p. 91-92
The product trio supported by the delivery manager must be able dynamically to shift focus between the OKR level and the very specific now and here Sprint Backlog activities.
OKR and Kanban
The comments are basically the same here as for Scrum; the big difference is another set of ceremonies.
Scaling
This is a subject responsible for numerus wildfires on social media. Try Google “scale Agile”. According to Marty Cagan, we’ll find basically two and very different approaches to scaling:
Fundamentally, as organizations grow, there are two main ways today that organizations attempt to scale.
One is by scaling their leaders (the managers). The other is by scaling their process.
It is no secret that Marty Cagan is a firm believer in the first approach – scaling by leaders/managers (read his books) – and definitely not a fan of the latter. He is not alone:
There is no correlation between the size of the organization and it’s approach to scaling. The FAANG (Facebook, Amazon, Apple, Netflix, and Google) companies are definitely big, but they scale (primarily) by leaders / managers. They are all digital natives and grown out of a startup environment.
In contrast you’ll find a lot of other high-tech companies definitely having chosen the path of “scale by process”. My experience is that these companies often come from a classic production mindset and are definitely not digital natives. Having seen the writing on the wall, these companies have entered a digitalization catch-up game. Many of these organizations have chosen to use SAFe.
Implementation strategy
As concluded earlier, implementing the OKR framework is not easy and calls for a well-thought implementation strategy. As mentioned in numerous posts in this BLOG (like here), a well-proven strategy is to start small with an experiment, and have the change ripple from there.
Some organizations will find it hard even to design and run such an experiment. Others, like a product-led company with a strong Product Culture, will find it much easier because running disciplined experiments is an integrated part of their modus operandi.
A simple yet strong way forward is to have a, carefully selected, team use the OKR framework. Their success is the most convincing argument you’ll ever find for other teams wanting to join the ride.
OKR Tools
On the long run you’ll undoubtedly benefit from a strong IT tool. But – start pragmatically with e.g., a whiteboard / excel file making you focus on learning the framework; not the tool.
Inspirational sources
A lot have been written about OKRs and the best way to use the method. In my list of inspirational sources, you’ll find e.g., these books addressing the topic:
At a TED Talk in 2018, John Doerr (author of Measure What Matters) provided the essence behind the OKR method:
OKR is not the only strategy framework around
Yes – OKR has become very popular in high-tech and fast moving product organizations, but not the only student in the class. Just to mention a few:
- The Balanced Scorecard
- Hoshin Planning
- Objectives, Goals, Strategies, Measures [OGSM]
- KPI
- The 4 Disciplines of Execution [4DX]
- …
OKR nor any alternatives are silver bullets. They each come with pros and cons. A future post might dig into the various strategy frameworks – and how to combine them.