Introduction

Most executives I meet are not struggling because they lack ambition.

Quite the opposite.

They know where the business needs to go.

They want faster product development. Better lifecycle visibility. Improved profitability. Simpler operations. More predictable decisions. Greater responsiveness. Higher customer value.

In many cases, the desired future state is relatively clear.

The challenge is something else.

The challenge is deciding where to begin.

Because transformation rarely suffers from a shortage of opportunities. It suffers from a shortage of sequencing.

Every initiative appears important. Every department has legitimate needs. Every capability gap seems worth addressing.

And yet, despite all the planning, prioritization and governance, many organizations still find themselves asking the same question:

Why does transformation feel so difficult, even when we know what needs to improve?

I think the answer lies in one of the most overlooked realities of leadership.

Knowing the destination is not the same as understanding the sequence.

The Planning Illusion

Transformation discussions often begin with future-state thinking.

What should the organization look like? What systems should exist? What capabilities should exist? What processes should improve? What operating model do we want?

These are important questions.

But they can sometimes create a dangerous illusion.

The illusion that knowing the future automatically tells us how to get there.

In reality, many organizations can describe their destination far better than their journey.

The roadmap becomes a collection of desirable outcomes rather than a sequence of enabling decisions.

And when that happens, execution becomes surprisingly difficult.

Why Good Priorities Still Fail

One of the most frustrating experiences in transformation is discovering that a sensible priority produced disappointing results.

The initiative was important. The analysis was reasonable. The business case was valid.

Yet the outcome failed to create the expected momentum.

This often happens because priorities are not independent.

Capabilities depend on other capabilities. Information depends on governance. Decision quality depends on context. Lifecycle learning depends on information flows. Configuration management depends on product ownership.

The problem is not that the initiative was wrong.

The problem is that something else needed to happen first.

Transformation frequently fails because organizations attempt to build capabilities on foundations that are not yet ready.

The Building Blocks Problem

Imagine trying to improve product configuration.

The organization launches a major initiative. Processes are redesigned. Technology is upgraded. Training is delivered.

Yet results remain inconsistent.

Why?

Because configuration quality may depend on something deeper.

Perhaps product ownership remains unclear. Perhaps product definitions vary between functions. Perhaps governance is weak. Perhaps lifecycle accountability is fragmented.

The visible problem exists. But it rests on other capabilities.

Improving the visible capability without strengthening its dependencies often creates disappointment.

Not because the investment was wrong. Because the sequence was wrong.

The Difference Between Importance and Dependency

This is one of the most useful distinctions I have encountered.

A capability can be important without being foundational.

And a capability can be foundational without attracting much attention.

Leadership teams naturally focus on visible priorities. The capabilities causing daily frustration. The capabilities appearing in performance reports. The capabilities receiving executive attention.

Yet transformational leverage often exists elsewhere.

Not in the most visible capability. But in the capability that enables several others.

Understanding this difference changes prioritization dramatically.

Because transformation is not only about importance. It is also about dependency.

The Capability Stack

Over time, I have started visualizing organizations as capability stacks.

Some capabilities sit close to business outcomes. Others sit underneath and enable them.

Customer value may depend on:

  • Product quality
  • Product availability
  • Commercial effectiveness
  • Service effectiveness

Those capabilities may depend on:

  • Product knowledge
  • Lifecycle governance
  • Configuration management
  • Decision quality

Those capabilities may in turn depend on:

  • Information quality
  • Ownership models
  • Accountability structures
  • Learning mechanisms

This creates a hierarchy. Not of departments. But of dependencies.

And leadership decisions often become clearer when viewed through that lens.

The Pressure to Deliver Quickly

Unfortunately, transformation does not happen in an ideal environment.

Leadership teams face constant pressure. Budgets. Customers. Quarterly results. Competition. Stakeholder expectations.

This pressure naturally pushes organizations toward visible action.

Large programs. Major announcements. Technology investments. Platform deployments.

Immediate activity creates confidence. Dependency analysis does not.

The challenge is that transformation speed and transformation effectiveness are not always aligned.

Sometimes the fastest visible action delays meaningful progress. Because the organization accelerates in the wrong direction.

Why Technology Often Becomes the Starting Point

This helps explain a pattern we have discussed throughout this series.

Technology frequently becomes the starting point.

Not because leadership believes technology solves everything. But because technology appears actionable.

A project can be launched. A vendor can be selected. A roadmap can be approved. Progress becomes visible.

Capabilities behave differently. Capabilities often improve gradually. Their value emerges over time. Their dependencies are more difficult to see.

Technology feels concrete. Capability development feels uncertain.

As a result, many organizations begin with the most visible elements of transformation rather than the most enabling ones.

The Cost of Starting in the Wrong Place

The consequences are rarely immediate.

In fact, organizations may initially report success.

Projects progress. Budgets are consumed. Systems go live. Activities continue.

The problem appears later.

Expected business outcomes fail to materialize. Users remain frustrated. Workarounds survive. Complexity persists. Decision quality improves less than expected.

At this point, organizations often conclude that they need another initiative. Another technology upgrade. Another transformation phase.

What they frequently need instead is a better understanding of capability dependencies.

Because transformation is not simply about doing the right things. It is about doing them in the right order.

The Leadership Question Nobody Likes

One question often makes transformation discussions uncomfortable.

Not because it is difficult. Because it forces prioritization.

The question is:

What must become true before this initiative can succeed?

It sounds simple. Yet it changes the conversation completely.

Now we begin looking for dependencies, prerequisites, enabling capabilities and missing foundations.

Instead of evaluating initiatives individually, we start evaluating relationships between them.

And transformation is fundamentally a relationship problem. Not a project problem.

Why This Matters More Than Ever

The challenge is becoming increasingly important.

Industrial companies are dealing with:

  • Growing product complexity
  • Increasing software content
  • Faster business cycles
  • AI-enabled decision making
  • Continuous product evolution
  • Rising customer expectations

The number of possible investments continues growing. The ability to prioritize them becomes increasingly important.

Leaders can no longer afford to ask only, "What should we improve?"

They increasingly need to ask, "What must happen first?"

Because sequencing is becoming a competitive capability in its own right.

A Different Way to Think About Transformation

Perhaps transformation should be viewed less like project management and more like architecture.

Architects do not start with the roof. They start with load-bearing structures.

Not because the roof is unimportant. Because other elements depend on the structure beneath it.

The same principle applies to organizations.

Some capabilities support others. Some investments unlock others. Some decisions multiply future options.

The most successful leadership teams often understand this intuitively.

They focus less on individual initiatives and more on the sequence that allows initiatives to succeed.

Final Thoughts

One of the reasons transformation feels difficult is that organizations are rarely suffering from a shortage of good ideas.

The challenge is deciding which ideas should come first.

Every capability appears important. Every initiative has supporters. Every business case can be justified.

Leadership therefore faces a dilemma.

Not whether transformation should happen. But where transformation should begin.

And that decision is often less about importance than dependency.

Because the most valuable investment is not always the one closest to the desired outcome. It is often the one that makes several future outcomes possible.

Understanding that distinction changes how leaders think about prioritization. And ultimately, how organizations change.

Because transformation is not simply the act of moving forward. It is the act of moving forward in the right sequence.