I’ve had the privilege of sitting on both sides of the classroom: as someone who has led digital transformation programs at scale across multiple industries, and as a visiting faculty member who teaches executives in management programs.

The gap between the two vantages is striking.

Business school curricula have gotten much better at covering the what of digital transformation — cloud migration, AI adoption, platform business models, agile delivery. But there are lessons that only accumulate through the scar tissue of doing it for real, at scale, with real organizational politics and real stakes. These rarely make it into the curriculum.

Here are five of them.

1. The Technology Is the Easy Part

I’ve said this so many times it’s almost a cliché in my circles — but it keeps needing to be said, because organizations keep making the same mistake.

When a transformation program struggles, the problem is almost never the technology. It’s the organization. It’s the incentive structures that reward the old way of working. It’s the middle managers whose identity and influence are tied to the processes being automated. It’s the governance model that was designed for a waterfall world trying to oversee an agile initiative.

Digital transformation is fundamentally an organizational change program that uses technology as its catalyst. If you design it as a technology program with some change management bolted on, you will fail. Or you’ll succeed on paper — the system will go live — and fail in reality, as adoption stays low and the old workarounds persist.

2. Pilot Purgatory Is a Real Risk

Every transformation program starts with pilots. Pilots are valuable: they test assumptions, build capability, generate proof points, and create internal advocates. Done well, they are excellent.

But I’ve seen too many organizations spend two years running pilots and never scale. The pilot succeeds. The business case looks compelling. And then… nothing. The organization defaults back to business as usual while the pilot team celebrates incremental wins in isolation.

Pilot purgatory happens when the scaling muscle hasn’t been built, when there’s no clear governance for moving from pilot to program, and — most often — when senior leaders haven’t committed to changing the core business model, only to experimenting at the edges.

The discipline of scaling is different from the discipline of piloting. Most organizations are better at the latter.

3. Data Quality Is Infrastructure, Not a Project

When organizations embark on AI and analytics initiatives, they routinely underestimate the data work involved. Then they discover their data is fragmented, inconsistent, poorly governed, and partially wrong. A “90-day analytics initiative” becomes a 2-year data remediation program.

The deeper problem is that data quality has historically been treated as a cleanup project — something you fix when you need it. What high-performing organizations understand is that data quality is infrastructure. It requires ongoing investment, clear ownership, and governance discipline, the same way you would treat a network or a cloud platform.

I tell executives: your AI strategy is only as good as your data strategy. And your data strategy is only as good as your data governance. Build the foundation, or you’ll be rebuilding it forever.

4. “Digital Native” Leaders Are Not Automatically Good Change Leaders

There’s a tempting shortcut that many organizations take: hire someone young and digital-native to lead the transformation. They know the tools. They’ll bring energy. They’ll challenge the old ways.

Sometimes this works. Often, it doesn’t.

Digital fluency is not the same as organizational influence. Transformation requires navigating political capital, building coalitions, understanding legacy business constraints, and earning the trust of people who have been in the industry for decades. These are skills that come from experience — not from knowing how to build a Snowflake pipeline.

The best transformation leaders I’ve worked with combine genuine technology literacy with deep organizational savvy and the patience to work within constraints while still pushing hard. That combination is rare and undervalued.

5. Declare Victory Thoughtfully

Transformation programs need milestones and wins — they sustain energy and justify investment. But I’ve seen programs declare victory too early, too loudly, only to unravel as the deeper change work hadn’t actually been done.

A system going live is not transformation. A process being digitized is not transformation. Transformation means the organization is operating meaningfully differently, at scale, with measurably different outcomes, in a way that would survive the exit of the program team.

That test — “would this survive the exit of the program team?” — is one I’ve come to use regularly. If the answer is “not really,” the change hasn’t been embedded. The program may be a success, but the transformation hasn’t happened yet.

None of these lessons are secret. Many practitioners know them intuitively. But knowing something and building it into how you design and govern a transformation program are very different things.

That’s why I keep teaching them — because the gap between the classroom and the boardroom is still wide, and the cost of that gap, in failed programs and lost potential, is enormous.