(2025-12-07) Cutler Tbm393 Why Labeling Relationships Is So Important

John Cutler: TBM 393: Why Labeling Relationships Is So Important. At work, I end up mapping out a lot of company operating systems. And it wasn’t until yesterday that something finally clicked

The basic idea is this. So much becomes clear when you actually label the relationships between things. It’s something I do every day, and I do it very naturally. But it is not something everyone does naturally.
The goal of this post is to persuade you to map out how you operate as a concept map, semantic network, or lightweight ontology where the edges carry meaning.

We fall back on a small set of options (e.g., hierarchies and containment models) when company operating systems are much more diverse. This drift is fine when you’re on a small team. But it can have disastrous effects when scaled across a company.

Goals & Initiatives (4 Variations)

I’ve encountered at least four very different mental models of the relationship between goals and initiatives

How do they differ?

Model A treats goals as the strategic anchor and initiatives as bets aimed at influencing them. Model B flips this, with initiatives chosen first and goals later derived to justify and frame their success.

each model assumes a completely different type of relationship, and small shifts in that relationship change how strategy and execution actually work.

“Strategy to Execution”

one model call out capabilities and features, while the other uses the term “bets,” applies that concept fractally, and explicitly includes data, insights, and beliefs

What assumptions are these models making? What is the primary role of frontline teams in each case? And which model is more accommodating of cross-team and cross-group dependencies?

the biggest differences aren’t the shapes of the diagrams but the assumptions they encode about how organizations work. It’s the objects AND the relationships: the nouns AND the verbs.

The first model assumes a world in which strategy can be decomposed into stable layers, causality is mostly linear, and frontline teams primarily implement well-defined intent. The second assumes a world of constant uncertainty, where strategy emerges from learning loops, bets express hypotheses rather than commitments, and teams interpret, localize, and contribute to the strategy rather than just execute it

The first model calls out capabilities and features because it sees progress as breaking work into modular parts; the second highlights beliefs, insights, and bets because it sees progress as iterating toward understanding (sense-making). My hunch is that the predictable one is better at dealing with large, cross-cutting projects, at the expense of creativity. But the bet-based one is better at avoiding those altogether.

the difference is not just “layers.” It is whether you believe progress comes from breaking work down or from iterating, localizing, and refining bets.

More Objects And Relationships

I spent ten minutes sketching a rough ontology of Amazon’s operating system. Don’t worry about completeness — it’s nowhere near complete. What I want you to pay attention to is the texture of the relationships

In most companies, the structure is basically “projects → deliverables → stories.” In this sketch, the power comes from the variety of relationships, how decisions flow, how signals travel, and how teams learn. It is a network. Notice how many of the edges describe mechanisms, not containers: diagnosing, escalating, grounding, influencing, revealing, setting expectations, generating insights. No relationship-label is used more than once! Definitely not aiming for semantic relations here.

And the objects themselves are not just convenient layers in a single hierarchy. They are a mix of rituals, artifacts, practices, concepts, formal mechanisms, and actual people

We can group them into my four-graph framework: (TBM 361: Context, Collaboration, Intent, and Investment)

Key thing to notice: this is not a hierarchy but a mechanism-rich network. The edges carry meaning, feedback, and intent that no simple “project → deliverable → story” tree can represent.

“Scaling Agile”

Way back in the aughts of 2008 to 2010, people started pondering what it might mean to “scale Agile.” There were decent ideas at the time about how a team might work in more agile ways. But at the “business level,” it was all programs and projects, budget codes, portfolio governance, and capitalization

Smart people looked at the problem and tried something very logical (and not at all unreasonable).

There has been much digital ink spilled around SAFe, but I want you to put yourself in a time machine and go back and be very honest with yourself. Do any of these ideas sound weird in context?

The conclusions were pragmatic and followed a simple heuristic: if something works locally, does it make sense to try it at the next higher level, or the level above that?
Here’s that logic in action:
If a story has tasks, and an epic has stories, then maybe a feature could have epics, and a program could have features. And if a program has features, perhaps a portfolio could have programs!

The problem is that the logic runs into some harsh realities of scale dynamics. Some things are relatively “scale-free”. Other things aren’t.

A burndown of stories might make sense for an epic, but that doesn’t mean a burndown of epics makes sense for reducing risk or looking to impact a set of input metrics

An informal dependency chat inside a team is very different from a large-scale dependency conversation. At the team scale, people share context and can make quick agreements. At a large scale, with many teams and shifting priorities, the prep work alone can consume enormous amounts of time

Team-based OKRs work well because they stay close to the work. Team-agnostic OKRs can also help align frontline teams. But once you build a large cascade, you have a big context telephone game.

This is not a new observation. Christina Wodtke has an excellent piece on why cascading OKRs often fail to do what people expect. In “Cascading OKRs at Scale,” she points out that the structure looks tidy in a slide deck but “does not scale at all” once it passes through several layers of an organization.

Surface patterns may look fractal, but the underlying dynamics shift dramatically as you add distance, politics, and interpretation.

If you want to explore this further, Scale by Geoffrey West is a great place to start. West shows that some things scale sublinearly and become more efficient as they grow, while others scale superlinearly and become more costly, fragile, or political. Knowing which dynamics you are dealing with is critical. Another useful treatment is Bent Flyvbjerg’s discussion of modularity in How Big Things Get Done. His core point is that modularity is powerful, but only when the units are genuinely modular, which is not the case for many of the assumptions described above.

Closing The Loop

The purpose of this piece was to challenge you to look at how things are related, not just where they sit in a hierarchy. To step beyond basic trees and start sketching simple ontologies, concept maps, relationship graphs, and semantic models (pick your term) to explore how your company operates.

It is tempting to say that none of this really matters

But I’d like you to turn your attention to the following. Consider how many companies:

• Only formally acknowledge two types of work: 1) work that originates with a business case, far up in the org, or 2) business as usual (BAU) work.
• Use terms like “initiative” to mean very different things, with very different relationships to outcomes, goals, insights, etc.
• Try to describe the whole operating system on neat, tidy slides, with stages, gates, and phases, and some loops thrown in for good measure.
• Insist that the clean hierarchy of X is actually how things work, and then expect a clean roll-up.

And don’t get me started on tools. How many tools assume that the sole task is a containment-type roll-up, with work happening at the bottom and roll-ups happening cleanly, level by level?

With Dotwork, we see a striking pattern. When people model their operating system with open-ended entities and relationship labels, they create, on average, 15 to 25 entity types, which naturally spread across our four graph framework: Intent, Collaboration, Context, and Investment. Only about 30 percent of the relationships they create are simple “part of” links.

Here’s a guide to common relationship types: