How to stop turning “change” into a recurring internal hobby
Or: Why Transformation #2 Is Usually Proof #1 Didn’t Stick
Background
This article was co-created together with Michael Schmollgruber & Lucas Heckmann. Thank you very much for your thoughts, discussions and perspectives!
Disclaimer: This is about large, complex enterprises: missioncritical products, real dependencies, regulated environments, “someone will call us at 3am if this breaks” territory. Not the threeperson startup. Not the “we renamed a squad and called it an operating model” crowd.
If you’ve been around big organizations long enough, you know how this story goes: the transformation “finishes,” the program office hands over a neat pile of artifacts, everyone nods solemnly - and two quarters later someone says: “We need another transformation.”
Based on my experiences accompanying various organizations and transformations, let me make one thing cristal clear: If you complete a transformation and immediately launch the next one, you didn’t transform. You ran an expensive internal project and the organization snapped back to its default settings.
And yes, I know the first objection: “But the world is changing.” Absolutely. The world changes on Tuesdays, too. If your only response to reality is a branded program every 18 months, you don’t have adaptability - you have a transformation subscription.
The transformation nobody asked for
A lot of transformations start as rational responses to real problems: time-to-market is too slow, customer experience is inconsistent, technology is brittle, costs are high, people are frustrated.
Then something happens that rarely appears in the business case: The organization becomes busy changing the organization.
Not improving products. Not reducing lead time. Not fixing the value stream. Changing roles. Changing reporting lines. Changing governance. Changing terminology. Changing templates. Changing toolchains. Changing the change.
And because internal signals are loud while customers rarely send calendar invites, the transformation becomes inwardfacing almost by default. Governance has meetings. Risk has meetings. Finance has meetings. HR has meetings. Transformation has… meetings about meetings.
Customers don’t show up with a calendar invite called “Alignment Session #3.” They show up with churn and complaints and lost deals.
So transformation becomes inwardfacing by default. And once that happens, delivery capacity starts leaking away - quietly at first, then all at once.
This isn’t just a cynical take. Major research houses have been blunt about transformation outcomes:
Bain reported that 88% of business transformations fail to achieve their original ambitions. That’s not a rounding error; that’s a pattern.
BCG wrote that only 1 in 4 transformations deliver “valuecreating, enduring change.”
And on top of that, Accenture’s Change Reinvented research found:
95% of organizations have undergone two or more transformations in the past three years
61% have had more than four (and as many as eight)
96% of Csuite leaders plan to dedicate more than 5% of revenue to change projects over the next three years
yet only 30% feel confident about their change capabilities
Read that again, slowly: we’re changing a lot, we’re spending a lot, and confidence in the ability to make change stick is… 30%. [6]
That’s not “the organization resists change.” That’s “the organization is drowning in it.”
So if your organization keeps running transformation after transformation, the question isn’t “why are people tired?” The real question is:
Why are we surprised that repeated internal upheaval doesn’t magically increase product throughput?
When transformation turns inward, products lose
Delivery teams spend more time explaining work than doing it; Product teams refine roadmaps while decisions get stuck in governance; Leaders ask for “more transparency” and get more dashboards - while the system gets slower. Everyone is busy. Everyone is exhausted. Somehow, output shrinks.
It’s not that people are suddenly less capable. It’s that the organization is consuming its own capacity on internal motion.
And this is where it gets really enterprisespecific: employee change saturation is already high.
HBR, reported that in 2022 the average employee experienced 10 planned enterprise changes (up from two in 2016). That’s not a lack of resilience, that’s a structural overload. If you stack enough “top priorities” on top of each other, you’re not driving transformation. You’re manufacturing fatigue.
At that point, the workforce develops a completely rational skill: waiting it out. Not because they don’t care - because they’ve learned the odds that this change will be replaced by the next one before it truly lands.
The hidden cost: reorganizations don’t come for free
There’s a specific variant of “transformation” that’s both common and strangely beloved: the reorganization.
Reorgs are attractive because they’re visible. You can point at boxes and lines and say, “Look, we changed something.” You can announce it. You can put it in the quarterly update.
The problem is: reorgs don’t just change structure. They disrupt relationships, decision pathways, identity, incentives, and trust - i.e., the stuff work actually runs on.
MITRE’s “Beyond Organizational Restructuring” brief references an HBR study where 60% of cases saw reduced employee productivity after reorganizations. [4] Whether your number is 60% or “it felt like 60%,” the mechanism is painfully familiar: uncertainty rises, coordination costs spike, and delivery slows while the organization re-learns how to function.
If you do this repeatedly, transformation stops being improvement and becomes reshuffling.
Deliverables are not capability
Most transformations produce deliverables. Lots of them.
target operating model slides
role descriptions
RACI charts
new ceremonies
dashboards
new “ways of working” guides
a refreshed vocabulary to sound modern
Deliverables are visible. They look like progress.
Capability is different. Capability is what remains when the program office leaves. It’s quieter, harder to fake, and far more valuable:
Teams can make decisions without escalating everything
Priorities change without political earthquakes
Quality doesn’t collapse when speed increases
Leaders steer through outcomes and constraints, not opinions and escalation chains
The organization improves continuously without a “big launch” every year
A simple test: If you shut down the program office tomorrow, would the change keep compounding - or would it collapse?
If it collapses, the transformation didn’t transform the system. It created dependency.
“One transformation is enough” (if it installs a change engine)
An organization should need only one real transformation, one that makes the organization continuously transformable - without turning every change into a major internal event.
Not “one transformation forever.” One transformation that upgrades how the organization learns and adapts so it doesn’t require a new program every time reality shifts.
That’s the difference between transforming and running transformations.
What the change engine actually consists of
This is the part where many transformations either get vague (“culture!”) or cosmetic (“let’s rename roles”). A real change engine is more concrete - and yes, it includes unsexy enterprise plumbing.
1) A product spine that survives leadership changes
If your unit of work is projects, you will keep producing internal initiatives that start with a bang and end with a slide deck. Products (or true value streams with product accountability) create continuity: longterm ownership, measurable outcomes, and the ability to learn over time instead of resetting every budget cycle.
2) Decision rights where the knowledge sits
Most enterprises don’t have a shortage of smart people. They have a shortage of distributed decision-making.
If every meaningful decision requires a steering committee, you haven’t built control - you’ve built latency. And latency is an expensive way to miss markets.
Delegation doesn’t mean chaos. It means clear boundaries, clear guardrails, clear accountability, and escalation when needed - not escalation as the default operating model.
3) A stable technology base (because “fluid” needs stable)
Everyone wants a fluid organization: dynamic teaming, flexible capacity, fast pivots.
That only works on a stable backbone: consistent delivery paths, reliable environments, good observability, coherent data, and a platform that makes the safe thing the easy thing. Without that, “fluid” turns into “fragile,” and the org compensates with… governance. (Which is how you end up launching Transformation #3.)
4) Enabling functions that can handle movement (HR, payroll, controlling)
This is where agile aspirations quietly die.
You can’t claim flexibility if payroll can’t handle flexible allocations, controlling needs three months to move cost, HR processes assume static roles, and performance management rewards individual heroics while leadership asks for team outcomes.
If the people system can’t support movement, the organization will freeze - no matter how many times you redesign the org chart.
5) Technology and AI as capacity multipliers (not toys, not threats)
Here’s the part I think many large organizations are underusing: AI shouldn’t just generate text or automate admin tasks. Used properly, it becomes part of the organization’s nervous system.
What that looks like in practice:
One governed place where decisions, standards, architecture rationale, policies, and product intent are accessible
Cross-linking between tickets, code, documentation, incidents, and decisions so context isn’t scattered
AI that helps people retrieve and synthesize what the organization already knows (not hallucinate new truths)
Decision support that produces options, trade-offs, risks, and “what we need to validate,” grounded in real constraints
This is how you reduce the enterprise tax of “we already learned this, but nobody can find it.” And that tax is a big reason organizations keep relaunching transformation after transformation: they’re repeating lessons because organizational memory is poor and decision-making is slow.
But there’s a catch - there’s always a catch: AI won’t fix organizational chaos. It will accelerate it.
If priorities are unclear, decision rights are centralized, and knowledge is fragmented, AI simply helps the org produce more output that still can’t be decided, shipped, or sustained.
The fair counterpoint: sometimes you truly need another big change
Yes - M&A happens. Regulation shifts. Platforms collapse. Strategy changes. Competitors move.
The point isn’t “never change again.” The point is: stop treating change as a recurring special event that requires a new program brand and a new org chart.
If you keep launching transformations, you’re effectively saying: “We didn’t build the capability to adapt; we built the capability to start programs.”
That’s not resilience. That’s ritual.
Three questions to ask before launching Transformation #2
If you’re about to kick off the next program, ask these - then answer them without PowerPoint:
Are we improving products and customer outcomes - or mostly optimizing internal mechanics?
What capability will exist after this that does not exist today? (Not deliverables. Capability.)
If we shut down the program office tomorrow, does the change continue - or collapse?
If the honest answer to #3 is “collapse,” you’re not building a change engine. You’re building dependency.
Closing thought
Serial transformations are not a sign of ambition. They’re often a sign the organization never installed the ability to learn and adapt without turning inward, slowing down, and reshuffling.
One transformation can be enough - if it installs the engine:
product spine
delegated decisions with guardrails
stable tech foundations
enabling functions that support movement
AI used to boost organizational capacity (memory + decision support), not just presentation output
Then you can go back to what customers actually pay for:
shipping better products - repeatedly - without needing a new program name every year.