What Does Transformation Leave Behind?

Published: 28 September 2026
Platform: LinkedIn
Original article: https://www.linkedin.com/pulse/what-does-transformation-leave-behind-john-laverick-sbihf/

Why delivery, sustainability and organisational capability need to be measured together.

We spend a lot of time measuring what transformation delivers. Perhaps we should spend more time measuring what it leaves behind.

It’s a question that has become increasingly interesting to me as AI changes how we build software, organise teams and think about productivity. We have opportunities to improve services and deliver technology at a pace that would have been difficult to imagine even a few years ago. As someone who uses AI extensively, I find that genuinely exciting.

But it also raises a question about the relationship between delivery and organisational capability. Are we always making the organisation stronger as we accelerate its output, or might we sometimes be consuming capabilities that have taken years to develop?

The things we can measure

Most transformation programmes are reasonably good at measuring visible progress. We can count systems replaced, processes automated, money saved and services improved. We can track milestones, benefits and delivery performance, and these are all legitimate ways of demonstrating that change is producing results.

What is harder to measure is the organisational knowledge that sits underneath those outcomes.

Consider a team that has spent years maintaining a complicated system. They understand its quirks, its dependencies and the reasons why certain things work the way they do. They know which apparently unnecessary processes exist because of an edge case that nobody thought to document, and which integrations are more fragile than they appear.

Some of that knowledge will be written down, but much of it probably won’t be. It exists in conversations, experience and the collective understanding of people who have spent years solving problems together.

A transformation replaces the system. The old team is reorganised, new technology is introduced and the programme delivers its objectives. That might be absolutely the right decision. Maintaining legacy technology simply because people understand it is hardly a sensible strategy.

But did we retain the knowledge that mattered? Did we understand the dependencies before replacing them? Have we developed the people who will maintain and evolve the new solution?

Those questions are just as important as whether the system was delivered on time, yet they can be considerably harder to answer. Organisational knowledge is difficult to quantify, and its value often becomes most apparent when something goes wrong.

AI changes the equation

I’ve become a reasonably enthusiastic user of AI-assisted development. As a self-taught coder, I’ve been building applications in my spare time that I would previously have struggled to produce on my own. It’s a hobby, rather than enterprise software development, but it has fundamentally changed my relationship with building things and given me a practical appreciation of what’s becoming possible.

I’m certainly not interested in going backwards. And while my own experiments are a long way from an enterprise software development lifecycle, I can see a point in the not-too-distant future where AI supports much more of that lifecycle, from understanding requirements and designing solutions through to coding, testing, deployment and maintenance. That will require appropriate engineering discipline, governance and human accountability, but the opportunity to change how organisations develop software is enormous.

But the more I use it, the more I wonder whether we are starting to separate two things that have historically happened together: producing software and developing the people who understand software.

Traditionally, building something meant spending time understanding how it worked. Junior developers learned by reading other people’s code, debugging unexpected behaviour, making mistakes, fixing them and gradually developing judgement. Much of that learning happened through the experience of doing the work rather than through a formal training programme.

AI can remove a remarkable amount of that friction, and that’s one of its greatest strengths. It allows people to experiment, explore ideas and produce working software much more quickly. It can also make sophisticated development capabilities accessible to people who would previously have found the technical barriers difficult to overcome.

But some of the friction we remove was also practice.

An organisation might now be able to produce more software with fewer developers. It might genuinely improve productivity, accelerate delivery and reduce costs. Those are outcomes worth pursuing, but if they also mean recruiting fewer junior developers, spending less time understanding existing systems and relying increasingly on a smaller number of experienced people to supervise AI-generated work, we need to think about how the next generation develops its judgement.

We might be producing more while learning less.

That isn’t inevitable. AI could equally become one of the most powerful learning tools we’ve ever had. It can explain unfamiliar code, help people explore alternatives, generate tests and make experimentation dramatically cheaper. Someone learning to code today has access to a level of support that simply didn’t exist when many of us started.

The opportunity is enormous, but we need to design for that outcome. Developing people cannot simply be assumed to happen as a by-product of faster delivery.

Two different time horizons

This is where transformation leadership becomes particularly interesting.

Some benefits are visible almost immediately. A new platform goes live, operating costs fall, delivery accelerates or a process that previously took days now takes minutes. These improvements are tangible, and organisations understandably want to see them.

Other benefits, and some consequences, take much longer to emerge. Developing an experienced engineer takes years. So does building a team that understands a complex service, establishing effective ownership of technology and creating the organisational knowledge needed to respond when something unexpected happens.

These capabilities matter enormously, but they don’t always fit neatly into a conventional programme dashboard. They are also difficult to attribute to a single initiative because they develop across teams, services and successive periods of change.

The tension isn’t unique to any particular sector or leadership model. Public and private organisations face different incentives, but both must balance immediate delivery with longer-term sustainability. There is no simple answer, because preserving everything is not sensible and delaying necessary change can be just as damaging as moving too quickly.

The challenge is making those trade-offs consciously.

When we simplify a service, what knowledge must we retain? When we automate work, how will people develop the judgement that previously came from doing it? When we introduce new technology, who will own and evolve it once the original delivery team has moved on?

These shouldn’t be questions we leave until the end of a programme. They are part of the transformation itself.

Three dimensions of success

Perhaps we need to think about transformation success in three dimensions: delivery, sustainability and capability renewal.

Delivery is the dimension we’re most familiar with. Did we achieve the outcomes we set out to achieve? Are services better, have costs reduced and can the organisation do things it couldn’t previously do? Without meaningful delivery, transformation risks becoming an exercise in changing structures and technology without improving anything for the people who depend on them.

Sustainability asks whether the organisation can operate, maintain and evolve what has been delivered. Does it understand its technology, data, processes and dependencies? Can it respond when something goes wrong, and does it have the ownership and expertise needed to continue improving its services?

Capability renewal is about what happens next. Are we developing the people, skills and knowledge needed for the next stage? Can the organisation continue improving without depending indefinitely on the individuals or suppliers who delivered the original transformation?

These dimensions are related, but they aren’t interchangeable. An organisation could perform exceptionally well against its immediate delivery objectives while gradually weakening its ability to sustain those improvements. Equally, a transformation that strengthens all three dimensions may require investment whose benefits won’t be immediately visible.

That creates difficult choices for those of us responsible for leading change, but at least we should be making those choices deliberately rather than discovering the consequences later.

This isn’t an argument for slower change

Sometimes the greatest threat to long-term capability is failing to change quickly enough. Legacy technology can consume resources, constrain services and prevent people from developing modern skills. Organisations can preserve knowledge that is no longer useful while failing to build the knowledge they actually need.

AI gives us extraordinary opportunities to improve that position. It can help us modernise systems, make better use of information, remove repetitive work and enable people to tackle problems that were previously beyond their reach.

The point isn’t to protect existing structures or insist that every task continues to be done manually because someone might learn something from it. It’s to recognise that when we fundamentally change how work gets done, we also need to reconsider how people learn, how knowledge is retained and how organisations develop the capability to keep improving.

That is a leadership responsibility, not an argument against technology.

It also means looking beyond the technology itself. A successful transformation depends on the people who understand the service, the teams responsible for its outcomes and the organisational environment that allows them to make good decisions. AI can be a remarkable enabling capability, but it doesn’t remove the need for those things.

A different definition of success

As execution becomes cheaper, we will have more opportunities to change things, replace things and build things. That’s exciting, particularly for those of us who have spent years trying to make technology delivery more accessible and effective.

But the ability to produce something quickly doesn’t automatically give us the organisational capability to understand, maintain and improve it. We need to pay as much attention to the experience we develop, the knowledge we retain and the ownership we establish as we do to the immediate outputs of a programme.

Perhaps we should judge transformation not only by what it delivers, but by whether the organisation is better equipped to keep improving afterwards. Can its people understand and evolve the systems we’ve built? Can its teams take ownership of their services? Are we developing the next generation of capability rather than simply relying on the experience we already have?

Because a successful transformation programme and a successfully transformed organisation might not be quite the same thing.