Open any OKR tool on the market and the model is identical. Company goals sit at the top of the screen. Department goals are nested under them. Team goals nested under those. Individual goals at the bottom. A neat inverted tree, with confident hierarchical lines connecting each layer to the one above. It looks great in a deck. It does not survive ten minutes of contact with how value actually moves through a company past about a hundred people.
Why the tree breaks the moment work crosses functions
Value rarely flows down a single branch of the org chart. Take any strategic objective worth having — a new go-to-market motion, a platform consolidation, a category expansion — and write down which functions have to do specific things, in sequence, with dependencies between them, for the objective to move. The list is never one function. It's usually four or five: Product, Engineering, Marketing, Sales, Customer Success, sometimes Finance, sometimes Legal. None of those functions sits under any of the others. They sit beside each other on the org chart. The goal lives across the chart, not down it.
When you force this reality into a cascade, two ugly things happen, and both are visible in almost every OKR tool deployment I've seen.
The first is duplication. The originating function — say, the GTM team that "owns" the new motion — writes a parent goal. The other functions, asked to support it, copy the same goal into their own branch with slightly different wording. Now the same objective exists five times in the tool, with five sets of progress numbers, five owners, and no agreement on which one is the real one. Reporting becomes a reconciliation exercise.
The second is orphaning. The other functions, sensibly tired of being asked to copy goals they didn't author, simply don't. The parent goal sits in the GTM branch with no visible dependencies into the other branches. On paper, GTM owns it. In practice, GTM cannot move it without four other teams doing work that doesn't appear anywhere in the tool. The cascade now actively lies about who is responsible for what.
What a goal graph looks like
A goal graph treats objectives as nodes and dependencies as edges. A single objective can be parented by multiple strategic bets. A single bet can be supported by objectives across many teams. The shape is a directed acyclic graph, not a tree. It looks less tidy on a slide. It models reality.
The practical consequences are immediate and worth the visual untidiness.
A team can see which of their objectives are required by other teams' work, which changes how they prioritise. An objective that looks small in isolation but is blocking three other teams is treated differently than one with no downstream consumers. Leadership can ask, for any strategic bet, the only question that actually matters: what is the full cross-functional set of objectives required to move this, and who owns each of them. A goal that fails has traceable upstream consequences — you can see which bets it puts at risk and which other teams need to be told now rather than three months from now when the slippage finally surfaces.
None of this is possible in a cascade. The cascade can tell you what's under a goal. It cannot tell you what depends on it.
Why no tool ships the graph
Because graphs are harder to draw than trees, and tool vendors are in the business of selling something that looks coherent in a demo. The slide for a cascade is a tidy pyramid that fits on one screen. The slide for a graph looks like a subway map — defensible, useful, and visually intimidating to a buyer who wanted "OKRs made simple." So the vendors pick the prettier model and ship it, and the buyer, who has never operated against either, picks the prettier one too.
There's a secondary reason. The cascade lets every manager pretend their function is self-contained. The graph forces them to admit the opposite. That admission has political cost — it means acknowledging that your team cannot succeed without other teams' work, which is uncomfortable in performance reviews and budget conversations. The cascade is preferred partly because it lies in the direction that everyone wants it to lie.
What changes when you operate on a graph
Three things, all of them load-bearing. First, conversations about priorities stop being about "whose OKR is this" and start being about "which bets does this objective serve." That's a much harder question and a much more productive one. Second, the silent pivot becomes visible — when capacity drifts away from a bet, the missing edges in the graph make the drift obvious instead of letting it hide in a separate team's tidy branch. Third, planning becomes shorter, because the dependencies are explicit before the plan is published, not discovered in execution.
The cost is a small amount of additional rigour at planning time. The benefit is that the plan survives contact with the quarter.
The Vindaris view
Model what's real, not what's drawable. The graph is harder to render and easier to operate. The cascade is the opposite — easier to render, impossible to operate against. Pick the one that matches the work your company actually does, not the one that fits cleanly on a slide. The companies that compound on their strategy are the ones whose model of goals matches the shape of how value gets created, and that shape, in any company worth running, is a graph.