Most OKR rollouts stall on a question that sounds sensible and usually sends the whole design in the wrong direction.
Should goals cascade top-down, or should teams set their own?
I've heard that question in leadership offsites, PMO workshops, and scale-up planning sessions. It sounds like a design choice. It isn't. It's a governance choice. The underlying issue is simpler and more uncomfortable. Where does alignment need an explicit connection, and where does forcing that connection just create process, delay, and low-grade compliance?
That matters because an okr cascade can either sharpen execution or bury it. Used well, it creates line of sight between company priorities and team outcomes. Used badly, it turns into a neat-looking hierarchy of goals that nobody really owns.
My view is straightforward. Pure top-down cascade is too rigid. Pure bottom-up is too loose. Selective cascade is better. Leadership should set the few priorities that require shared movement across the business. Teams should then respond to those priorities with OKRs they own.
That's the model I've seen work.
The OKR Cascade Question We Get Asked Most
Most leaders ask the wrong question first.
They ask whether the organisation should run a top-down cascade or a bottom-up model. That framing assumes the only choices are control from the centre or freedom at the edges. In practice, both extremes fail for predictable reasons.
An okr cascade is not mainly about structure. It's about decision rights. It's about who defines direction, who translates it, and where you need hard links between priorities versus looser alignment. If you treat it as a formatting exercise, you get polished slides and weak delivery.
The false binary
Top-down cascade promises order. Bottom-up promises ownership. Leaders often pick one based on ideology, not operating reality.
That's a mistake.
A business doesn't need every objective to flow neatly through every level. It needs the right connections in the right places. Some company priorities depend on coordinated action across Product, Commercial, Operations, and People. Those need visible linkage. Other work should stay with the teams closest to the problem.
The best OKR systems don't ask, “Can we cascade this?” They ask, “Should we?”
If your leadership team is still debating the basics, it helps to reset on what OKRs are and how they work in practice. But once you're past the basics, the cascade debate becomes a question of operating model design.
What leaders should ask instead
I push clients to answer three questions before they design any cascade:
- What must be aligned at company level: These are the few outcomes that only the business can achieve together.
- What should be team-owned: These are local choices about contribution, trade-offs, and execution.
- What governance will keep both connected: Reviews, planning, and cross-functional decisions matter more than a perfect hierarchy chart.
That last point gets missed constantly. Leaders obsess over whether OKRs should “roll down” and spend far less time on the review rhythm that keeps them alive. That's why the cascade argument is so often sterile. It debates mechanics while ignoring management.
Why Pure Top-Down Cascade Breaks Down
Pure top-down cascade looks excellent in a board pack. The CEO sets three company objectives. Executives create matching functional OKRs. Directors translate those into team OKRs. Everything appears aligned.
Then delivery starts.
What I usually see is not alignment. I see administrative inheritance. Teams copy language from above, swap a few verbs, and write goals that satisfy the cascade requirement rather than reflect the work that will move the number.
Why neat hierarchy turns into compliance
The problem starts with ownership. If a team is handed an objective instead of being asked to define its contribution, the conversation changes. People stop asking, “What result can we influence?” They start asking, “What wording will get this approved?”
That shift is fatal.
Review meetings become upward reporting sessions. Teams defend status. Leaders inspect progress against inherited goals. Nobody wants to admit that the original breakdown was wrong, so weak OKRs stay in place longer than they should.
This is one reason tall structures struggle with OKRs. The more layers you push through, the more distortion you create. If you're dealing with that problem already, it's worth looking at how tall organisational structures slow decisions and muddy accountability.
The governance trap
Strict top-down cascade only works when leaders actively govern it. Cascade without rhythm becomes drift with paperwork.
Practical rule: If you need a strict cascade, you also need disciplined review cadences. Without them, the chart lies.
A common failure pattern
A product team gets handed a company objective around retention. Leadership expects a direct cascade. The team writes key results around shipping features because that's what it can control quickly. Commercial writes pipeline OKRs because it reads the same company objective through a revenue lens. Customer Success writes response-time improvements.
All three teams can claim alignment. None are working from a shared view of what moves retention.
That's why pure top-down models disappoint. They create visible linkage but weak translation. They look rigorous because every box has a parent box. But the quality of the connection is poor. The organisation confuses inheritance with understanding.
The Inevitable Failure of Pure Bottom-Up OKRs
Pure bottom-up OKRs usually emerge as a reaction to bad top-down experiences. Leaders decide they want real ownership. So they let teams set goals based on local knowledge and customer reality.
I understand the appeal. Teams often write sharper OKRs when they aren't constrained by a hierarchy chart. They know the bottlenecks. They understand the trade-offs. They can move fast.
The problem is that autonomy without a clear strategic frame creates fragmentation. Teams optimise locally. The business doesn't necessarily move coherently.
High ownership, weak coherence
I've seen this many times in product-led companies. Product focuses on activation. Sales focuses on new logo acquisition. Operations focuses on efficiency. Customer Success focuses on service quality. Each team has sensible OKRs. Each team can defend them.
But leadership still can't answer a basic question. Are these efforts adding up to the company's actual priorities this quarter?
When they aren't, OKRs don't solve silos. They formalise them.
The hidden conflict leaders miss
Bottom-up systems fail undetected. That's what makes them dangerous.
Nobody is obviously resisting strategy. Teams are engaged. Work is progressing. Dashboards move. The issue only appears later, when the executive team realises that effort has been spread across too many priorities and cross-functional dependencies were never resolved.
Here's a simple example:
| Team | Locally sensible OKR | Strategic risk |
|---|---|---|
| Product | Improve engagement with new features | May increase complexity when the business needs retention simplicity |
| Sales | Increase new customer acquisition | May sell segments the product can't support well |
| Operations | Reduce service delivery cost | May constrain investment needed for growth |
Each OKR is defensible on its own. Together, they can pull the company in different directions.
If every team owns its own success definition, leadership no longer has a strategy system. It has a collection of local optimisation loops.
That's why so many programmes stall. If you want the broader diagnosis, this is exactly how over-engineered or poorly aligned OKR systems fail in practice.
Bottom-up is not a strategy substitute
I'm in favour of team input. I'm not in favour of strategic abdication.
Leadership has to name the few company outcomes that matter most. Teams should shape the response. They should not have to infer the company's direction from a workshop prompt and a blank template.
A Better Approach The Selective Cascade Model
The best okr cascade is selective.
Not partial because leadership lacks conviction. Selective because not every outcome needs the same level of vertical connection. Some priorities need direct alignment across functions. Others need local ownership and flexibility. Treating both the same is what creates either bureaucracy or chaos.
Responding is better than deriving
This is the distinction I care about most.
Deriving means a team is handed a parent objective and expected to reproduce it at a lower level.
Responding means a team understands the company priority and defines its own best contribution.
That difference changes behaviour immediately.
When teams derive, they mirror language. When teams respond, they make choices. They weigh trade-offs. They define an outcome they can own. That's where accountability becomes real.
What selective cascade looks like
At company level, keep OKRs for the few outcomes that require enterprise-wide movement. Usually that means a small number of priorities that cut across functions and need senior trade-offs.
Below that, ask each function or team to answer a harder question: given this company priority, what contribution can you credibly make this quarter?
That is not the same as forcing a one-to-one cascade from every company KR to every team KR.
Direction should come from the top. Translation should happen closer to the work.
If you want to build this into the quarterly cycle, the key design choices usually happen during OKR planning and alignment before the quarter starts.
A practical design pattern
I recommend something like this:
- Company OKRs for shared outcomes: Use these for the few priorities that need coordinated effort across multiple functions.
- Functional OKRs as contribution choices: Ask functions to define what they will move, not to copy company wording.
- Team OKRs only where they add clarity: Don't force every team into the same structure. Some should align through initiatives, metrics, or shared delivery commitments instead.
Decision filter: If a team can influence a company priority directly, connect it. If the connection is indirect or stable, don't force a formal cascade.
What this prevents
Selective cascade avoids two common errors:
- Compliance theatre from the top-down model: Teams aren't writing goals just to satisfy hierarchy.
- Fragmentation from the bottom-up model: Leadership still names the few priorities that matter across the business.
It also improves the quality of conversations. Instead of arguing over whether a team has “fully cascaded” an objective, leaders can test whether the proposed OKRs are the right strategic response. That is a much better conversation.
When a Direct Cascade is Essential
Selective cascade should be your default. It should not be your dogma.
There are moments when leadership needs to impose a direct connection because ambiguity will cost too much. In those situations, a looser model creates lag, mixed signals, and wasted effort.
Scale and coordination raise the cost of interpretive freedom. At that size and pace, direct cascade earns its keep.
Cross-functional outcomes
When a result depends on multiple functions moving together, leadership should name it explicitly and cascade it clearly.
A market launch is a good example. Product, Marketing, Sales, Legal, and Operations all need to make compatible decisions. If each team writes its own interpretation of the priority, the launch slips or fragments. In that situation, direct cascade creates a shared frame and forces trade-offs into the open early.
Strategic pivots
When the company changes direction, you cannot rely on gradual alignment.
If the business is shifting from growth at any cost to efficient expansion, or from one segment to another, old priorities linger unless leadership replaces them decisively. Teams keep funding yesterday's logic unless the new priority is visible, explicit, and essential.
Leadership should cascade hard when the cost of mixed interpretation is higher than the cost of reduced autonomy.
New strategic bets
A new product line, new region, or new capability often loses out to business-as-usual work unless it is protected.
That protection usually comes from a direct company-level OKR that forces resourcing decisions. Without it, established teams tend to keep serving current demand. That's rational from their perspective. It's also how new bets die slowly.
A quick test
Use direct cascade when all three conditions are true:
- The outcome is cross-functional
- The business needs speed of alignment
- Leadership is willing to govern it actively
Miss the third condition and don't bother. Direct cascade without follow-through creates confusion faster than a lighter-touch model.
Where Cascade Creates More Problems Than It Solves
Many OKR systems suffer from over-connection. Leaders assume that if some cascade is good, more must be better. It isn't. Forced linkage deep into the organisation often adds noise, not clarity.
Don't cascade deep into execution
Delivery teams close to customers, systems, and workflow constraints usually know more than senior leaders about what should happen next. If you force a rigid cascade into that layer, you reduce judgement where you most need it.
Engineering teams, product squads, and specialist delivery groups often need room to respond to technical reality. Give them strategic context. Don't script their quarter from the top.
Leave stable mandates alone
Some functions do not need to reinvent themselves every quarter to prove alignment.
Finance operations, core HR services, internal IT support, and similar teams often operate with stable mandates. Forcing them to create fully cascaded OKRs every cycle can turn routine but critical work into a performative exercise.
Be careful with regulated or sensitive environments
Rigid okr cascade design can also create exposure that standard guides ignore. Cascades can expose sensitive key result data — sales pipeline figures, headcount decisions, commercially sensitive targets — across teams that have no need to see them.
I've seen leaders push for radical transparency without thinking through which KRs contain commercially sensitive or personally identifiable information.
Not every KR should be visible to everyone. Alignment does not require careless exposure.
A better rule for these cases
Use lighter mechanisms where formal cascade adds friction:
- Shared operating metrics: Useful for stable functions that need continuity more than quarterly reinvention.
- Contribution statements: Good when a team supports company priorities indirectly.
- Initiative alignment: Better for specialist teams whose work is important but not best managed through nested OKRs.
If the cascade is making good teams spend more time proving alignment than creating it, you've gone too far.
The Ultimate Test for Your OKR Cascade
Forget the perfect hierarchy map. Forget whether every team can point to a parent objective in the software.
I use one test.
Ask any team, “If you achieve your OKRs this quarter, what company priority does that move forward?”
If they can answer immediately, clearly, and specifically, the cascade is working. The connection is real. It lives in decisions, not just in documentation.
If they hesitate, give a vague answer, or talk only about their own deliverables, the cascade is broken. That might mean leadership never clarified the priority. It might mean teams were told to inherit goals they didn't understand. It might mean the planning process created links on paper that never became management conversations.
What a good answer sounds like
A strong answer is specific. It links the team's result to a company outcome without stretching.
A weak answer is abstract. It sounds like “supporting growth” or “helping the strategy” with no real line of sight.
That's why governance matters more than diagrams. If you want to sharpen that discipline, use an OKR checklist that tests alignment, ownership, and measurability before launch.
My recommendation
Run selective cascade by default. Use direct cascade selectively. Reject pure bottom-up unless you enjoy strategic drift. Reject pure top-down unless you are ready to govern it tightly.
If you want the broader operating model behind that approach, look at how alignment works beyond the cascade structure and designing the governance model for OKRs.
If your leadership team is stuck on the cascade debate and not making progress, let's talk. I work with UK scale-ups and enterprise teams to design practical OKR systems — fixing the alignment gaps, clarifying priorities, and building a model people can actually run.