This article was originally published in my free bi-weekly newsletter, Continuous Learning. You should sign up.
In our new book, Josh and I walk through how to create OKRs from strategy from both the top-down AND bottom-up—meaning, leadership sets the strategy and high-level OKRs for the organization, and then each business unit and team creates their own OKRs that ladder up to the high-level ones and gain leaders’ approval. This is how we teach teams to scale OKRs, but some do it differently. There’s one really important caution to keep in mind when it comes to scaling OKRs, though: The bigger your organization, the more careful you should be to avoid “cascading” OKRs.
What do we mean by this? And why should you avoid them? Here’s an excerpt from the final chapter of our book, which answers those questions.
What are “cascading” OKRs?
There’s a school of thought in the OKR community that recommends a process where management sets a high-level goal and then prescribes how that goal cascades down through the organization’s individual business units and teams (hence, “cascading” OKRs). Essentially, leadership is dictating goals from the top. This central planning approach has a surface appeal.It seems simple and fast. It allows a relatively small number of leaders to maintain a lot of control and make goal-setting decisions quickly. There’s a problem though: It rarely works.
Why cascading OKRs don’t work
Think about it this way: The bigger your organization, the more important and complex it becomes to set OKRs, especially if the leaders at the top are the ones doing the setting. When your organization grows, leaders get further away from customers. This is natural and inevitable. It’s also a big risk. OKRs, if used correctly, ask the people who are closest to the customer to be deeply involved in the goal-setting process. It gives them ownership of their work because they chose it and it’s within their sphere of influence. This taps a critical resource in the organization and brings it into the planning process. Cascading OKRs ignore this source of knowledge,and planning is invariably worse for it.
Build a family tree instead
So, instead of cascading, think of scaling your OKRs like building out a family tree. Every OKR needs to have a parent. A child OKR should clearly support the parent OKR.
This has three main benefits:
- Every goal set at every level of the organization supports the higher purpose. You can trace it all the way up to the strategy.
- Every goal has an owner. Owners drive accountability.
- Leaders still get a top-down discipline while allowing for flexibility and creative contribution from the bottom up.
Being able to trace the “lineage” of each OKR ensures we don’t have any orphan goals floating around in the company. It ensures each person, team, team of teams, business unit, and department is pulling in the same direction—toward the shared high-level, strategic goal. It also provides a level of control over an entire portfolio of work. We can quickly see how well a team of teams is progressing toward their goal as well as the impact they’re having on the broader organization, for example. This is particularly helpful as OKRs are scaled up into the hundreds and thousands of teams. At the highest levels of an organization, it also gives us a clearer sense of how much of the work we’re doing is actually moving us forward toward the strategy—a key metric in operational efficiency.
Once leadership has finished setting the high-level OKRs for the organization, ask every department and team to set their own team-level OKRs. The constraint that they must respect here is simple: Lower-level OKRs must support the higher-level objectives set “above” each team in the organizational hierarchy.
Want to get started for free? Try my 5-day email course, The OKR Repair Kit.