I have lived through several transformations in my life.
Some were chosen. Some were necessary. Some became exciting only in retrospect.
As I wrote in my first article, I have moved between countries and continents. From the outside, every move can look like a new beginning: another place, another opportunity, another chapter.
But transformation rarely feels like a beginning when you are standing at the beginning of it.
At first, it often feels like an ending.
When I moved to the United States, I left my family behind. I left familiarity. I left the small things you barely notice until they disappear: the way people speak, the assumptions you share, the invisible rules that make everyday life predictable.
And gradually, something else happened.
America changed the way I thought.
I became more comfortable with the idea that things did not necessarily have to remain the way they were. If something was not working, perhaps it was not impossible to change. Perhaps I needed to look at the problem differently.
Change the angle.
Change the perspective.
Try another way.
Years later, when I moved to Germany, I encountered another instinct.
I heard variations of one question surprisingly often:
Why change something that is working?
Initially, that frustrated me.
Eventually I realised that there was intelligence in that question too.
Not every change is progress.
Sometimes an existing system survives because it contains knowledge that is not immediately visible to the person trying to replace it. Processes evolve around operational realities. Workarounds sometimes exist because the official process has a gap. And organisations remember transformations that promised improvement but delivered additional complexity.
The instinct to change and the instinct to preserve both have value.
The difficult part is knowing which one is right.
That became increasingly important to me as my work moved deeper into large business and technology transformations.
We use the word transformation constantly.
Digital transformation. Business transformation. Organisational transformation.
But transformation is not simply replacing a system.
A business is itself a system.
Technology is part of it. So are processes, data, governance, operating models, decision-making, knowledge, incentives and the people who make all of those things work together.
Change one part and the effects rarely remain there.
That is why I have become interested not only in asking:
What needs to change?
I also ask:
What are we asking people to leave behind?
Not because transformation is primarily a people-management exercise.
Because the answer often tells you something important about the system you are changing.
Ask people about a system they use every day and they will usually tell you where it fails them.
They know which screen takes too long.
They know which process is duplicated.
They know where information disappears.
They know which spreadsheet exists because two official systems do not communicate properly.
They know which workaround everyone quietly uses because the documented process does not survive contact with reality.
But those same people may also defend things that genuinely should disappear.
A local process may work very well for one team while creating complexity everywhere else.
A workaround may solve today’s problem while creating tomorrow’s operational risk.
A requirement may be perfectly reasonable in isolation but impossible to justify once cost, scale, architecture, governance or the needs of the wider organisation are considered.
This is where transformation becomes difficult.
You have to distinguish between valuable knowledge embedded in the existing system and familiarity that no longer deserves to be preserved.
I remember conversations in which I would present a proposed solution and ask someone what they disliked about it.
“Everything.”
Everything?
There is very little value in defending a solution at that point.
Instead, I would keep asking.
What exactly does not work?
Which part?
What will become more difficult?
What are you able to do today that you believe you will no longer be able to do?
Why does the current process work this way?
Gradually, “everything” becomes something specific.
And specific problems can be examined.
Sometimes we had explained the proposed model badly.
Sometimes someone had misunderstood it.
Sometimes resistance came simply from familiarity.
And sometimes the person was identifying a genuine flaw in our design.
That last possibility matters.
A transformation team can understand architecture, technology and the target operating model and still miss something important that is obvious to someone who has operated inside the existing environment for ten years.
Listening does not mean accepting every requirement.
It means understanding what the requirement is telling you before deciding what to do with it.
That distinction became particularly clear to me during a large transformation programme.
We were changing a major system and way of working across multiple operational sites.
The initial response from many people was predictable.
No.
From their perspective, they already had processes they understood. They knew their local operations. They knew how to make the existing environment work. Now a new system and a different operating model were being introduced.
We could have designed the solution centrally, implemented it everywhere and dealt with the consequences afterwards.
Instead, we looked for the site most willing to go first.
They agreed to become the first implementation.
That site became much more than an early adopter.
It became where we tested our assumptions.
We were not only testing whether people would accept the new system. We were testing whether our design was actually right.
A design that looks coherent in a project room is still only a hypothesis.
Once people begin using it in a real operating environment, you discover whether the pieces actually fit together.
We saw where the proposed solution worked.
We saw where it did not.
People challenged parts of the design.
Some of those challenges exposed things we had missed, and we changed the solution.
Others represented local ways of working that could not reasonably become part of a common model, and we said no.
That was equally important.
Transformation is not consensus.
A solution for an organisation cannot become the sum of every local preference.
There are architectural constraints, costs, operational dependencies, governance requirements and enterprise objectives that also have to be protected.
The job is to understand the whole system well enough to know where to adapt and where not to.
Meanwhile, the other sites could watch.
They did not have to believe a presentation describing how the transformation might work.
They could see it.
They saw people like themselves challenge the design.
They saw changes being made when evidence justified them.
They also saw that not every request was accepted.
Most importantly, they saw the first site continue operating successfully in the new model.
After that, the conversation changed.
The transformation was no longer theoretical.
We had evidence.
Then we went site by site.
What began with significant resistance became one of the most successful projects I worked on.
I carried several lessons from that experience.
One was about people.
Some people are comfortable stepping into something new before all the answers are visible. Others need evidence first.
Both reactions matter when designing a transformation.
But the larger lesson was about systems.
A transformation cannot be judged only by whether the technology works.
Nor can it be judged only by whether a process has been redesigned, a project has met its milestones or a deployment has been completed.
The real question is whether the new operating system works as a whole.
Can people perform the work?
Does information move where it should?
Are responsibilities clear?
Does the technology support the process?
Do local decisions still make sense at enterprise scale?
Have new risks been created while old ones were removed?
Does the solution survive real operations?
And when the answer to one of those questions is no, which part of the system needs to change?
That is also why listening and compromise have to be handled carefully.
Sometimes a team must give up a familiar process because a common process creates greater value for the organisation.
Sometimes an excellent idea has to wait because it is not essential to going live.
Sometimes an individual requirement simply costs too much or introduces too much complexity.
I have often told teams during transformations: if we cannot implement an idea now, write it down.
Do not lose it.
We deliver what we need to establish the new model.
Then we return to the list.
Does the idea still solve a real problem?
Does it fit what we have learned from operating the new system?
What would it improve?
What would it cost?
Is it still worth doing?
Transformation does not end when the new system goes live.
A go-live gives you a different kind of information: evidence from reality.
And reality should always be allowed to challenge the design.
Perhaps that is what my own moves between countries taught me long before I began thinking about transformation professionally.
Every significant transformation requires something to be left behind.
Sometimes what we leave behind genuinely should disappear.
Sometimes it contains knowledge worth preserving.
And sometimes we do not yet understand which is which.
That is why I no longer think of transformation simply as moving from point A to point B.
It is the redesign of a system while that system is still operating.
Technology matters.
Process matters.
Architecture, data, governance and economics matter.
And people matter — because they operate the system, understand parts of it that diagrams do not always show, and ultimately expose whether the new model actually works.
So when I begin looking at a transformation, I still ask:
What needs to change?
But I also ask:
What are we asking people to leave behind — and what does that tell us about the system we are trying to build?
Because understanding both is usually where the real transformation begins.