Start by dropping the word “cascade”
I was preparing content on OKRs for an agile team assessment recently, borrowing ideas from my book Assembled. Aligned. Adaptive., when I ran across the word cascading in some old notes, and it stopped me. I've found this word causes a lot of problems when it's used to teach teams about OKRs. In fact, I think it's largely responsible for quietly smuggling the wrong idea into how people learn and apply them.
Picture an actual cascade. Water goes over the edge and lands in the pool below, and the pool below has no say in the matter. When we talk about cascading OKRs, that's the image we're borrowing: the company sets its objectives, each division takes its share, each team takes a share of that, and by the time the goal reaches the people doing the work it has become a slice of somebody else's number. It feels tidy and accountable, which is probably why the word stuck, but it treats every goal below as arithmetic performed on the goal above.
And if the image of water tumbling from one level to the next, each pool waiting on the one above it before anything can happen, sounds familiar, it should. Our industry spent the better part of two decades convincing organizations to stop running their work as a waterfall, and then a lot of those same organizations adopted OKRs and promptly drew them as one. Cascading OKRs is quite literally waterfall with a quarterly cadence, and I hope that image sticks with you the next time someone asks for the cascade slide.
Goals change character as they move down
If you look at how OKRs read at different levels of a healthy organization, they change in character as well as in size. A company's strategic OKRs are almost abstract, and they should be, because they have to hold true for every part of the business at once. A division's goals are narrower and describe how that division intends to contribute.
By the time you reach a team of teams, the handful of teams that co-own a product or product area, the useful question shifts from “what's our portion of the number?” toward something like “given the work we actually do, what's the most meaningful way we could move this?” That's an act of interpretation, and the teams closest to the work are the ones best placed to make it.
Even John Doerr, whose Measure What Matters did more than any other book to popularize OKRs, favors alignment over a strict top-down cascade in which each level simply hands down the work it implies. In my opinion the better framing is that the goals above should inspire and influence the ones below, without dictating them.
So what does marketing do with a product goal?
Say the division's focus this quarter is repeat purchases from known customers. For the software teams that's easy to imagine: a faster reorder flow, saved carts, recommendations based on what someone bought last time. You can almost watch the backlog write itself, and in that corner of the organization a cascade might even look like it works.
But what does the marketing team do with that goal? They don't ship reorder buttons. If you cascade the division's key result straight down to them, they inherit a number they can't directly move, and the most likely response is a campaign built around a discount code, because that's the shortest line from their work to somebody's second purchase. It probably hits the number this quarter, and it also teaches customers to wait for the next coupon.
If the marketing team interprets the goal instead, they might decide their real contribution is how people feel about coming back. Their objective could be something like make coming back feel like returning to something customers love, with key results written the way Jeff Gothelf and Josh Seiden suggest in Who Does What By How Much?, as changes in customer behavior:
Fewer coupon-driven returns. The share of second purchases made without a promo code rises from a baseline toward a target.
More attention on the right content. More returning customers engage with post-purchase content, such as how-tos and customer stories, than with promotional email.
A better reason to come back. More returning customers name the product experience, rather than price, as their reason for buying again.
The campaign work that follows is inspired by the division's goal and clearly aligned with it, and I'd argue nobody two levels up could have written it for them. The difficulty of finding the marketing example is the argument against cascading, because if the line from the division goal to the marketing team's work were obvious, you wouldn't need the team's judgment at all.
Why the wiggle room matters
When I describe team OKRs as inspired by and aligned with the goals above them, rather than cascaded from them, I'm deliberately choosing looser language, and I think that looseness is exactly what OKRs need. It leaves a team room to make the goal its own, to get creative about which problems to solve, and to run experiments inside that space with the outcome in mind.
It also changes who cares. A team that shaped its own OKRs has a stake in whether they move, and it has something solid to point to when it needs to say no, or not yet, to work that falls outside them. A team that received its OKRs on a slide mostly has a reporting obligation.
And interpretation is where most of the learning happens. When the marketing team's bet about how customers feel turns out to be wrong, that's useful information about the division's goal itself, the kind of thing a cascade has no channel for, because in a cascade information only flows one direction.
Keeping interpretation honest
The fair objection is that wiggle room can turn into drift. Given enough freedom, a team can relabel whatever it was already planning to do and call that alignment, and from the outside it's hard to tell the difference. So interpretation needs a little structure around it, and in my experience it doesn't take much.
The teams that share a product should write their OKRs together, with each team knowing which key results its own work contributes to, so nobody is guessing at its part alone. They should check their drafts with the people who wrote the goals above them, expect a round or two of iteration, and start a week or two before the quarter ends, because the process takes longer than anyone expects. Hoshin kanri has a nice name for this back-and-forth, catchball: leadership tosses down an outcome, the teams toss back their interpretation, and they keep throwing until both sides agree on what the team will own.
A simple test helps too. Can the team explain, in a single sentence, how its key result moves the one above it, and would the person who owns that goal agree with the explanation? If both answers are yes, the team has interpreted the goal. If the team can't answer, it has probably drifted, and if the owner can't follow the reasoning, the conversation isn't finished.
How to tell which one you're doing
Most organizations wouldn't describe their own process as a cascade, so it's worth looking at the symptoms instead of the vocabulary. You're probably cascading if any of these sound familiar:
The slide deck. Your team's OKRs arrive in a deck rather than coming out of a conversation you were part of.
The long division. Each team's key result is a fraction of the parent's number, split along the org chart.
The task list. Your key results read like a to-do list (“launch a loyalty program”) instead of describing a change in what customers do.
The shrug. At the end of the quarter, nobody can say how the team's work moved the goals above it, only that the tasks got done.
The phase gate. Someone in planning says “we can't start on ours until the division finishes theirs,” and nobody in the room hears the waterfall.
OKRs live in the strategy and outcomes part of the Adaptive Organization Operating Model, one of its five parts, yet the cascade habit grows out of leadership and culture, from leaders who learned somewhere along the way that alignment means control. It leaks into team design too, whenever the org chart decides how a number gets divided. The fix is a small change in leader behavior: asking a team what the goal means to them before telling them what their share of it is.
So, does anyone actually use OKRs properly? Some teams do, and in my experience the ones who get the most from them stopped expecting the goals to flow downhill. Next quarter, before your division's OKRs land, try getting the neighboring teams on your product in a room and asking what the goal would mean if it were yours to interpret, then take that answer back up the line and see what comes back.
Strategy and outcomes is where Assembled. Aligned. Adaptive. begins, and the books behind this post, including Doerr's and Gothelf and Seiden's, are on the reading list you'll find here.