There is a diagram that shows up in almost every OKR presentation. The company objective sits at the top. Underneath it, each department’s objectives branch out. Underneath those, each team’s, and then each individual’s, in a tidy pyramid where everything traces neatly upward to the company goal. It is a beautiful diagram. It is also, in my experience, a fairly reliable way to break an OKR system, and it is worth understanding why before you build your own org chart of objectives.
What cascading actually does
Pure cascading works top-down and mechanically. Leadership sets the company OKRs. Each layer below takes the layer above and decomposes it into sub-objectives, which the next layer decomposes again, until every individual has objectives that are, in effect, a slice of their manager’s, which are a slice of their manager’s, all the way up.
On paper this guarantees alignment. Everyone’s work ladders up to the top-level goal, so nobody can be working on anything that does not serve the company’s stated priorities. The appeal is obvious, especially to leaders who worry that without this rigid structure, teams will wander off and do their own thing.
Why it breaks in practice
The problem is that cascading assumes the people at the top know enough to specify, in advance, what every team below them should be trying to achieve. They almost never do, and pretending otherwise causes three predictable failures.
The first is that it is slow. A strict cascade cannot finish until each layer waits for the layer above to complete its objectives. By the time the cascade reaches the bottom, weeks of the quarter are gone, and the people closest to the actual work have spent that time waiting rather than working.
The second is that it destroys ownership. When my objective is just a decomposed fragment of my manager’s objective, handed down to me, I did not set it and I do not really own it. I am executing someone else’s plan. OKRs are supposed to engage the judgement of the people doing the work, and a pure cascade specifically removes that judgement from everyone except the top layer.
The third and worst failure is that it propagates mistakes perfectly. If a leadership objective is slightly wrong, and leadership objectives are often slightly wrong because they are set with the least operational detail, the cascade faithfully pushes that error down through every layer. The structure that was supposed to guarantee alignment instead guarantees that everyone is precisely aligned to the wrong thing.
What aligning does differently
Alignment keeps the goal of cascading, which is that work connects to company priorities, but it changes the mechanism. Instead of objectives being handed down and decomposed, teams write their own objectives and then explicitly connect them to the company objectives they intend to support.
The direction of authorship is the key difference. In a cascade, the objective comes from above and you receive it. In an alignment model, the objective comes from the team that owns the work, and that team is responsible for showing how it serves the level above. The team brings its operational knowledge to bear on what the objective should actually be, and leadership’s role shifts from dictating objectives to reviewing whether the connections make sense and the priorities are genuinely covered.
This is messier than a clean pyramid, and that messiness frightens people who want the org chart of objectives to be perfectly tidy. But the mess is the system working. It means real judgement is being applied at every level rather than just at the top, and it means a flawed top-level objective gets questioned by the people who can see the problem rather than silently inherited by everyone beneath them.
You still need to see the connections
The legitimate worry about alignment is that without the rigid pyramid, you lose visibility into whether everything actually connects, and whether some company priority has quietly ended up with no team supporting it. That is a real risk, and it is the thing alignment models have to actively manage rather than assume away.
The answer is not to go back to cascading. It is to make the connections visible and reviewable. You want to be able to look at a company objective and see every team objective that has been linked to it, and just as importantly, to spot any company objective that nothing has been linked to, because that gap is a priority nobody has picked up. Maintaining that map by hand across a real organisation is close to impossible, which is the honest practical reason teams reach for proper OKR software like Profit.co, since the value is precisely in being able to see how bottom-up objectives connect to top-level goals without forcing the rigid top-down decomposition that causes alignment to fail in the first place.
Align by default, cascade only where it genuinely fits
None of this means cascading is never appropriate. In parts of an organisation where the work really is a clean decomposition of a higher goal, a sales target broken into regional targets broken into individual quotas, cascading is natural and fine. The mistake is applying that logic to the whole company, including all the parts where the people doing the work understand the problem better than the layer above them.
The default should be alignment, with teams authoring their own objectives and connecting them upward, and cascading reserved for the specific cases where decomposition genuinely reflects how the work breaks down. Get that default right and you keep the alignment that cascading promises without inheriting the rigidity that makes it break.
