Change vs. Transformation: Why Your “Transformation” Might Just Be Change in a Trench Coat
Everyone calls it a transformation. Almost none of it is.
The Hook
Everyone calls it a “transformation.” The new tool rollout. The reorg. The Scrum ceremonies bolted onto last year’s org chart. Almost none of it is.
Change and transformation get used as synonyms in every steering committee deck I’ve ever sat in, and that confusion is expensive. Change is something an organization does. Transformation is something an organization becomes. Mix them up, and you either underdeliver on a real transformation ambition with change-sized tools, or you exhaust everyone trying to “transform” something that only ever needed to change.
Field Vignette
A few years into an SAP Finance IT program, I watched this play out almost in slow motion. The engagement began exactly as these things usually do: integrate the working processes across finance, ABAP development, and functional consulting; standardize on SAP Activate-aligned delivery; install the ceremonies — standups, sprint reviews, backlog refinement — on top of teams that had previously handed work to each other over a wall.
For months, that’s all it was. Change. New rituals, same command structure. The standups happened; the decisions still moved exactly the way they always had.
The transformation started when the question in the room shifted from “are we running the ceremonies right” to “how do finance, IT, and the business actually decide things together now.” The rituals didn’t change. What happened inside them did — because the assumptions about who owns what decision had finally moved. That’s the tell: identical practices can sit on top of an untouched system or a genuinely transformed one, and the practices alone won’t tell you which.
I’ve seen the same fork elsewhere. A fintech built from a string of acquisitions needed to look like it was changing — same sprint cadence, same tools, same definition of “done” across teams. But the real work only started once we stopped treating it as a process-alignment problem and started treating it as a culture-alignment problem: naming the different tribal assumptions each legacy team carried, and building a shared culture people could actually belong to. Standardizing tools was change. Building belonging was transformation.
The Model: First-Order vs. Second-Order
Systems theory gives us the cleanest version of this distinction: first-order change happens within a system — the rules stay fixed, only the variables move. Second-order change rewrites the rules themselves.
Installing Scrum ceremonies inside an unchanged hierarchy is first-order. Decentralizing decision rights, rewriting how power and information actually flow, redefining what “success” means for a team — that’s second-order. Most agile transformations stall precisely here: they install the artifacts of agility while leaving the deep structure — who has authority, who owns risk, how incentives are set — completely intact. New vocabulary, old operating system.
The two also behave differently in time. Change is linear and reversible — you can specify a start date, a milestone, an end date, and roll it back if it doesn’t work. Transformation is nonlinear and largely irreversible. You cannot roll back a shared culture of belonging once a fragmented organization has adopted one. There’s no clean prior state to return to.
This is also why heavy governance can quietly kill transformation ambition. On a regulated financial-services workstream I advised on, the executive reporting cadence — fixed milestones, RAG statuses, linear roadmaps — was built for auditable change. Reasonable instruments, wrong system: they suppressed exactly the ambiguity tolerance a real operating-model shift needed, because ambiguity doesn’t fit in a status report.
The Practical Tool
Before you label anything a “transformation,” ask two questions in the room:
- What layer are we actually touching? Processes and tools (change) — or identity, mental models, and power (transformation)? Be honest; most initiatives are change, and that’s fine, as long as you stop calling it something bigger than it is.
- What happens if we reverted tomorrow? If the answer is “we’d just go back to the old tool/process,” you’re doing change — manage it with a plan, a sponsor, milestones. If the answer is “there’s no going back, people have already changed how they see themselves,” you’re doing transformation — and it needs sensemaking spaces, iterative experimentation, and leaders who can tolerate ambiguity, not a Gantt chart.
I saw this most clearly in a large-scale assessment organization’s modernization effort. The initial ask was pure change: upgrade the platform, digitize the pipeline. The real issue was that the organization’s whole sense of purpose was still anchored to being technology-driven rather than value-driven. Rebuilding the platform without answering “what do we believe our job is now” would have been a beautifully executed change that transformed nothing.
If you’re staring at an initiative right now and genuinely unsure whether it’s change or transformation dressed up as each other, that diagnostic conversation is exactly the kind of work I do with leadership teams through the AO Method. If that’s useful, reach out via Menschgeist or Agile Organization.
Closing Reflection
The next time someone in your organization announces a “transformation,” ask them one question: what, exactly, will be different about who we are — not just what we do?
If nobody in the room can answer that, you’re probably about to manage a change project with a transformation-sized budget and transformation-sized expectations. Know which one you’re actually running before you start.
Pierre Neis · Menschgeist · agile-organization.com
Discover more from Menschgeist
Subscribe to get the latest posts sent to your email.