‍ ‍

The Missing Cement. What Connects Strategy to Outcomes?

There is a deceptively simple question at the centre of every transformation program. Why should the things we are designing cause the outcomes we expect? It sounds almost too obvious to ask.

Organisations have strategies. They establish objectives. Increasingly, they express those objectives through OKRs. Transformation teams gather requirements. Product teams develop user stories. Architects produce designs. Applications are configured. Processes are tested. Systems go live.

Every artefact can be present. Every governance gate can be passed. Every requirement can be traced. And yet something fundamental can still be missing. The program may have connected everything without ever establishing how the proposed changes are expected to cause the intended outcomes. That is the missing cement.

 Mackie and the problem of causation.

In 1974, philosopher J. L. Mackie published The Cement of the Universe- A Study of Causation. The title itself borrowed an older philosophical metaphor for causation as the force that makes events connected. Mackie was not writing about ERP transformation, strategy execution or enterprise architecture. He was investigating a much deeper question. What exactly are we claiming when we say that one thing caused another?

One of Mackie’s most useful insights was that effects rarely have the simple causal structure implied by statements such as “X caused Y”. What we casually identify as the cause is often only one part of a larger combination of conditions. Something can matter enormously without being capable of producing an outcome by itself. And the same outcome may be achievable through more than one combination of conditions.

That observation translates remarkably well into enterprise transformation. An ERP system does not cause improved working capital. Real-time inventory visibility does not cause improved service. Finite scheduling does not cause improved on-time delivery. Workflow automation does not cause shorter lead times. AI does not cause productivity.

Each may contribute. Each may even be indispensable within a particular operating design. But none should casually be confused with the outcome itself. The more interesting question is, what combination of operating conditions makes the outcome possible? This is where Mackie’s metaphor becomes uncomfortable for contemporary transformation practice.

We have become exceptionally good at defining the components of transformation. What is less visible is the causal cement that binds them together. Strategy does not cause outcomes.

Consider a familiar progression. An organisation establishes a strategy. The strategy is translated into objectives. Objectives are expressed through OKRs or performance targets. Transformation teams identify requirements. Requirements become capabilities, processes, applications and configurations. The solution is implemented. Performance is measured. The sequence is familiar enough that we rarely question its underlying logic.

But something important has happened. The organisation has moved from saying  this is what we intend to achieve to this is what we intend to build, without necessarily establishing why the second should cause the first.

Take a strategic objective such as reduce working capital while maintaining customer service. A subsequent requirement might state that the system shall provide real-time inventory visibility across all locations. Both statements may be perfectly reasonable. But the second does not explain how the first will occur.

Why should greater visibility reduce inventory? Who will act differently because the information exists? What decision will change? When must that decision occur? Against what threshold? What authority does the decision-maker possess? What prevents conflicting priorities elsewhere in the organisation from overwhelming the decision? What feedback establishes whether the intervention worked? What other conditions have to exist before visibility makes any material difference?

These are not questions about requirement quality. They are questions about causal design. Making the requirement more precise does not answer them. And this distinction matters because increasingly precise specifications can create the impression of increasingly precise reasoning. They are not the same thing.

The current state has an advantage the future state does not

There is another difficulty hiding inside transformation discovery. The current state exists. It can be observed. People can describe what they do. Transactions can be examined. Queues, delays, inventory, rework and exceptions can be measured. Decision rules can be investigated. We can examine what happens when demand changes, supply fails, work arrives early, information is late or a customer changes priority. Our observations may be incomplete. Our explanations may be wrong. But there is at least an existing world against which our claims can be challenged.

Then the transformation moves to the future state. And suddenly the object under discussion no longer exists. There are no future transactions to inspect. There are no future behaviours to observe. There are no future operating decisions to measure. There is no future organisation from which requirements can be extracted.

This creates a profound but rarely acknowledged change in the nature of the problem. The future state cannot be discovered in the same way as the current state because the future state does not yet exist. It must be reasoned about. It must be designed. It must be proposed. And eventually it must be tested. Yet remarkably little changes in the method.

The workshop continues. The process maps continue. Requirements continue to be recorded. User stories continue to be written. And gradually the future acquires the status of fact. “The planner will…” “The process will…” “The system shall…” “The user needs…” “The future state is…” But these statements are not observations. They are propositions.

At best, they are hypotheses about how a future operating system might behave. That difference is far more consequential than it first appears.

The missing change in the mode of thinking

At some point in transformation design, the question must change. We move from what happens to what would have to happen for a materially different outcome to occur? That is not merely another discovery question. It represents a change in the mode of reasoning. The first question is primarily observational. The second is hypothetical and causal. It requires us to reason about a world that does not yet exist.

What would happen if this constraint were removed? If this decision were made earlier, what downstream behaviour should change? If work were prevented from entering the system until specified readiness conditions were satisfied, would WIP and disruption fall? If a proposed operating condition existed but the expected outcome still did not occur, what other conditions would be missing? If that condition were absent, could the desired outcome still be achieved? Could another combination of conditions produce the same result?

These questions are much closer to Mackie’s conception of causation than a conventional requirements list. They force us to think in terms of combinations of conditions rather than isolated solutions. They also make uncertainty explicit. That is not a weakness in the design. It is intellectual discipline. Because the future state is necessarily uncertain.

The feature trap

Technology makes this transition particularly difficult. Once an application enters the conversation, it supplies an extraordinarily powerful vocabulary for imagining the future. The capabilities are useful precisely because they make a future state feel concrete. But that “concreteness” can prematurely close the inquiry. The question, what operating behaviour must exist for the objective to be achieved quietly becomes what can the application do? The technology then begins to supply the conceptual model of the future organisation.

A future-state design can consequently become little more than the existing operating system translated into the feature and function vocabulary of a new application. Many of the underlying assumptions that generated existing performance survive. The organisation has modernised the mechanism through which work is performed without necessarily redesigning the causal system through which value is created. Old assumptions, new technology. Old wine in a new bottle. This is not an argument against requirements, technology or user stories. It is an argument about when they enter the reasoning process.

They become dangerous when they begin supplying the answer before the causal problem has been understood.

A user story can conceal an entire theory

Consider the seemingly harmless user story. As a planner, I want visibility of inventory across all locations so that I can make better replenishment decisions. It is concise. It is understandable. It is also full of causal assumptions. “As a planner” assumes that the future decision belongs to that role. “I want visibility” has already selected an intervention. “Across all locations” assumes the relevant system boundary.

“So that I can make better replenishment decisions” asserts a relationship between information availability and decision quality. And the word “better” assumes that the decision criterion has already been established. An entire theory of how performance will improve has been compressed into a sentence and labelled a story.

The problem is not the story itself. The problem is what may never have happened before the story was written. The story may eventually be an excellent implementation artefact. But it is not a substitute for the causal reasoning that should precede it.

Objectives do not supply the cement either

Outcome-oriented methods, including OKRs, have attempted to shift attention away from activity and towards results. But an objective is still not a causal model. Improve order fulfilment reliability to 98 per cent tells us what success should look like. It does not tell us what operating conditions must change to make 98 per cent performance possible. A measure can establish ambition. It can expose divergence. It can create accountability. But it cannot explain the operating mechanism through which the target will be achieved.

Something must occupy the space between what the organisation intends to accomplish and the operating behaviour capable of producing it. Not another strategy document. Not another requirements catalogue. Not another technology architecture. What is missing is an explicit causal proposition about the future operating system.

The missing design layer

This changes the familiar idea of a “gap between strategy and execution”. Perhaps strategy and execution are not merely insufficiently aligned but missing the causal design layer between strategic intent and outcomes ?

Strategy establishes intent. Objectives make the intended changes more explicit. High-value value chains identify where those changes must materialise in operating performance. But once a value chain is placed in focus, an entirely different inquiry is required. What combination of operating conditions, behaviours, decisions, controls, feedback and measures would have to exist for this value chain to produce the intended outcome?

Now we are designing. Importantly, we are not claiming to have discovered the future state. We are constructing a future-state hypothesis. Given these operating conditions, we hypothesise that these controls, decisions and behaviours will produce these intermediate effects, which should contribute to the intended objective under these assumptions. That proposition can then be operationalised through processes, roles and technology.

But more importantly, it can be tested. From design certainty to design falsifiability. This changes the relationship between design and execution. Execution is no longer simply where a predefined future state is implemented. Execution is where the proposed causal design encounters reality.

If we believe shorter decision latency will improve fulfilment reliability, operating evidence should expose whether it does. If we believe a readiness control will reduce disruptive rescheduling, the future operating system should be capable of revealing whether that relationship occurs. If we believe controlled release will reduce WIP and cycle time, those predicted consequences should become observable.

Measurement therefore ceases to be merely a reporting mechanism attached after implementation. It becomes part of the design itself. Sensors test whether important assumptions and conditions remain valid. Signals reveal when intervention is required. Metrics diagnose whether the operating mechanism is behaving as expected. KPIs show whether the intended business outcome is emerging.

The organisation is no longer simply asking, did we implement the solution? It is asking was our theory of how the outcome would be produced correct? That is a very different conception of transformation. It turns execution into a source of evidence and makes adaptation a legitimate consequence of learning rather than evidence that the original design failed.

Mackie did not write an enterprise transformation methodology

The analogy should not be overstated. Mackie was engaged in philosophy. His analysis of causation was not intended as a method for ERP design, enterprise architecture or strategy execution. But that is precisely what makes Mackie useful. He makes us less comfortable with casual assertions of causation.

Transformation practice is full of them. Implement ERP and standardisation will follow. Introduce AI and productivity will improve. Increase visibility and decisions will improve. Automate planning and inventory will fall. Introduce workflow and execution will accelerate.

Maybe? But Mackie encourages a different set of questions. Under what other conditions? Necessary in what circumstances? Sufficient as part of what combination? What else could produce the same outcome? What would we expect to happen if the condition were absent? Those questions expose the reasoning hidden between intervention and outcome. And that reasoning is exactly what a causal design must make visible.

The question transformation leaders should ask

Perhaps every executive sponsoring a significant transformation should ask at what point did our program stop describing the organisation that exists and begin designing an organisation that does not yet exist? Then ask something more uncomfortable. What changed in our method when we crossed that boundary? If the answer is nothing, there may be a problem.

The same workshops continued. The same process models were elaborated. The same requirements templates were populated. The technology entered the discussion. The future became progressively more detailed. But the mode of thinking never changed.

Observation quietly became specification without passing through disciplined causal inquiry. That is the missing layer we have spent years describing simply as the gap between strategy and execution. The gap may actually sit between strategy and outcomes. And it is not merely a missing artefact. It is not another governance gate. It is not another architecture document.  It is the point at which an organisation consciously acknowledges that we have reached the limit of what can be observed.

We are now reasoning about a world that does not yet exist. From that point, the mode of thinking must change. Observation becomes inquiry. Inquiry develops causal hypotheses. Those hypotheses become an operating design. Technology enables that design. Execution exposes the design to evidence. And the organisation adapts as reality confirms, contradicts or modifies its causal assumptions.

Only then is strategic intent connected to outcomes through something stronger than objectives, requirements and implementation plans. It is connected through an explicit account of why the changes being made should cause the outcomes being sought.

Mackie spent The Cement of the Universe examining the difficult question of what allows us to claim that one thing causes another. Transformation has its own version of that problem. It already has strategy. It already has objectives. It already has requirements. It already has applications. It already has execution.

What is missing is the causal reasoning that binds them to the outcome. The pieces are there. The cement is missing.