Getting the Words Right

Summary: In complex systems, containers help organize intent, but anchors stay closer to reality and carry more reliable status. Not all endurants are created equal. Some endurants act as containers, while others act as anchors. The distinction matters more as systems become complex. Containers A container is something we use to group and organize work. Common examples are initiative, project, epic, andprogram. Containers are defined by inclusion. The implicit question is, “What’s inside this?” They are useful because they create boundaries, help coordinate effort, and give a name to a bundle of intent. In stable environments, containers can work well. Scope is relatively fixed, relationships are predictable, and the contents map reasonably well to reality. In more complex environments, that starts to break down. Scope shifts, work moves in and out, dependencies cross boundaries, and meaning evolves over time. The container becomes a lagging, lossy summary of what is actually happening. You can still assign a status to a container, but the status carries less and less context as the system becomes more fluid. Anchors An anchor is something that connects more directly to reality. Common examples are ateam, aproduction change, ametric, or asystemor

service. Anchors are not defined by what they contain. They are defined by what they are and what happens to them over time. You do not usually ask, “What’s inside this?” Instead, you ask:

• what changed?

• what happened?

• what is the current state?

•how has it evolved over time? Anchors persist through time, accumulate context, and remain meaningful even as work shifts around them. They become stable reference points in a changing system. Across Traditions This distinction overlaps with several adjacent traditions, even if they use different language. Tradition Container-like ideaAnchor-like idea Typical failure mode Information architecture category, folder, navigation bucket person, product, account, service the navigation structure gets mistaken for the underlying reality Taxonomyclassification bucket, class, grouping label the entity being classified the classification scheme starts to stand in for the thing itself Knowledge graphs collection node, grouping construct, context wrapper durable entity node grouping constructs get treated as if they had the same status as the underlying entities

Tradition Container-like ideaAnchor-like idea Typical failure mode Portfolio management initiative, program, epic, project team, service, metric, production change status gets attached to the wrapper instead of the more stable realities underneath Systems thinking abstraction layer, organizing frame stable point of observation the simplifying frame hides the actual dynamics of the system Records or archives collection, series, folder record, item, artifact the finding structure is treated as if it were the primary object of concern Across all of these, the pattern is similar: containers help organize meaning, while anchors help keep us attached to reality. Why It Matters In simple systems, containers and anchors often align. A project maps cleanly to a set of activities, and a status on the container reflects something real about the underlying work. In complex systems, containers drift away from the underlying work while anchors remain tied to observable reality. That creates a gap. You might have:

•a green initiative •while key metrics are degrading •and recent production changes are causing issues The container says one thing. The anchors say another. Back to RAG This explains a common failure mode with RAG status.

When you attach RAG status to a container, the signal compresses multiple, shifting realities. Context is lost, and interpretation is required. When you attach signals to anchors, the signal is closer to reality. It connects more directly to action and carries more inherent meaning. This is why:

•RAG works better in manufacturing •struggles in knowledge work •becomes especially fragile at the executive summary level Because the further you move up, the more you rely on containers and the further you get from anchors. A Practical Contrast ExampleTypeWhy it matters TeamAnchorPersists, owns work, accumulates context Production changeAnchorDirectly observable, tied to customer experience MetricAnchorReflects system behavior over time InitiativeContainerOrganizes intent, but drifts as reality changes A Simple Test If you are not sure whether something is acting more like a container or an anchor, use this side-by-side test: CriterionAnchor Container Is it directly observable in operations or outcomes? YesNo

CriterionAnchor Container Can you ask “what changed?” and get a concrete answer? YesNo Does it accumulate context over time in a stable way? YesWeakly Does a status signal on it usually imply a clear action? OftenRarely Would it still make sense even if the current plan changed? More likelyLess likely Is it mainly defined by what it contains? NoYes Can work move in and out without changing the label much? NoYes Does its meaning drift as scope changes? Less soMore so If most of the answers line up with theAnchorcolumn, treat it primarily as an anchor. If they line up with theContainercolumn, treat it primarily as a container. Some things will sit in the middle. The point is not perfect classification. It is to surface whether you are trying to explain reality with something that mostly organizes intent. The Shift As systems become more autonomous and interconnected, work becomes more fluid, processes become non-linear, and relationships become manyto-many. Under those conditions, containers lose explanatory power and anchors become more important. This does not mean containers disappear, but it does change what they are good for. Containers still help with:

• planning

•coordination •communication But they are no longer sufficient as:

•primary units of understanding •reliable carriers of status •proxies for reality Rule of Thumb If you want to understand what is going on, look at anchors. If you want to organize effort, use containers. Confusing the two is where problems begin. The Deeper Point Most of the frustration you hear from leaders, “We don’t have the big picture” or “We’re surprised by what is happening,” does not come from a lack of data. It comes from relying on containers to explain a system that can only be understood through anchors and the perdurants connecting them. Try This Now:

•Write down one container your organization uses often: for example an initiative, project, program, or epic.

•Then write down two anchors underneath it that are closer to reality: for example a team, service, release, metric, customer segment, or production change.

•Ask: if the container says “green” but the anchors do not, which one would you trust first?