Why Your Transformation Won't Outlast Its Creators

Last month I named an uncomfortable pattern: most change efforts depreciate. Billions invested. Returns temporary.

The organisations commissioning transformation know it. The consultants delivering it know it. The boards approving the budgets suspect it. Everyone keeps doing it anyway. The business press is full of articles diagnosing the "transformation treadmill" — the exhausting cycle of change programmes that never quite stick. The pattern is finally getting attention. What's missing is the structural explanation — and a test for whether you're actually escaping it.

This month I want to go deeper. Not just what happens, but why. Because the structural reasons matter — they determine whether anyone can do anything about it.

Here's the uncomfortable truth: depreciation isn't a failure of execution. It's a failure of architecture. The way most transformation gets built guarantees it won't last.

Part 1: The Problem

The Depreciation Pattern

Watch any large organisation long enough and you'll see it.

A transformation launches. Significant investment — consultants, technology, internal resources. Early wins generate excitement. Case studies get written. People get promoted.

Then time passes. The project team moves on. The consultants finish their engagement. Attention shifts to the next priority.

Two years later, you'd hardly know it happened. The gains have eroded. The capability has dispersed. The organisation is starting over — often on the same problem.

This isn't rare. It's the default.

I've watched it happen with digital transformations, culture programmes, innovation initiatives, operating model redesigns. Different labels, same pattern. Activity that felt like progress but didn't leave anything behind.

The question isn't whether you've seen this. The question is why it keeps happening — and whether it has to.

Part 2: Why It Happens

Four Structural Reasons

Depreciation isn't random. It follows predictable structural patterns.

1. Capability Concentrates

Most transformations create pockets of excellence rather than distributed capability. The project team becomes expert. The consultants hold the methodology. A few key people "get it" while everyone else watches.

This feels like progress — you can point to the capable people. But capability that concentrates is capability that's fragile. When those people move on, the capability moves with them.

2. Knowledge Stays Tacit

Ask the people running a successful transformation what makes it work, and they'll struggle to explain. They know it when they see it. They make dozens of judgment calls that produce quality. But they can't articulate it clearly enough for someone else to follow.

This is normal — most expertise is tacit. But tacit knowledge doesn't transfer. It doesn't scale. It doesn't survive the departure of the people who hold it.

3. Dependency Forms

Successful transformations create heroes — the people who make it work through sheer force of will. They coordinate across silos. They translate between groups. They hold the whole thing together.

This heroic coordination isn't wrong — exceptional people doing exceptional things is often how breakthroughs happen. Linda Hill and her colleagues call them "bridgers" – and they are right that these people are essential to getting innovation across the finish line. But it's not scalable. And it's not transferable. What looks like leadership is actually a symptom: it signals that the underlying infrastructure doesn't exist. The principles aren't clear enough. The systems don't enable distributed judgment. So everything flows through human switchboards.

The problem isn't the heroes. It's building as if you'll always have them.

4. Key People Leave

This is the obvious one, but it's worth stating plainly. People move. They get promoted. They take other jobs. They retire.

If the transformation depends on specific people, their departure is a countdown to depreciation. Not because they were bad at their jobs — because of how the thing was built.

The Four Types of Change

Part of why depreciation persists is that we use one word for very different things.

Type 0: Continuous Calibration. Micro-adjustments, course corrections. This should be constant and expected. There was never a moment when everything worked.

Type 1: Surface Change. Products, campaigns, processes. These change constantly — monthly, quarterly. They should be agile and experimental.

Type 2: Capability Change. Systems that enable the generation of Type 1 solutions. These change periodically — every few years. The infrastructure should last; the agility it enables should flex.

Type 3: Principles Change. Core truths that guide everything. These change rarely — once a decade, if ever.

Most transformation confusion comes from mixing these up. Treating Type 1 solutions as if they need Type 3 permanence. Treating Type 3 principles as if they need Type 1 flexibility.

The real gap is Type 2. Most organisations have a purpose statement (Type 3) and constantly change their products and processes (Type 1). What they lack is the infrastructure in between — the capability layer that makes good decisions possible at scale.

What does Type 2 infrastructure actually look like? It's not a platform or a process. It's the layer that tells people how to make good decisions when no one's watching.

Think: principles clear enough that a new hire can apply them without asking permission. Systems that surface quality problems before they reach customers. Ways of working that spread through use rather than training programmes. The scaffolding that makes distributed judgment possible.

Next month I'll go deeper into what this architecture looks like. For now, the key point: most transformation investment goes to Type 1 (new solutions) or Type 3 (purpose statements). The infrastructure that would make either of them stick gets skipped.

Why Good Strategy Isn't Enough

Here's something I've learned that might be uncomfortable for strategists to hear: strategy alone can't solve this.

I've watched brilliant strategies depreciate. Not because the thinking was flawed — because no one built the infrastructure for distributed execution. The direction was clear. The capability to sustain it wasn't.

Strategy sets the destination. It doesn't build the vehicle that gets you there and keeps running after the driver changes.

This isn't an argument against strategy. Good strategy is necessary. It's just not sufficient. The gap between strategy and lasting execution is where most transformation investment goes to die.

Filling that gap requires something most strategy work doesn't touch: building the infrastructure that enables people throughout the organisation to make good decisions without checking upstairs. And developing the leadership capabilities to let them.

Why the Incentives Push Toward Depreciation

Understanding the structural reasons isn't enough. You also need to understand why they persist — why smart people in well-run organisations keep building things that depreciate.

Quick wins over lasting capability. Boards want results. Executives want to show progress. Consultants want to demonstrate value. All of these push toward visible short-term wins rather than invisible long-term capability.

Clear credit over distributed ownership. When capability concentrates, credit is clear. When capability spreads, credit diffuses. Career advancement rewards the former.

Being indispensable over becoming unnecessary. Consultants who make themselves unnecessary lose their contracts. Internal experts who distribute their expertise lose their unique value. The incentive is to stay needed.

Moving fast over building deep. Exploration takes time. Experimentation requires patience. Building infrastructure is slower than delivering solutions. Every timeline pressure pushes toward the faster option.

None of this is malicious. It's structural. The default path leads to depreciation because that's where the incentives point.

Overcoming it requires building differently from the start — and reshaping the incentives for the people involved.

What might that look like? Consultants whose contracts include a "departure test" milestone — paid in part on whether capability transfers, not just whether the solution launches. Internal teams measured on how many people they've made capable, not just what they've delivered. Leaders evaluated on what still works a year after they've moved on, not just what they achieved while in role.

These aren't fantasy. I've seen versions of each. But they require commissioners who ask for them and providers willing to be held to them. That's rare — which is why depreciation remains the default.

Part 3: The Reframe

Rented vs Built

Here's a useful distinction: are you renting capability or building it?

Rented capability looks like:

• Consultants who deliver solutions but not the ability to generate them
• Project teams who hold the expertise rather than spreading it
• Centres of excellence everyone depends on rather than learns from
• Key people who "just know" how things work but can't explain it

When any of these leave, capability leaves with them.

Built capability looks like:

• Principles anyone can apply
• Infrastructure that enables judgment
• Know-how that spreads through use
• Systems that improve without their designers

When people leave, the capability stays.

To be clear: the issue isn't whether you use consultants or project teams. It's the model of engagement. The same consultancy can either extract value or build capability — it depends on what they're asked to do and how success is measured. Most are asked to deliver solutions. Few are asked to leave capability behind.

Renting is faster to start. It's easier to justify — you can point to clear deliverables and expert resources. It feels like you're buying competence.

But rented capability depreciates. Built capability compounds.

Most organisations don't choose renting consciously. They fall into it because the structural reasons and incentives push that way. Now you can see why.

Building takes longer upfront. The payoff is less visible. Success means becoming unnecessary — which doesn't feature in most performance reviews.

Not everyone wants that trade. But it's the only one that lasts.

The Departure Test

Once you understand the distinction between renting and building, you need a way to test which one you're doing.

I've started applying a simple diagnostic: if everyone who built this left tomorrow, would it keep working?

It's a brutal test. Most initiatives fail it.

Not because the people were lazy. Not because the strategy was wrong. Because the capability was never designed to outlive its creators.

This test should be applied at the board level. Before approving transformation budgets, ask: what will remain when the project team disbands? What capability will the organisation own independently? How will we know if we're building an asset or renting an outcome?

Most boards don't ask these questions. They approve investments based on projected returns without examining whether those returns are structurally durable.

Here's the question that changes the conversation:

If the key people left tomorrow, would this keep working?

Once you're asking that, others follow:

• What will remain when the project team disbands?
• How will we know if capability is concentrating or spreading?
• Are we building Type 2 infrastructure or just funding Type 1 activity?
• What's the half-life of this investment?

These questions surface whether you're making a strategic investment — or funding sophisticated activity that will depreciate like any other expense.

Part 4: The Path Forward

What Compounding Looks Like

If depreciation is the default, what does the alternative look like?

I built a marketing experimentation capability a few years ago. In its first year, it generated 300 million DKK in incremental revenue. The formal infrastructure is gone now — reorganisation and shifting priorities claimed it.

But something survived. Eighty marketers who learned a different way of working. The structure didn't last. The capability did. I've since watched some of them build experimentation into their own teams. Others have applied the thinking in contexts the programme never touched — different markets, different channels, problems we never anticipated.

Here's what I've noticed about capability that compounds:

It spreads. People teach each other. The knowledge doesn't stay locked in a few heads — it propagates through the organisation. Five years later, it's not a "programme" anymore. It's just how work gets done.

It improves through use. Each application makes it stronger, not weaker. People discover new ways to apply it. Edge cases get incorporated.

It works without its creators. The people who built it can leave, and it keeps functioning. Not because it's frozen in place — because the capability transferred.

It survives structure changes. Reorganisations happen. Priorities shift. Budgets get cut. Capability that compounds persists through these disruptions because it lives in people and principles, not in org charts and programme offices.

Where to Start

If you're reading this and recognising the pattern in your own organisation, here's where to start:

Before your next transformation investment, ask the investment committee to answer the departure test explicitly in the board paper. Not as a throwaway line — as a section that explains what capability the organisation will own independently when the project ends.

For transformations already underway, ask the programme lead: if your team disbanded tomorrow, what would keep working? If the honest answer is "not much," you're renting. That doesn't mean stop — it means change what you're building toward.

For your own leadership, notice where you're the human switchboard. Where does quality depend on your judgment rather than systems others can use? That's where capability is concentrating rather than spreading.

The Alternative Is Possible

Depreciation isn't inevitable. Some transformations build capability that compounds. The organisations that achieve this aren't luckier or better resourced. They build differently.

What that architecture looks like — the principles, the levels, and what it demands of leaders — is what I'll explore next month.

This is part of an ongoing exploration of what makes change last — the gap between strategy and execution, and what actually bridges it.