Cascading OKRs is bad for startups

"Having goals improves performance. Spending hours cascading goals up and down the company, however, does not. It takes way too much time and it's too hard to make sure all the goals line up."
Lazlo Bock, Former VP of People Operations @ Google

This quote above could be the entire post. Cascading OKRs is one of the first questions we get from teams adopting Tability, and my answer is always a variant of "you probably don't want to do that".

Cascading is appealing from the top, but looks miserable from the bottom

Cascading sounds great in theory – imagine if you could follow every goal from the top to the bottom of the company and see how each team contributes to the greater good. We'd get such clarity! Surely it's also a great way to keep everyone aligned since everything is connected.

Beautiful.

But businesses hardly look like a set of dominos (or a football team - wink wink). I previously wrote about the inefficiencies of OKR cascading, but here I want to emphasize some other issues:

• Humans are generally bad at predictions
• OKRs should be about creating conversations, not maintenance work

You'd have to be a fantastic strategist to make cascading OKRs work. Any mistake at the top may drive the rest of the org into a wall. A bad Key Result could snowball quickly into having your entire company pursuing the wrong outcomes.

With cascading, you must be excellent at predicting what will work. And it's precisely why it's not a great model to follow.

Companies like Netflix, Airbnb, Amazon run hundreds of experiments every month because they know that they get things wrong – even with hundreds of the brightest minds focused on their problems. There's no way that a startup stretched in every possible way can make perfect decisions, and it's all the more important for them to be nimble and flexible.

That takes us to the second issue with cascading OKRs. It makes us treat our goals as a network graph. Managers expect to be able to drill down through the entire company at any point of time. Any change in the OKRs will trigger a dance around spreadsheet and docs to repair the relationships. As a result, your team is more concerned with managing the graph than it is about discussing the OKRs themselves.

Frankly, it's another form of micro-management.

Treat your OKRs live vectors, not graphs

A better approach consists of treating each team as its own vector. You can then use OKRs as a simple way to see each team's direction and make sure that they all converge towards a common goal.

‍

OKRs work best when you use them as a communication tool instead of a reporting engine. The framework provides a standard way for your org to talk about focus and progress across functions. Use that to your advantage to create rapid feedback loops between outputs and outcomes.

Having weekly progress reviews (OKRs + roadmap) is a great way to stop worrying about bad goals. Misalignment will naturally surface after a couple of iterations, and corrections are easy to make.

The aim of this process is not perfection. It's agility.

Alignment should not mean having strict control over your team's work. It means having clarity across your organization. Ditch cascading if you want to empower your team to move fast, and replace it with better ways to sync on progress.

Technology is great, but so are we

It's always tempting to fix every problem with more code and features. Why not build a graph? Why not inject some machine learning? Why not suggest dependencies?

The answer for us is that we believe that humans still have the upper hand when it comes down to making sense of complex data. Sometimes it's better to keep things simple and replace complexity with the right conversations.

Going further

• Watch Whitney O'Banner's talk Bottoms Up With OKRs.
• Read about the cost of cascading OKRs.
• See how you can treat your OKRs like code.