Organizations often describe major change by naming the framework, technology or theme associated with it.
“We are doing a SAFe transformation.”
“We are becoming agile.”
“We are doing an AI transformation.”
“We need a quality transformation.”
The language suggests that the organization is implementing something. A framework is introduced. New roles appear. New ceremonies are scheduled. Governance changes. Tools are deployed. Training begins.
But that raises a more basic question: what, exactly, is being transformed?
The Framework Is Not the Subject
Consider a SAFe transformation. The visible changes may include portfolio structures, planning events, Product Management, Product Ownership, architecture, release mechanisms, governance, team structures and new artifacts.
It is easy to describe progress in terms of those visible arrangements. Roles have been appointed. Events are happening. Backlogs exist. Governance forums have been established. Yet none of those things, by themselves, demonstrate that the organization has become better at what the transformation was supposed to improve.
The deeper change may concern the organization’s ability to manage portfolios, translate strategy into product direction, coordinate architecture, define requirements, engineer products, test them, release them, learn from operation and make decisions across organizational boundaries. Those are capabilities.
The framework provides one possible set of structures, roles and practices through which those capabilities may be realized. It is not itself the capability. That distinction matters because an organization can become increasingly faithful to a framework without becoming increasingly capable.
Transformation Changes Several Capabilities at Once
Large transformations rarely concern one organizational ability in isolation. An agile transformation may influence portfolio management, Product Management, planning, requirements, engineering, testing, release management, leadership and collaboration. An AI transformation may influence software engineering, customer service, analysis, decision-making, knowledge work, governance, security and Product Management. A quality transformation may affect product definition, architecture, engineering, assessment, testing, operations, governance and learning.
These capabilities may begin at different levels of strength, respond differently to intervention and evolve at different speeds. One may improve rapidly while another remains weak. That matters because the value created by one capability often depends on another.
A stronger testing capability cannot fully compensate for weak requirements if important expectations remain unclear. Better Product Management cannot create the intended effects if engineering cannot reliably realize product decisions. Strong architecture may have limited impact if portfolio decisions repeatedly undermine architectural direction.
Transformation is therefore not simply a collection of independent improvement initiatives. The capabilities form a system.
Uneven Capability Development
This may explain a familiar transformation experience. Some parts of the organization seem to change quickly. New planning practices are adopted. Teams learn new techniques. Tools are introduced. One discipline develops strong leadership and a clear operating model.
Elsewhere, progress is much slower. A neighboring capability remains weak and gradually becomes a constraint on the rest of the transformation. The program may still report progress because many planned interventions have been completed, while the organization continues to struggle with the effects the transformation was meant to create.
This exposes an important difference between implementing change and developing capability. An intervention can be completed. A capability must actually become stronger. And because capabilities depend on one another, the slowest or weakest capability may limit the value produced by improvements elsewhere.
Transformation is therefore not only a sequencing problem. It is also a dependency problem.
From Framework Adoption to Capability Evolution
Seen this way, the transformation question changes. Instead of asking primarily whether the framework has been implemented, we can ask which organizational capabilities we are trying to strengthen.
That immediately leads to more useful questions. What should those capabilities enable? Why do they matter to the organization’s strategic objectives? Which capabilities depend on one another? Where are the current constraints? Which interventions are intended to strengthen which capability? What evidence would show that the capability has actually improved?
The framework may still be useful. It may provide proven structures, terminology, roles and practices that make development easier. But its value becomes instrumental.
It is one possible means of developing the capabilities the organization actually needs.
The Portfolio Becomes the Subject
Once several capabilities are being changed together, another subject appears. The transformation is no longer concerned only with individual capabilities. It is concerned with their composition and relationships.
The organization may strengthen several capabilities while leaving one strategically important gap untouched. Two capabilities may duplicate responsibility. One may have expanded because another remained weak. A capability may depend critically on another that is receiving little attention. Investment may be concentrated in areas where maturity is already sufficient while more important weaknesses persist elsewhere.
These are portfolio questions. The subject of a major transformation may therefore be understood as a portfolio of organizational capabilities.
That suggests a broader definition:
Transformation is the intentional evolution of a portfolio of organizational capabilities in pursuit of strategic objectives.
Strategy Provides the Reference
If transformation is capability portfolio evolution, the organization also needs some basis for deciding what that portfolio should become.
It is not enough to say that every capability should improve. Some capabilities may already be sufficient. Others may require significant development. New strategic objectives may demand capabilities that barely exist today. Some capabilities may become less important, while others need to work together differently.
The reference therefore comes from the future the organization is trying to create. Strategy creates demands on organizational ability. Those demands can be translated into the capabilities the organization needs, the relationships between them and the relative importance of developing each one.
That provides a stronger basis for transformation than framework completeness. A framework may suggest components. Strategy should determine which capabilities matter.
Measuring the Wrong Thing
This perspective also changes how transformation progress should be assessed.
If success is measured mainly through implementation, progress may be reported through adoption indicators.
How many teams use the new method?
How many roles have been appointed?
How many planning events have taken place?
How many people completed training?
Those measures may be useful evidence that interventions occurred, but they are not necessarily evidence of improved capability.
The stronger question is whether the organization can now achieve something it previously could not achieve, or achieve it more reliably, efficiently or sustainably. That requires capability assessment. And because the capabilities interact, it may also require assessment of the portfolio as a whole.
A transformation can contain many locally successful changes while still producing a weak overall result. The parts may improve without the system becoming sufficiently capable.
The Temporary Program and the Permanent Organization
There is another consequence. Transformation programs are temporary. Capabilities are not.
The program may establish new structures, introduce practices, create communities, launch training and coordinate changes across organizational boundaries. For a time, the transformation organization itself provides much of the attention needed to keep those developments moving.
Eventually the program ends. At that point, the capabilities remain. If nobody has become responsible for their continuing management, some of the new arrangements may gradually weaken. People leave. Priorities change. Practices drift. Dependencies shift. The organization learns new things, but nobody incorporates those lessons into the capability.
A transformation can therefore succeed as a program and still fail as continuity if the project changed the organization and nobody remained responsible for managing the ability it created.
From Transformation to Capability Management
This is where transformation connects naturally to Capability Management. Transformation provides concentrated, temporary development. Capability Management provides ongoing stewardship.
A transformation may accelerate the evolution of several capabilities at once. Capability Management ensures that each strategically important capability continues evolving after the temporary intervention ends.
At portfolio level, the same distinction applies.
Capability Portfolio Management would maintain the larger view: which capabilities the organization needs, how they depend on one another, where investment is required and how the portfolio should evolve as strategy changes.
Transformation then becomes a period of deliberate acceleration within that longer lifecycle. Not a temporary departure from normal management but part of it.
Reflection
Perhaps one reason transformations disappoint is that we describe them by the thing we are introducing.
SAFe.
Agile.
AI.
Quality.
That makes implementation highly visible. But implementation is not necessarily transformation.
The deeper question is whether the organization’s abilities have changed. Can it now make better portfolio decisions? Can it translate intent into products more reliably? Can it coordinate architecture more effectively? Can it release safely and learn faster? Can it manage quality with greater confidence?
If the answer is no, the transformation may have changed a great many visible things without changing enough of what actually mattered.
Perhaps that is the better way to think about transformation. Not as the implementation of a framework.
But as the intentional evolution of the capabilities the organization needs to become something different.
Leave a Reply