Change Is Not Transformation

Two CEOs, Same Company

General Motors had two very different leaders separated by about two decades. The first built a culture around people as the primary asset of the company. Decisions flowed from that premise. Investment, recognition, accountability, and strategy all reflected it. The people working inside the company could feel it. The people buying from the company could feel it.

The second inherited the same company name, the same factories, the same product lines, and the same organizational chart. What changed was the premise. People became a cost to be managed rather than an asset to be developed. The decisions that followed reflected that shift. Over time, so did the culture, the products, and the reputation.

Same company. Different company. The difference was not a reorganization or a product launch. The difference was what the person at the top believed about the people inside the organization, and how that belief cascaded through every decision they made.

The Decision That Lit the Fuse

Transformation does not usually announce itself. It starts with a single decision that carries a signal about what the organization now believes. The people closest to the leader read the signal. They adjust. Their teams read them adjusting and adjust further. By the time the signal reaches the edges of the organization, nobody is thinking about the original decision anymore. They are just operating inside a different set of assumptions.

That cascade is what transformation actually is. It is not a program. It is not a roadmap. It is the long chain of consequences that follows when a foundational belief inside an organization shifts. Some of those consequences are intended. Most are not. Almost none of them were on the transformation slide.

What Change Looks Like

Change is bounded. It lives at one layer of the organization. A new tool ships to a team. A policy gets updated. A process gets redesigned. A role gets eliminated or added. The rest of the organization continues operating as it was. The changed thing exists alongside everything else, subject to the same culture, the same goals, and the same measurement system that existed before the change was made.

This is not a criticism of change. Bounded, well-executed change is valuable. Most of the useful work organizations do is change, not transformation. The problem is calling it transformation. When a bounded change gets labeled a transformation, the people being asked to change hear a promise that the system around them is also going to change. When it does not, they stop believing the next promise.

What Transformation Looks Like

Transformation is unbounded. It moves through layers. When a foundational belief shifts, it eventually touches identity, culture, structure, goals, metrics, portfolio decisions, program priorities, and day-to-day operations. Not at once. Over time. In ways that are often invisible until someone looks back and realizes the organization is treating itself differently than it used to.

Using Stanford's Strategic Execution Framework as a map: transformation happens when a shift at the upper domains (identity, purpose, culture) cascades downward through the organization until it shows up in operations. Change happens when something gets adjusted in the lower domains (portfolio, programs, projects) without touching the upper ones. The upper domains are what the organization actually believes about itself. The lower ones are what it does. You can change what an organization does without ever changing what it believes. That is change. When the belief changes, the doing eventually follows. That is transformation.

Why Most "Transformations" Are Not

Most programs called transformation are change programs with a bigger word in the name. They touch the lower domains: a new platform, a new process, a new organizational layer. They do not touch the upper domains: what the organization believes about its people, its customers, its purpose, or its identity.

This is why so many transformation programs stall. The tooling changes. The org chart changes. The name of the initiative changes. The culture does not. The measurement system does not. The leadership behavior does not. The people living inside the organization can feel the gap between what the program is promising and what the organization is actually willing to change. They wait it out. They have seen enough programs come and go to know that patience is usually the right strategy.

Designing for the Cascade

If you want transformation and not just change, the work starts at the upper domains. What does the organization believe about its people? About its customers? About what it is for? If those beliefs are not part of the conversation, the cascade will not happen. You will get a new platform and an old culture. The platform will adapt to the culture, not the other way around.

Designing for the cascade means being honest about what layer you are actually working at. If you are working at the portfolio or project layer, call it change. Deliver the change well. That is valuable. If you want transformation, name what belief needs to shift, find the leaders who hold it, and work with them on it directly. The cascade follows belief. It does not follow a project plan.

The two CEOs at General Motors did not set out to transform the company in opposite directions. One believed in people and built accordingly. The other believed in cost and cut accordingly. Neither of them was running a transformation program. They were just leading. And the organization cascaded around them, in both cases, exactly as you would expect.