How we align OKRs (because cascading sucks)

I fully understand the appeal of cascading OKRs. In theory you get:

Amazing visibility
Clarity on execution
Greater focus

But, in practice, this turns into a nightmare 9.9 times out of 10:

It becomes a disguised roadmap
It takes waaaay too much time to build and maintain
It obfuscates real problems in your org
It removes agency

There’s almost never a time where you should embrace a cascading model where every OKR must trickle down from a top one.

It is much easier to let teams align to the top-level OKRs and discuss progress every week. This approach requires 10% of the energy for 10x better results. And you can still let teams ladder up specific OKRs that need to be connected to the top ones.

In this post I want to give you a concrete set of steps to achieve that.

Wait, why does cascading OKRs suck? I don’t get it

The fastest way to get an answer is to watch this short video. The video is 8m30s long, but it covers the topic in detail.

For a brief text explanation lets start by defining the difference between cascading and aligning OKRs:

In a cascading model, every objective must trickle down from a parent key result
In an aligning model, teams can simply write their own plan that best contributes to their parent OKRs

Now let’s talk about just 2 of the main issues with the cascading model.

Problem 1: It becomes a disguised roadmap

As Damien points out here, the job of OKRs is to help teams understand what big problems they need to focus on. It elevates the discussions to talk about desired impact (faster growth, better user satisfaction, increased retention, more productive teams…) instead of listing a bunch of solutions.

When we’re using OKRs we’re admitting that, although we have clarity on what we want to achieve, there’s uncertainty and risk on how to achieve it. So we need a tool (the OKRs) to help us maintain focus and quickly understand which bets are working, and which bets are failing.

When teams start cascading the OKRs, the approach pushes them to build a solution tree. This starts as soon as someone writes something like “make product X successful”. What ensues is a list of activities (“identify problems”, “build prototype”, “deliver alpha version”...) that will push people to write more activities further down.

You’re now building a roadmap.

Teams that have to cascade OKRs often resent the framework as a result. Instead of empowering them (you give them problem areas, they find the solutions), the OKR tree removes agency as it’s yet another backlog of things to deliver.

Problem 2: It’s super expensive to manage

It takes 2-3 weeks for any leadership team to come up with the top-level OKRs.

This means that the layer #2 of OKRs can only be started on week 3-4. And it’s going to take another 1-2 weeks for people to agree on these OKRs.

So, for a team on the 3rd level (company → department → team), it can take 4-6 weeks before they can draft their plan.

This sucks.

And what sucks even more is that if anyone above has made 1 mistake then everything under that mistake needs to be rebuilt.

Ok, so how do we align teams instead

Step 1: Define the top-level OKRs

This doesn’t change. You need to start at the top and define the top-level OKRs for the quarter.

The good news though is that teams won’t have to wait for the KRs to be fully completed to start drafting their own OKRs.

Step 2: Teams can draft their own OKRs!

As soon as:

The top-level objectives are locked
The top-level KRs are drafted (targets may not be decided, but we’re clear on how we’ll measure success for the objectives).

Then, departments and teams can start drafting their own OKRs.

Let me give you an example.

If one of the top-level objective is “Develop Europe as a new market”, and we’ve agreed that we’ll use a region-specific revenue and customer count as success metrics, then all teams can start thinking about their best way to contribute.

A useful approach is to start by repeating the objective “Develop Europe as a new market” and then to figure out which KRs are relevant for the specific team:

Marketing may have KRs relating to MQLs, conferences, local influencers
Sales can have KRs touching regional pipeline size, targeted outreach, and maybe local hires
Product might have KRs around languages supported, localization, regional hosting availability

This works because we’re asking teams to focus primarily on the objectives and what that may mean for them. The KRs are here to help frame the objective by defining how big of a swing we’re taking (do we want 10 european customers at the end of Q1 or 100 customers?).

This would have been harder to do in a cascading model because the focus is on the key results first and foremost. Support, engineering, HR, or design will typically find it difficult to create OKRs that must come down from “Secure 100 customers in Europe”.

Step 3: ladder up the relevant key results!

Aligning OKRs doesn’t mean that you can’t get clear relationships between your OKRs. But, instead of forcing them top-down you let them happen bottom up.

Technically this is how we do it in Tability.

We first create a top-level plan, and then use sub-plans for the team OKRs. You end up with a picture that looks like below (don’t mind the content of the plan, this is sample data from my sandbox).

Now, the next step is to indicate direct relationships between items. For instance, we want to clearly show that the NPS and voted tickets KRs of the Product team contribute to the product review rating KR in the top-level plan.

This is done simply by:

Clicking on the NPS key result.
Click on Add relationship
Select Add parent key result
Pick the corresponding key result

Once you click save, the new relationship is created and you can now have a view similar to the tree that you’d get from a cascading model – without incurring the extra costs.

This is a rant

This is not the first time I’ve written about this (I got an old post about cascading vs. aligning OKRs) but I keep on seeing/reading about teams that are suffering because they’re enforcing a cascading approach or using OKR tools that are forcing them to do so.

There are easier ways to roll out OKRs while also getting complete visibility from a leadership perspective.

And, when we decided to build Tability, this was one of the first design decisions that we made. We went against the trend and built a platform that would promote fast feedback loops and rapid execution around goals.