Cascading Goals

At ten people this happens by itself. Everyone sits in one room, everyone knows what matters this month, and when that changes the news reaches the whole company the same day.

Past forty people it stops working. The company splits into six teams, each with its own schedule, and at the end of the quarter a strange scene shows up: all six teams report hitting their goals while the company's numbers sit exactly where they were three months ago. Design shipped the redesign, engineering cut load time by 30 percent, marketing doubled visitors, and the number of teams that started paying didn't move. Everyone did good work. Nobody did it in the same direction.

The same problem shows from the other end. An engineer knows exactly what they're building this quarter but can't say how it reaches the company. Every time the order of work has to be decided — this ticket or that one — there's no basis for deciding, so the only available answer is whatever was assigned most recently. Cascading goals is the procedure built to handle both ends at once.

Settle the company goals first, have each team write its own share of them in its own words, and let individuals take their piece from the team goal.

1. Settle company goals before the quarter starts, and cut them down to two or three. Write eight and every team can find the one that suits what it was already planning, which leaves the appearance of alignment and none of the substance.
2. Each team writes its own share. If the company goal is paid conversion, engineering might take payment failure rate while design takes the share of new signups that create a first document. The reason teams write rather than receive is simple: people reread sentences they wrote, and don't reread sentences they were handed.
3. Reconcile where teams depend on each other. If marketing is committed to doubling visitors and design plans to ship the signup screen those visitors land on six weeks in, one of those dates has to move. Skip this check and mid-quarter one team sits idle waiting for another.
4. When individuals write their goals, require one line saying which team goal the work moves. "Clean up the payments module" leaves nobody able to check how something three levels down connects to conversion. "Clean up the payments module to cut payment failures" makes it visible what gets lost when that work slips.
5. Reread everything once mid-quarter. Company goals change, and when they do the levels below have to change with them. Without this step only the top changes and team goals stay frozen at whatever was written in week one.
6. At the end of the quarter, read top to bottom once. Where a team hit its goal and the company goal didn't move, the link between them was wrong to begin with, and the thing to fix next quarter is the link rather than the team.

It earns its cost when there are several teams with a lot of waiting on each other. The need starts around the point where everyone no longer fits in one meeting, and it usually runs alongside a format like OKR, which pairs one objective with two or three key results each quarter. In a ten-person company the same procedure only adds meetings.

The largest limitation appears when the top is wrong. Alignment transmits direction; it doesn't check it. Set the wrong company goal and forty people go the wrong way efficiently. An unaligned company at least has teams doing different things, one of which may happen to be right — that accident disappears once everything points the same way.

Distance from the original goal grows at every level down. If the company goal is paid conversion, engineering owns payment failure rate, and one engineer owns the payments module, the person three levels down may go a whole quarter without saying the word conversion. That's why many companies refuse to stack more than three levels.

Work that doesn't appear in any goal gets pushed aside. Incident response, cleaning up old code, answering support tickets — none of it attaches neatly to a company goal. Cascade too tightly and this work reads as work nobody is asking for, and two quarters later the backlog of it is what blocks the goals. Setting aside a fixed share of team time outside the goals is the usual defense.

Finally, attaching the whole thing to performance reviews changes what it is. Once the percentage of goals achieved feeds compensation, people write targets they are sure to clear, and the alignment meeting turns into a negotiation about lowering numbers rather than matching them.

"Write one line on where your team goal attaches to the company goal."

Put the connection in the document instead of explaining it out loud.

"The company goal changed, so let's revisit the team goals."

The top moved, and leaving the lower levels alone isn't an option.

"This doesn't attach to any goal, and we still have to do it."

Make room for the work that lives outside the cascade.

At Pagedeck's quarter kickoff, Grace reads out the two company goals, and then each team spends thirty minutes apart writing its own. When Mia brings the product team's draft back to compare, what usually gets caught is the level the sentence is written at. "Finish the onboarding redesign" is something the team did rather than something that happened, so that line typically becomes the share of new teams that create a document within seven days.

The most common reading is that this means slicing goals at the top and handing pieces down. The word cascade invites the image. But assigning from above turns a team goal into a fragment of the company goal, and what that team can actually do never makes it into the sentence. A company goal of conversion doesn't give engineering a goal of one third of conversion. Only when a team writes in its own words and then reconciles upward does the sentence get used during the quarter.

The other frequent belief is that all work should connect to a goal. Connection is the point of the exercise, so more connection looks better. In practice the forced connections break first. Attach support ticket volume to a company conversion goal and the team starts triaging by whether a question looks like it leads to revenue — or, more often, nobody looks at that link again all quarter. Work that doesn't connect is better left unconnected on the list, with time budgeted for it directly.