OKRs are networks, not hierarchies

They don’t cascade, they integrate

Photo by Alina Grubnyak on Unsplash

If you use objective and key results (OKRs) as part of your practice you have probably struggled to make them fit together across the organization. Many groups use a simple hierarchy of OKRs so that they flow down, up, and meet in the middle to match the way that their organizations are set up.

Both our clients and our own teams use OKRs to build a better connection between the strategy of the organization and the work that individuals do in their teams. Our clients find that this isn’t always easy when they haven’t built a good separation of ownership between their leaders and the teams. They tend to think about how the goals cascade down from the top to the bottom.

The OKR methodology can help this but thinking about OKRs as a hierarchy recreates a lot of the same problems these teams are trying to fix. You get right back into the process of requiring leadership to approve the exact work that people will be doing. This process requires more time since it isn’t distributed across the entire team figuring it out. The person at the top of the hierarchy needs to set everyone’s work and then trickle it down.

I’ve been doing OKRs at both small and large organizations previously but it wasn’t until I listened to a podcast on networks of OKRs by There Be Giants (the rest of their OKR podcast is great too!). They identify a huge list of issues based on the fact that OKRs are created as hierarchies:

1. “Top” of the hierarchy will tend to be comprehensive and generic OKRs — this is bad because it is meant to spotlight the key objectives, not all possible work. People start asking “if my department isn’t counted does my team matter?”
2. Hierarchies cascade down the OKRs more often than meeting in the middle — which ends up micromanaging the work that people are doing on the teams.
3. “Lower” teams in the hierarchy inherit initiatives — they just take key results and turn them into objectives. This is bad because objectives shouldn’t be metrics. Then the teams end up with a lot of unimportant OKRs that cascade into the higher ones.
4. A person near the “top” of the hierarchy ends up owning the OKRs — people “lower” in the hierarchy loose understanding of the purpose and don’t control their own work.

In the end, hierarchical structures make it easy to lose sight of why you are trying to achieve something. The complexity, lack of autonomy, and strategic impact can damage culture. It stops the organization from fixing the aspects they wanted to avoid in the first place by using OKRs.

OKRs don’t exist in a vacuum

What people often forget is that OKRs aren’t a singular artifact for a team. They exist alongside many other artifacts that build a cohesive picture of what an org and the teams do. When people forget this point they feel the need to have OKRs do the heavy lifting of all documents. The OKRs are there as a feedback mechanism for the teams and how well they are aligning to the strategy of the organization. It is there to help make hard decisions on prioritization easier for each team.

Don’t make OKRs be everything to everyone!

Each team will have something like a charter and a scorecard which is meant to be comprehensive.

First, the charter is a document (or often a slide in an organizational slidedeck) that outlines the teams that are part of a group, how they work with other groups, and what they ‘own’ inside the org.

Second, the scorecard is a document (or dashboard somewhere) that shows all of the different metrics, KPIs, and business impacts that the team cares about.

If we have these two artifacts we take pressure off the team from making sure that everyone’s work is spoken for in the OKRs.

Building a network of dependent OKRs

The network that is built between teams is based on dependencies. Dependencies of delegation, shared work, supporting work, etc. Hierarchies don’t work because they assume that there is some flow of work down.

When was the last time that a CEO cared about a team’s operational role? They don’t focus on them and don’t make space in their strategy but the operational role needs to exist.

There are four main ways that dependencies can be built in OKRs:

1. Whole OKR — they share an objective and its key results. This is generally because that OKR is both a team and org (or both team’s) priority.
2. Only an objective — the teams share the objective but have different key results that they have the ability to track and effect.
3. Only a key result — the teams share (or contribute to) the same key result but have different objectives which they are looking to achieve.
4. Not at all — the teams don’t have dependencies between them.

Here is an example visualization of a network for OKRs:

Network of OKRs template, originally from Mauricio Franzoni of nintex and modified by me.

As you can see there are a few important dependencies between OKRs:

• The Org and Product teams share an objective but not key results for that objective.
• The Org and Marketing team share a key result but not the overall objective.
• The Product and Marketing teams share key results since they are tracking the same KR.
• The Operations team doesn’t network into The Org (or any other team) but their work is still valuable to the organization as a whole.

In fact, teams inside of an organization tend to have common patterns of dependencies based on the type of teams they are:

• Product teams — usually share objectives with the greater organization and each other. This is because they are the main way that objectives are met is through building new or better experiences.
• Enabling teams — they share key results since they amplify the work that product teams do, like marketing and platform product teams.
• Shared teams — teams that support multiple other teams, like operations, don’t usually share objectives or key results since they focus so much on removing waste from the system and making things more efficient. This is not the same thing as building a brand new experience.

OKRs are a strategy Trojan horse

The reason why it is so hard to build great OKRs is because they require a real strategy to be implemented. Without a knowledge of strategy across the organization a network of those OKRs can’t be properly built either.

Remember that the organization is a network for teams that are looking to achieve a main outcome but will focus on different work to achieve that outcome. They will have outcomes that help lead to the overall mission being completed.

Don’t cascade OKRs, network them!