I have worked in organisational transformation for more than 20 years, across organisations of very different sizes, sectors and circumstances. Some of that work has involved technology, some workforce reform, culture, operating models, organisational structures and new ways of working, and quite often several of those things happening at once.
Over that time, I have become increasingly interested in the distinction between delivering change and actually transforming an organisation.
Organisations can be very good at change. We can implement the system, restructure the organisation, launch the strategy, redesign the process, train everybody, complete the project and report the milestones as green. All of those things might have been necessary, and they might have been delivered extremely well.
But they don’t, by themselves, tell us whether the organisation is now better at doing what it was trying to do. That is the distinction that matters to me.
When I talk about organisational transformation, I mean an intentional improvement in how the organisation operates that enables better outcomes. Something should be materially better as a result. Perhaps decisions happen faster and with better information. Work moves through the organisation with fewer unnecessary hand-offs. Customers have a better experience. People can spend less time navigating systems and more time doing valuable work. Risk is better understood and managed. Data can actually be trusted. The organisation can respond more quickly, produce more efficiently or deliver something it previously couldn’t.
The particular outcome will depend on what the transformation was intended to achieve. What matters is that we can connect the change we made to an improvement in the organisation’s ability to achieve that outcome.
That sounds obvious when you say it like that. In practice, I don’t think we always hold transformation to that standard.
Transformation is one of those words that has become broad enough to describe almost anything.
Implementing a new technology platform becomes a digital transformation. Changing the organisational structure becomes an organisational transformation. A collection of improvement projects becomes a transformation portfolio.
Any of those things might contribute to transformation. I just don’t think the activity itself is sufficient evidence that transformation has occurred.
A new system makes the organisation different because it now has a new system. That doesn’t necessarily make it better. If employees still need spreadsheets and workarounds to compensate for poor data or an impractical process, we have certainly implemented something, but we need to be much more careful about what we claim has transformed.
The same applies to structure. We can redraw reporting lines and move hundreds of people into different teams. The organisation is unquestionably different afterwards. But if decisions have become slower, accountability less clear and end-to-end work more fragmented, I would struggle to describe that as successful transformation simply because the organisation changed.
So the test I tend to apply is more demanding.
What became different? Did it become better? And is that improvement helping us achieve the outcome the transformation was intended to create?
Those questions take us beyond implementation and into the operating reality of the organisation. They make us look at how decisions are made, how work moves, how information is used, where accountability sits, what leaders reinforce, what gets measured, what people have to do to get something done and, ultimately, whether the organisation is more capable of achieving what it set out to achieve.
That is where transformation becomes meaningful.
A project can be genuinely well delivered and still produce much less organisational improvement than expected. That isn’t necessarily because the project team did something wrong. Sometimes it is because we measure the success of the intervention more carefully than we measure the outcome it was supposed to create.
| Delivery asks… | Transformation asks… |
|---|---|
| Did we successfully implement what we planned? | Did that implementation improve the way the organisation operates and contribute to the outcome we were trying to achieve? |
We know whether the technology went live, how many people attended training, whether communications were distributed and whether the new structure was implemented. Those measures tell us whether we delivered what we said we would deliver. They don’t necessarily tell us what happened next.
If the reason for introducing technology was to reduce processing time, did processing actually become faster? If we redesigned a process to improve the customer experience, can customers feel the difference? If we restructured to create clearer accountability, are decisions now being made more effectively?
We need both levels of measurement. The danger comes when evidence of delivery is treated as evidence of transformation.
I have spent a significant part of my career working in and around organisational change, so this isn’t an argument against change management. Good change practice matters enormously.
I do think, though, that organisations sometimes ask change management to solve problems that aren’t fundamentally change management problems.
Imagine people aren’t following a new process. We could reasonably respond with more communication, training, leader reinforcement or engagement. Any of those might be appropriate. Before doing that, I want to know why people aren’t following it.
Perhaps they don’t understand it. In that case, we may indeed have a communication or capability problem. But perhaps the process requires them to enter the same information into two systems. Perhaps it takes twice as long as the process it replaced. Perhaps responsibility is unclear at one of the hand-offs. Perhaps the performance measure they are accountable for rewards them for doing something completely different. Perhaps the old spreadsheet gives them information the new system doesn’t.
Now we have a different problem.
What looks from a distance like resistance might be perfectly rational behaviour within the environment we created.
This is where behavioural science has changed the way I approach transformation. I am much less interested in labelling people as resistant than I am in understanding what around them is making the behaviour we are seeing make sense.
Once we understand that, we can make a much better decision about what actually needs to change.
We often divide transformation into workstreams because it makes complex work manageable. People, process, technology, data, governance and organisational design may all have their own leads, plans and deliverables.
Employees don’t experience the organisation in workstreams.
Someone trying to serve a customer experiences the system, process, information, approval limits, performance measures, relationships, leadership expectations and team norms at the same time. To them, it is simply the environment in which they are trying to get something done.
That distinction matters because each component can look sensible when considered independently while the experience created by all of them together is dysfunctional.
A process might be perfectly logical until you try to perform it in the system. A system might technically do exactly what was specified, but the underlying process might never have been properly resolved. A restructure might create clearer accountability within individual functions while making an end-to-end customer process more fragmented.
This is why I spend so much time trying to understand how work actually moves through an organisation.
I want to see where it begins, who touches it, where information changes, where decisions happen, where work waits, where somebody has to go backwards, where information gets re-entered and where someone leaves the formal process because the only practical way to get the outcome is to invent another way of doing it.
Those moments tell you an enormous amount about the organisation you actually have, rather than the organisation represented in its documentation.
A workaround is easy to interpret as non-compliance. Sometimes it is. Often, though, it is somebody solving a problem.
That makes workarounds incredibly useful during transformation because they show us where the formal organisation and the practical reality of getting work done have separated.
If people maintain their own spreadsheet, create a shadow system, message somebody privately for approval or follow an unofficial process, I don’t want my first question to be, “How do we stop them doing that?” I want to know what the workaround allows them to achieve.
Perhaps it gives them visibility the formal system doesn’t provide. Perhaps it avoids a bottleneck. Perhaps it compensates for unreliable data. Perhaps it gives them control over something for which they are still held accountable.
Once we understand the function of the behaviour, we can decide whether the behaviour itself needs to change, whether the environment producing it needs to change, or both.
Simply removing the workaround without solving the problem it was solving often means another workaround appears in its place.
A useful transformation test
WHAT BECAME DIFFERENT?
↓
DID IT BECOME BETTER?
↓
DID THAT IMPROVEMENT HELP CREATE THE OUTCOME WE INTENDED?
Difference alone is not evidence of successful transformation. The change needs to improve the organisation in a way that contributes to the outcome it was intended to achieve.
Leadership matters enormously during transformation, although I think we sometimes reduce the leadership role to communication or ‘sponsorship’.
We prepare leader packs, town halls, talking points and messages explaining why the transformation matters. And while there is certainly value in all of that, people need context, and leaders need to be able to explain where the organisation is going.
But people also watch what leaders actually do! They notice what gets prioritised when there is a genuine trade-off. They notice whether an executive who talks about enterprise thinking continues making decisions that optimise their own function. They notice what happens when somebody raises an inconvenient problem with the transformation. They notice which exceptions are approved, what leaders repeatedly ask about, who is held accountable and whether the new way of working still matters when following it becomes difficult.
That behaviour is communication too. And in most cases, it is more powerful than the formal communication because it teaches people how seriously to take what they have been told.
What leaders pay attention to tells people what matters. What they reward influences what is worth doing. What they tolerate helps establish what is acceptable. The questions they repeatedly ask direct organisational attention. What they do when something goes wrong teaches people what is safe. And whether they follow the new expectations themselves tells people whether the transformation is real.
That is why I don’t think leadership alignment is demonstrated by everybody agreeing with the transformation in a steering committee meeting. I am much more interested in whether leaders’ subsequent decisions and behaviour are creating the conditions for the organisation they say they want.
Governance has somehow acquired a reputation for being the boring administrative part of transformation. I find that unfortunate because good governance can remove an extraordinary amount of organisational friction.
For me, governance is fundamentally about enabling the right decisions to be made by the right people, with the right information, at the right level and at the right time.
When that isn’t clear, you feel it everywhere. Decisions travel through meeting after meeting. The same issue is discussed by several groups because nobody is entirely sure who owns it. Projects compete for the same resources without a mechanism for resolving the conflict. A decision appears to have been made, only to be reopened two weeks later by someone who wasn’t involved. Accountability becomes distributed so widely that nobody can really be held accountable at all.
Transformation tends to expose these weaknesses because it introduces decisions that cut across the normal boundaries of the organisation.
That is why, when designing governance, I prefer to start with the decisions rather than the committees.
What decisions does this organisation need to make? Who should own them? Who genuinely needs to contribute? What information is required? What principles or constraints apply? Where does the decision go if it cannot be resolved?
Once we know that, we can determine what governance is actually required.
Most organisations are structured vertically. Work rarely is.
A customer order might move through sales, operations, manufacturing, logistics, finance and service. Each function can perform its own part reasonably well while the overall customer experience remains unnecessarily difficult.
This creates one of the recurring traps in transformation: we improve individual components of the organisation without improving the system as a whole. Sometimes we even make the whole worse.
A function reduces its own processing time by moving an activity downstream. Another team now has more work. One part of the organisation improves its cost position by removing capacity that an end-to-end process depended upon. A technology decision solves the needs of the team buying the system while creating additional work for everyone who consumes its data.
From inside the function, the decision can look entirely rational. From the perspective of the whole organisation, it can be destructive.
An end-to-end view makes us ask where value actually moves, where the hand-offs occur, where information is lost, where accountability becomes unclear and where somebody downstream is compensating for something that happened upstream.
It also forces us to become much clearer about what we mean by better.
Better for whom? Better at what? And at what cost elsewhere in the system?
That is an important transformation question because local improvement is not necessarily organisational improvement.
For me, behavioural science isn’t an additional workstream within transformation. It is a lens I bring to understanding how the organisation works.
Organisations ultimately operate through human behaviour. A strategy only becomes real through the decisions and actions people take. A process only works when people perform it. Governance depends on people making and respecting decisions. Technology creates value when people use it in ways that improve the work. An operating model exists in practice through the way people coordinate, decide and act.
So when a transformation isn’t producing the outcome we expected, I want to get close enough to the behaviour to understand why.
What happens immediately before the behaviour? What does the person need to know? What is easier? What requires extra effort? What are other people doing? What does the system allow or default to? What consequence follows? What does the person risk by behaving differently?
Sometimes that analysis tells us we do need better communication, capability or reinforcement. Sometimes it tells us that asking the person to change while leaving everything around them untouched would be absurd.
And that is why I keep returning to a question that sits across much of my work: what are we doing as an organisation that might be helping to create the behaviour we’re trying to change?
There are plenty of established transformation methodologies, and I don’t feel any need to invent another one simply to put my name on it.
What I do have, after more than two decades doing this work, is a sequence of questions I tend to work through regardless of the particular methodology being used.
1. Start with the outcome
What needs to become better? What outcome are we trying to create, and how will we know the organisation is more capable of producing it than it is today?
2. Understand how the organisation really works now
Get underneath process documentation and organisational charts to see how work, information and decisions actually move, including the workarounds, dependencies and informal practices people have developed.
3. Understand why the current state makes sense
What is it about the systems, processes, data, governance, structure, leadership and broader environment that produces the way work happens today?
4. Define what needs to become better
What should people be able to do that they cannot do now? Which decisions need to improve? What friction needs to disappear? What capabilities need to exist? What outcomes should improve as a result?
5. Design the conditions that make that future possible
That might involve technology, process, data, structure, governance, capability, leadership or behaviour. Usually it involves several of them.
6. Implement and learn
No design survives contact with a complex organisation exactly as imagined. Watch what happens when the new way of working meets reality, understand unintended consequences and adjust.
7. Come back to the outcome
Did it work? Not merely: did we deliver it? Did the organisation become better at achieving the outcome we set out to improve? That is the test.
This isn’t a proprietary transformation methodology. It is the practical sequence of questions that more than two decades of transformation work and behavioural science have taught me to ask.
I am slightly cautious about talking about making change “stick” because it can imply that the goal is to arrive at a transformed organisation and somehow hold it there. Organisations don’t stay still long enough for that…People change. Leaders change. Customers change. Technology changes. Markets change. Strategies change. Something that made perfect sense when we designed it may become an obstacle several years later.
So I am less interested in making a particular transformation permanent than I am in creating an organisation capable of sustaining the improvement and recognising when it needs to evolve again.
If a transformation only works while there is a program team chasing actions, producing reports, reminding leaders and escalating non-compliance, I am not convinced it has yet become part of how the organisation operates.
The more interesting point comes when the systems, processes, information, governance, leadership and everyday behaviour begin reinforcing the improved way of working without the transformation machinery having to hold it together.
At that point, we have created something more valuable than a successfully delivered program. We have improved the organisation’s capability to operate. And perhaps, if we have done the work particularly well, we have also improved its capability to transform again when it needs to.
My perspective on transformation comes from more than 20 years spent working inside complex organisations and transformation environments, including establishing enterprise organisational change capability within a 52,000-person organisation and leading behavioural and workforce reform as part of a $1.2 billion transformation portfolio. Those experiences have included organisational and cultural transformation, operating models, governance, workforce transition, systems and process change, and working with executives trying to turn strategic intent into an organisation capable of delivering it.
The contexts have been very different, but the question beneath the work has remained remarkably consistent:
What needs to change in this organisation so that it can produce a better outcome than it can today?
Sometimes the answer sits predominantly in behaviour. Sometimes it sits in technology, process, data, structure or governance. Most of the interesting problems don’t respect those disciplinary boundaries.
Which is why I don’t think of organisational transformation as a collection of projects sitting alongside the business.
At its best, transformation is the deliberate work of improving the organisation itself.