Watch how OKRs actually cascade in a company of any size and you find a quiet arithmetic problem nobody planned for. Company-level objectives get set in the first week of the quarter, after the leadership offsite. Divisions need to digest those before they can write their own, so divisional OKRs land around week three. Teams wait on divisions, so team OKRs appear around week five. Individuals wait on teams, so individual goals are finalized around week seven. The quarter is thirteen weeks long. The bottom of the organization gets its direction with less than half of it remaining.
This is not a failure of any one team being slow. It is the unavoidable consequence of a strictly sequential cascade, where each layer must finish before the next can begin. The latency is built into the shape of the process, and it means that for the first half of every quarter, most of the company is working toward its best guess of what the OKRs will turn out to be, rather than the OKRs themselves.
The cascade has a settling time
A strict cascade behaves like a slow filter. A change introduced at the top takes time to propagate to the bottom, and that settling time is a structural property of the layering, not a sign anyone is dragging their feet. In a four-layer org with a couple of weeks per layer, the settling time is six to seven weeks. If the quarter is thirteen weeks, the system spends roughly half of every cycle not yet settled, which is a strange way to run something whose entire purpose is alignment.
It gets worse if anything changes mid-cascade. If the leadership team refines a company objective in week four, after divisions have already written against the week-one version, the refinement has to re-propagate, and the lower layers are now chasing a target that moved while they were still receiving it. This is the cascade-specific version of strategy half-life: the instruction decays as it travels, and a long enough travel time means it can decay before it even arrives.
Why the guessing is not harmless
You might think teams simply wait, but they do not, because work does not pause for the cascade. They start on their best guess of what the direction will be, which means the first half of the quarter is full of effort pointed at an anticipated target. Sometimes the guess is right and the cascade merely ratifies what teams already started. Often it is close but off, and the work quietly done in weeks two through six has to be partly redone or redirected once the real OKRs land. Either way the cascade was not actually steering that work. It was catching up to it.
This is one of the mechanisms behind the 26 percent gap between what leadership thinks is aligned and what the work actually reflects. A meaningful fraction of every quarter's effort is spent in the unsettled period, aligned to a forecast rather than a decision. The cascade looks like alignment because eventually everything connects up. It just connects up too late to have steered the early work.
Sequential cascade is the wrong shape
The root issue is treating alignment as a sequence of authoring steps that must complete in order. Each layer rewriting its goals only after the layer above has finished is what creates the latency. But alignment does not actually require sequential authoring. It requires that the work be connected to the objective it serves, which is a question of linkage, not of waiting your turn to write a document.
When a team's work is connected to the company strategy through a live structure, a team does not have to wait for a formal cascade to reach it before it can align. It can see the company objective directly, link its work to it on day one, and adjust as that objective is refined, without the intervening layers each having to finish their own authoring first. The structure carries the connection immediately, so alignment is available in week one instead of week seven, and a mid-quarter refinement updates everyone at once rather than re-propagating layer by layer. This is part of why a goal graph beats a strict cascade: a graph does not have a settling time, because the links are direct rather than relayed.
What to do this quarter
Time your own cascade. Note the date company OKRs are set and the date the last individual goals are finalized, and count the weeks. Then estimate how much work happened in between, pointed at anticipated rather than confirmed direction. That interval is your cascade latency, and the work inside it is your alignment-on-a-guess.
Then ask whether the lower layers actually needed to wait. In most cases a team could have linked its work to a visible company objective in week one and refined from there, rather than waiting for the objective to be relayed down through two layers of document-writing. The waiting is a property of the cascade as a process, not a requirement of alignment as a goal. Remove the waiting and you get back half a quarter of actually-steered work.
FAQ
Why does cascading OKRs take so long? Because a strict cascade is sequential: each layer must finish writing its objectives before the next can start. In a four-layer org at a couple of weeks per layer, the bottom gets its direction around week seven of a thirteen-week quarter. The latency is built into the layered shape, not caused by any one team being slow.
What's wrong with teams starting on a guess? Work does not pause for the cascade, so teams begin against their best guess of the coming direction. When the real OKRs land and differ, the early effort gets redone or redirected. The cascade ends up catching up to work rather than steering it, which feeds the gap between assumed and actual alignment.
Doesn't the cascade still produce alignment eventually? It connects everything up, but too late to steer the early work, and a mid-quarter change has to re-propagate layer by layer, decaying as it travels. That is the cascade version of strategy half-life: the instruction can decay before it arrives.
How do you align without waiting for the cascade? Connect work directly to the objective it serves through a live structure, so a team can link to a visible company objective in week one instead of waiting for it to be relayed down. A goal graph beats a strict cascade because direct links have no settling time and a refinement updates everyone at once.