A Strategic Initiative Should Be the Work — Not a Card That Links to It

Somewhere in nearly every strategy vendor's pitch is a number: the percentage of an organization's work that is "connected" or "linked" to its strategic priorities. The category's own research concedes the figure is dismal — that only a small minority of what an enterprise actually does can be traced to a stated priority inside a live system. It is presented as the problem the product exists to solve.

Look one level down and it is something else entirely: a confession about the product's own data model. You only measure the connectivity between two things when they are, in fact, two things. Nobody reports the percentage of a running process that is connected to itself. The metric can exist at all only because, in these tools, the initiative and its execution were separate objects from the first day — and stitching them together is a task that is never finished. The number stays low not because teams are lazy about linking, but because the architecture guarantees a gap that human effort is asked, in perpetuity, to close.

This is not a cheap shot, and the tools are not naïve. The strategy-execution platforms do genuinely useful things. An alignment tree that maps objectives to teams really does create shared context and a common vocabulary for a conversation that used to happen in fragmented decks. An operating cadence — the check-in rhythm, the review ritual — really does improve execution discipline; teams that inspect their commitments weekly behave differently from teams that do not. And an AI that drafts a first-pass set of objectives, or assembles the pre-read for a quarterly review, really does save hours of coordination toil. None of that is fake value.

But whatever the interface shows, the initiative object stores references — pointers — to work items that live in other systems: backlogs, ticket queues, planning tools, the ERP, documents. The status you read against it is either self-reported (a check-in, a RAG color, a confidence score someone sets) or polled from those systems through integrations. Real-time metric integrations are a real improvement over manual entry: they cut the staleness of the number. What they do not change is what the initiative fundamentally is — a card that references work happening somewhere it cannot reach, route, or govern.

The sharpest version of the category's answer comes from the enterprise-agile and strategic-portfolio vendors: stop treating linkage as a spreadsheet of hyperlinks and model the whole enterprise as a typed graph or ontology, so that work items are "linked" to objectives in a live system rather than a static slide. Give it credit — a maintained graph is genuinely better than a pile of pasted URLs. It is queryable. It can surface orphaned work, show coverage gaps, and let a leader ask which objective a given team's effort actually rolls up to.

But examine what a link is in that model, and the decay is structural, not a maturity problem you can train your way out of. A link is an edge between two independently owned nodes: an initiative node, maintained by strategy or the PMO, and a work node, maintained by a delivery team inside its own tool on its own schedule. That edge is derived, not intrinsic — it is asserted by a human mapping, a naming convention, or a heuristic that guesses the match. Every one of those is a standing maintenance liability. A reorg re-parents the nodes. A tool migration re-keys the work items. A backlog refactor splits one epic into five. A team renames its board. The nodes move, and the edges silently snap.

That is why "% connected" stays low no matter how elegant the linking experience becomes: you are not filling a bucket once, you are bailing a boat. And here the honest distinction matters — real-time integrations keep the status fresh; they do nothing to keep the linkage true. A live metric flowing across an edge that no longer reflects how the work is organized is a precise reading of the wrong thing. Freshness of the number and truth of the connection are different guarantees, and only the first one is on sale.

Consider a market-expansion objective whose key result is on-time site activations. In a reference model, "site activation" is a work-item type in a delivery tool, joined by an edge to the initiative. Re-shape the field organization, migrate activations to a new system, or split "activation" into permitting, build, and inspection — and the edge is now stale. The initiative still displays a confident status, but it is a status about a mapping that quietly stopped being true.

Entroid starts from a different object model, and that difference is the entire argument. A strategic initiative here — expressed through the Strategy and Business Portfolios modules — is not a record that points at the work. It is instantiated as a composition of the same five primitives that execute it: Deterministic Workflows that route and sequence it, Intelligence Orchestration that applies runtime judgment to choose the path, Atomic Agents (human or AI, governed inline) that perform the leaf work, Functions that calculate and query, and Connectors that read and write the existing estate under authentication, authorization, and audit — all defined on one Semantic Ontology, in one runtime.

The initiative is the executable composition. That is a claim about identity, not integration. A card references the work; a composition is the work. And when the initiative and its execution are one object, there is no edge to maintain, because there are not two nodes to connect. The linkage layer does not get better — it ceases to have anything to describe.

Follow the same illustration through. On-time site activations as a key result is no longer a check-in someone updates or a metric polled from a separate system. It is a Function — a query over the live state of the very Deterministic Workflows and Atomic Agents that perform each activation. Progress is not reported against the initiative; it is emitted by the initiative as it runs. The status is a byproduct of the work, computed from the work, inseparable from the work. State these as what they are: architectural properties of a single object model, not measured results from any particular deployment.

Here is the payoff that should interest an architect more than any feature. "Percentage of work connected to priorities" does not get optimized in this model — it becomes undefined, in the good way. You cannot compute the connectivity between an initiative and its execution when they are the same object; there is no ratio because there is no gap to measure. The linkage-decay problem is not solved so much as removed from the catalog of possible problems:

• A reorg does not snap an edge. There is no pointer to re-parent — the same primitives re-compose, and the initiative continues to be the thing that executes.
• A tool migration is a Connector change, not a broken mapping. Swapping where an external system lives is a governed edit at the one primitive that touches the estate — it does not sever a claim about which tickets belong to which objective, because no such claim was ever the source of truth.
• The cascade is an enforced dependency, not a diagram to re-key. A re-plan at the strategy tier propagates into the operating plans and the running workflows and agents beneath it, because they are composed on the same fabric — not reconciled by a human who remembers to update a second artifact.

None of this is a claim that Entroid needs no integration, and any vendor who tells you their strategy layer requires zero connection to your estate is selling you a fourth silo. Your systems of record are real and they stay. Connectors are the one primitive that reaches them, governed bidirectionally, with authorization and audit on every read and write. What disappears is not integration — it is the standing linkage layer and the reconciliation work it demands. You still connect to the ERP; you simply stop maintaining a separate graph of assertions about which work belongs to which objective, then measuring how much of that graph is still true.

Cadence and narrative do not vanish either. Reviews still happen; oversight still matters — the Committees module exists precisely to govern who may act and to hold initiatives to account. The difference is that a review reads execution instead of reconciling two copies of it. The rhythm that the strategy-execution category rightly values is preserved; what is removed is the manual, lossy, never-finished act of keeping intent and doing pointed at each other.

Strip away the roadmap gloss and put three structural questions to any tool that promises to connect strategy to work:

• Is the initiative a record that references the work, or the executable definition of the work? If it references, "% connected" is a permanent line item on your roadmap and your operating budget — you have bought the treadmill, not the destination.
• When a team reorganizes or a system is replaced, does a mapping break — or does the same composition simply run over a re-pointed connector? The first is decay you will fund forever; the second is a change with no reconciliation tail.
• Where does progress come from? If it is entered or polled, it is a claim about the work. If it is queried from the running instances, it is the work reporting itself.

The connectivity metric was never a measure of your discipline. It was a measure of the distance the tool's own architecture put between your strategy and your operations — a distance you were then billed to keep closing.