Cascade: choices, not goals

Strategic choices cascade logically: each level’s choices set the context inside which the level below makes its own. Goals should not cascade bureaucratically, with each level’s Key Results becoming the level below’s Objectives. The first creates alignment; the second creates a compliance exercise.

By Matt Roberts, co-founder, ZOKRI

The two things people mean by cascade

One is a logical relationship: the company has chosen where to play and how to win, so a function’s choices have to make sense inside that. Nobody sensibly objects to this.

The other is a mechanical procedure: my Key Result becomes your Objective, level after level, until the bottom of the org chart is writing goals derived from a number four levels up. This is the one that produces resentment and paperwork.

Most arguments about cascading are two people using the same word for these two different things.

Why the mechanical version fails

It is slow. Nothing at level four can be written until level three has finished, so a quarter is half gone before teams start.

It removes judgement. A team told to move a derived number will move that number, whether or not doing so serves the outcome it came from.

And it hides the strategy. By the fourth derivation nobody can see the original choice, so nobody can tell when their local optimisation is working against it.

What to do instead

Publish the choices, not the numbers. Make the strategy short enough that a team can recall it without looking, and require them to be able to explain how their goal serves it.

Then let each team write its own goals inside that context, and check alignment by asking for the argument rather than the arithmetic.