Skip to content
Richard Cooper
Go back

The five barriers to digital transformation aren't technical

When a digital transformation stalls — and most of them do — the post-mortem reaches for a technical culprit. The legacy system was too tangled. We picked the wrong cloud. We didn’t have enough AI, or data, or platform. It’s a comfortable story, because technical problems have technical fixes you can buy.

It’s also usually wrong. David Rogers, who has spent a career studying why transformations succeed and fail, catalogues the things that actually block them, and the striking part of his list is that none of them are really about technology. Five barriers keep coming up, and every one of them is organisational.

The five, and why none of them are technical

1. No shared vision. Everyone in the building is “transforming”, and if you ask them towards what, you get five different answers. Not a technology gap — an alignment gap. You cannot architect your way to a destination the leadership hasn’t agreed on, and no platform decision fixes a room that doesn’t share a picture of where it’s going.

2. The wrong priorities, or none. The organisation tries to do everything at once, so nothing lands. Prioritisation feels like an operational chore, but it’s the most strategic act there is: choosing what to do means choosing what not to do, which is just what you’re optimising for wearing a project-plan hat. A transformation with forty priorities has none.

3. It can’t experiment. The organisation can’t run small, cheap tests and learn from them, so it makes big irreversible bets instead and prays. That’s a culture-and-process problem, not a tooling one. It’s also why reversibility matters so much: a team that can only walk through one-way doors daren’t try anything, and a team that daren’t try anything can’t transform. Cheap experiments need cheap reversal.

4. Governance that’s wrong-sized. Either there’s none — and change is chaos nobody trusts — or there’s so much that every decision drowns before it ships. Getting this right is a genuine balancing act, and I’ve written about coming round to lightweight governance with actual teeth precisely because both failure modes are so common. Too little and nobody believes the change is safe; too much and nobody can move.

5. A capability gap — people, not stack. This is the one that disguises itself as technical. “We don’t have the skills” sounds like a hiring-a-cloud-engineer problem, but it’s overwhelmingly about talent, ways of working, and culture — whether the organisation can actually operate differently, not whether it owns the right software.

Conway’s Law is standing behind all five

Notice the shape. Vision, priorities, experimentation, governance, capability — every barrier is about how the organisation thinks and works, not about what it runs. And there’s a reason a digital transformation keeps failing on human barriers: you’re trying to change the system, but the system mirrors the organisation that built it. Change the software without changing the org and the old shape simply grows back, because the forces that produced it never moved.

Which is why the one lever that shifts these barriers is cross-boundary collaboration — getting the silos to actually work across their edges. The barriers are the walls between functions made visible: no shared vision because product and engineering and the business never align; can’t experiment because the hand-offs are too slow to close a loop; capability gaps because knowledge is trapped in departments. Lower the walls and the barriers drop with them. That’s not a coincidence — it’s the same law, read from the other direction.

The uncomfortable part for technical leaders

If you build systems for a living, the tempting move is to treat the transformation as an engineering programme: get the architecture right and the rest follows. It doesn’t. You can ship flawless architecture into a transformation and still watch it fail, because the barriers that kill it aren’t in the code — they’re in the alignment, the focus, the appetite to experiment, the governance, and the people.

So the technical leader’s real job in a transformation turns out to be at least as organisational as it is technical: forcing the vision to get specific, defending a short list of priorities, making experiments cheap and safe to run, right-sizing the governance, and closing the gaps between teams rather than just between services. That’s uncomfortable, because it’s not the work we signed up for. It’s also where the actual leverage is.

Buy all the cloud you like. Add the AI. Untangle the legacy system — that’s worth doing on its own merits. The transformation will still succeed or fail on vision, focus, learning, governance, and people. The technology, as usual, was never the hard part.


Share this post:

Previous Post
DevOps, SecOps, DevSecOps
Next Post
Zero-downtime by design