Improving OKRs

There’s a form of OKRs described in Measure What Matters which is often repeated in blog posts about OKRs and in the pulpy documentation found in the documentation OKR tool vendors publish. OKRs are not a formalised method so as I’ve written before, OKR documentation includes significant variation causing confusion. The positive side of this is there’s lots of experimentation on how to improve.

At its simplest, it’s 2-4 Objectives with 2-4 Key Results, often set quarterly by each team. Whilst the Objectives are often described as an outcome, the examples of OKRs that are provided usually indicate that what is meant by ‘Outcome’ is very loose and could mean ‘activity’, ‘output’ and very occasionally an actual outcome.

Quite often this approach to OKRs is paired with the nonsensical suggestion of cascading OKRs by using the key results of higher up in the organisation to be as the objectives of the next level down and so on for however many levels of hierarchy exist. I get the appeal, it feels like a neat path for alignment. It just stands up to more than a few moments of thought on what this actually translates to and whether that is valuable for the organisation.

So, what are the ways leading OKR thinkers are improving upon OKRs?

• Ensuring Objectives actually describe an outcome.
• Use a ‘truth statement’ approach to writing objectives, i.e., describe the goal as if it’s true in the future.
• The Objective should not have a numerical component.
• Define key results as symptoms or evidence of achieving the objective.
• Focus: Have as few OKRs as possible
• OKRs align rather than cascade.
• Pairing OKRs with a persistent model which includes longer-term goals linking up to the strategy and purpose of the organisation
• More explicitly reconcile work that brings about change and work that sustains an organisation.

Ensuring Objectives actually describe an outcome.

OKRs can support the empowerment of teams and allow them to take the responsibility of selecting the solutions which they believe may achieve the outcome.

Use a ‘truth statement’ approach to writing objectives, i.e., describe the goal as if it’s true in the future.

This format is inspired by examples of goals you often see in the Logical Thinking Process from the Theory of Constraints body of knowledge. It’s a simple-to-apply method for describing outcomes (often a tough challenge for those without practice) that’s easier to get the knack of.

The Objective should not have a numerical component.

Save these for the key results. This is becoming commonplace in most OKR documentation, but you still occasionally see bad examples which mix the goal and how it’s measured.

Define key results as symptoms or evidence of achieving the objective.

Examples of key results you see out in the wild can feature a broad range of measurable (and sometimes not really measurable) approaches to their definition.

A narrower approach which in my experience leads to more useful key results which are more likely to indicate real progress towards the goal is to think of key results as being symptomatic of achieving the objective or put another way, as evidence of making progress towards the goal. This again will suggest that putting activities as a key result such as completing some work or building something are bad key results and have the causal influence reversed.

Pairing OKRs with a persistent model which includes longer-term goals linking up to the strategy and purpose of the organisation.

The relationships represent the WHY behind the WHAT that the goals represent. They do this to provide their teams with more context and reduce the feeling of starting from a blank slate each quarter which can translate to lots of time wasted and less continuity. More sophisticated performance measurement frameworks such as PuMP use this approach (and many other improvements on how OKRs are typically implemented) and it’s an exceptional complement to any OKR implementation.

As?Mallam Tamon?puts it “Don’t brainstorm your OKRs”- work on being clear on the context. This work can be living documents which evolve as you learn through doing and be reflected in artefacts such as your Purpose, Vision, Strategy and the persistent model of relationships between enduring goals for your organisation which help articulate the rationale for why you believe achieving these will help realise your purpose.

Focus: Have as few OKRs as possible

Guidance for the number of objectives to define is often suggested as 2-4 or 2-5 for any given period. In my experience, an organisation’s ability to focus and still be effective can improve over time but to have success with OKRs, start as simple as possible. This can also inform how an organisation might adopt OKRs. Don’t start with all teams and lots of goals at different levels of resolution. You might evolve to that over time as you build up organisational competencies with OKRs but you are unlikely to have those competencies when you start.

When piloting it may help to focus on a single OKR to familiarise with the concepts and ways to instil OKRs as a practice into your organisation. I often suggest leaders ‘dogfood’ OKRs themselves and know what is involved before introducing OKRs more broadly. Important to know what is being signed up for and the level of commitment required.

Defining at least two OKRs is often the suggestion and I believe a great reason for this is to help think about trade-offs within your organisation. There’s always more than one important thing to trade off against or reconcile with organisations of any size and using OKRs to help make these explicit is a great benefit of OKRs.

OKRs align rather than cascade.

There are many examples online and in Measure What Matters which show how OKRs could cascade from the top of an organisation through the ‘levels’ of the organisation. A common approach suggested is for the key results of a higher-level objective to become an objective for a lower level. Many of these examples are contrived, such as the oft-cited OKRs for an American Football team.

Felipe Castro makes a great case that?OKRs do not cascade?with his central argument being the time it takes. He suggests a better way for all teams to set goals in parallel, allowing for bi-directional influence, for instance, issues which may be important to the organisation but at the coalface get the opportunity to be highlighted and inform the strategy.

This approach leverages the socialisation of goals to enable alignment and adjustment - an approach that can be done in parallel in a much more compressed amount of time. Paired with a persistent model the degree of alignment with the organisation’s purpose and strategic direction remains strong.

This also provides the opportunity for more meaningful learning loops throughout the organisation as objectives can remain focused on outcomes at all levels rather than being converted to output measures after the leadership level which is the result of the cascading approach.

More explicitly reconcile work that brings about change and work that sustains an organisation.

OKRs are generally focused on what is changing so it’s typical for the OKR work to co-exist with the work that typically helps the organisation function at its desired level of performance. This is often described as operational work or Business As Usual (BAU). Operational work is important, it’s usually about the organisation delivering the products and services it provides. BAU is one of those minimising ways of describing work so it’s not a term I like to use.

This work is often managed with KPIs which often get confused with OKRs and because they also involve metrics, they sometimes look like key results. KPIs typically define a threshold and whilst the values of a given KPI fall within this range they will be considered healthy.

OKRs, given they typically focus on change are usually leading indicators focused on shorter time windows and KPIs, which represent the health of what the organisation seeks to sustain, are usually lagging indicators focused on longer timeframes.

With persistent models or driver trees or similar relationships which also show the relationships between metrics, you can reconcile these two types of measurement. You can think of the change an OKR is helping you achieve as moving a KPI to a new, better threshold. You can also use OKRs for managing corrective actions when a KPI has fallen below the threshold that has been set.

What improvements have you seen applied to OKR implementations you’ve been a part of? Share your examples in the comments.