When Has an Organisation Actually Transformed?

I've always been slightly uncomfortable when someone says they transformed an organisation. It isn't that I doubt their contribution. People lead transformations, sponsor them, design them and sometimes carry enormous responsibility for whether they succeed. But in any organisation of meaningful size, transformation is rarely something one person does. It happens across functions, systems, processes and people, often over a much longer period than the transformation programme itself suggests.

Perhaps part of the problem is the way we use the word. Transformation has become attached to almost every significant organisational change. We talk about digital transformation, cloud transformation, AI transformation, operating-model transformation, commercial transformation and organisational transformation. Sometimes the label is appropriate. Sometimes it makes an implementation sound more significant than it really is. In either case, I think we spend considerably more time talking about what is being transformed than asking what the organisation itself needs to become capable of doing differently.

That distinction matters because implementing something new is not necessarily the same as transforming the organisation around it. A company can introduce a new technology without changing how people work. It can restructure teams without changing how decisions are made. It can redesign a service without changing the capabilities required to deliver it. It can introduce AI without changing processes, responsibilities or expectations. All of those things may be important parts of a transformation, but none of them proves that one has actually happened.

The more transformation work I have been involved in, the more I have come to see it as a system rather than a programme. The visible change may sit in one part of the organisation, but the dependencies rarely do.

Transformation Extends Beyond the Thing Being Changed

Consider something relatively current such as introducing AI into an organisation. It is tempting to think of this primarily as a technology initiative. There are platforms to evaluate, licences to purchase, security requirements to consider, integrations to build and governance decisions to make. Those are substantial pieces of work, but even a technically excellent implementation can achieve very little if the rest of the organisation continues operating exactly as it did before.

Someone has to decide where AI should actually be used. Existing processes may need to change. Data policies need to be understood. People need to know what information can and cannot be provided to particular tools. Leaders need to decide where human judgement remains essential and who remains accountable when AI contributes to an outcome. Measures and incentives may need to change if people are expected to work differently. Managers need enough understanding to help their teams navigate questions that won't have existed six months earlier.

Then there is training.

Training is easy to underestimate because it often appears on a transformation plan as a relatively neat workstream somewhere before go-live. In reality, somebody first needs to understand the future operating model well enough to determine what people need to learn. Material has to be created, reviewed and sometimes tested. Trainers themselves may need to learn the new systems and processes before they can teach anyone else. Different roles may require different training, and a global organisation may need to deliver it across teams, regions and time zones. People then have to take time away from their normal work to attend it, practise what they have learned and become comfortable enough to use it.

All of that takes time, and all of it costs money. More importantly, much of it cannot begin properly until other parts of the transformation are sufficiently mature. A training team cannot prepare people for a process that is still changing every week. Managers cannot explain what a transformation means for their teams if they don't understand it themselves. Technology teams cannot always build the right solution before the operating requirements are clear. Finance cannot realistically understand the full cost if the organisation hasn't yet identified the people, technology, training and operational capability the new model will require.

This is why I struggle with the idea of transformation as a collection of independent workstreams all moving neatly towards the same date. They are dependencies. Decisions made in one part of the organisation continually change what another part needs to do.

A CEO can set the direction. A transformation leader can coordinate the journey. Technology teams can build the systems. Finance can determine how the change is funded and whether its economics work. HR can help redesign roles, responsibilities and organisational structures. Training teams have to turn the future state into something people can actually learn. Managers then translate all of that into everyday work, while employees are often the first people to discover where the design doesn't survive contact with reality. Customers may eventually expose consequences nobody inside the organisation anticipated.

None of those groups can complete the transformation independently.

The Transformation Didn't Start at the Same Time for Everyone

There is another part of transformation that I think organisations regularly underestimate: people experience the same transformation on very different timelines.

A leadership team may spend six months discussing a significant change before most employees hear about it. During those six months they have seen the analysis, considered different options, challenged assumptions, debated risks and gradually become comfortable with the direction. Even if the final decision is difficult, the people closest to it have had time to process why the current model needs to change and what the organisation is trying to accomplish instead.

Then the transformation is announced.

For someone elsewhere in the organisation, those six months of context may arrive as a presentation, an email or a meeting on Monday morning. They hear what is changing, perhaps receive a high-level explanation of why, and are then expected to become part of the new model.

From the perspective of the people leading the programme, the transformation has been underway for six months. From the employee's perspective, it started on Monday.

Those are very different transformation timelines.

I think this is one reason resistance to change can be diagnosed too quickly. People certainly can resist change. Familiar systems and processes are comfortable, and there will always be situations where someone simply prefers the old way. But hesitation is not automatically resistance. Sometimes people are asking questions that the transformation team had months to work through themselves. Sometimes they have spotted an operational consequence that wasn't visible from the programme level. Sometimes they understand why the organisation wants to change but don't yet know how they are expected to work differently.

If we want people to operate in a new way, telling them that the organisation has transformed is not enough. They need context, time and, where appropriate, training. They also need somewhere to raise the awkward questions that emerge when a design reaches daily operations.

That doesn't mean every employee needs to participate in every decision or agree with every aspect of the transformation. Large organisations couldn't function that way. Leadership still has to make decisions, including unpopular ones. Getting people onboard shouldn't mean manufacturing unanimous enthusiasm. It should mean giving the people affected by a change a reasonable opportunity to understand it, prepare for it and become capable of operating within it.

There is a considerable difference between asking everyone to support a transformation and preparing everyone to participate in one.

Go-Live Is Usually the Beginning of Something

Transformation programmes naturally need milestones. Budgets need dates. Technology needs release schedules. Leaders need to know whether a programme is progressing. At some point a new platform has to go live, a new organisational structure has to take effect or a new process has to become the official one.

The danger comes when the milestone starts being treated as evidence that the transformation itself is complete.

A system going live tells us that a system went live. It doesn't tell us whether people know how to use it well, whether the surrounding processes make sense, whether managers are reinforcing the new behaviours or whether the organisation has stopped relying on the old ways of working to compensate for gaps in the new ones.

The same applies beyond technology. An organisational restructure can be completed on paper long before people understand their new responsibilities. A new operating model can be launched while teams are still relying on relationships and workarounds inherited from the previous one. A new service can be commercially available before every function involved in delivering it has adapted to what the new promise requires.

None of this necessarily means the transformation is failing. Some messiness is unavoidable. I would probably be more suspicious of a significant enterprise transformation that claimed everything worked perfectly from day one. Organisations learn by operating. Assumptions that looked sensible during design will be challenged by reality, and some of the most useful feedback will come from the people doing the work after the formal implementation is supposedly finished.

The important question is what happens to that feedback.

If employees repeatedly compensate for gaps but nobody changes the underlying model, the workaround can quietly become permanent. If managers keep resolving unclear ownership through personal relationships, the organisation may never fix the decision structure. If training teaches the documented process while experienced employees know that the real process is different, the organisation can end up maintaining two operating models: the one described officially and the one required to get the work done.

A transformation can look complete from the programme office while remaining very unfinished everywhere else.

The Organisation Has to Move as a System

This is where I think the language of individual transformations can sometimes become misleading. A technology transformation affects people. A commercial transformation affects operations. An operating-model transformation affects finance. An AI transformation affects governance, training, management and accountability. A customer transformation can expose weaknesses in Product and Engineering. The labels describe where the change may have started, but they rarely describe where it ends.

Organisations are systems, and systems have dependencies.

A commercial decision can create an operational requirement. That requirement may create a need for additional capacity. Capacity needs funding. Delivery requires knowledge, processes and tooling. New tooling requires training. New responsibilities require clear ownership and decision rights. Different behaviour may require different incentives. Customers then experience the combined result of all of those decisions, not the individual transformation workstreams behind them.

This also explains why transformation can be successful in one part of an organisation and unsuccessful in another. The technology team may have delivered exactly what it committed to. Training may have delivered every scheduled course. Finance may have kept the programme within budget. HR may have completed the organisational changes. Every workstream can therefore report green while employees are still struggling to make the new operating model work.

That isn't necessarily because anybody performed badly. It may simply mean we measured the components rather than the system.

It is also why transformation requires humility. The people designing the future state cannot anticipate everything. Senior leaders won't see every operational dependency. Technology teams won't understand every customer consequence. Employees closest to a process may identify something nobody considered during design. Customers may expose contradictions that weren't visible internally.

The objective shouldn't be to prove that the transformation design was right. It should be to create an organisation capable of learning quickly enough to make the transformation work.

So When Has an Organisation Actually Transformed?

I don't think there is a single moment.

It probably isn't the day the new system goes live, the new organisation chart takes effect or the transformation programme formally closes. Those are useful milestones, and sometimes important achievements, but they tell us that something has been implemented. They don't necessarily tell us that the organisation has transformed.

Perhaps a better test is what happens afterwards.

Do people understand the new way of working without constantly referring back to the transformation programme? Can managers lead within it rather than repeatedly working around it? Do the processes, technology, incentives and organisational structures reinforce one another? Have people developed the capabilities they need? Does the training reflect how the organisation actually operates rather than how somebody expected it to operate six months earlier? When something doesn't work, does feedback travel back to the people who can improve the design?

Most importantly, has the new way become the normal way?

That is a much harder outcome to capture on a programme dashboard. It may happen at different times in different parts of the organisation, and there will probably be no meeting where someone can confidently announce that transformation is now complete.

Perhaps that is exactly the point.

Transformation isn't simply changing the thing we set out to change. It is changing enough of the organisation around it that the new way can actually work.

And until that has happened, we may have successfully implemented something new.

I'm just not sure we have transformed yet.