Why Digital Transformation Fails: It’s Not the Technology, It’s the Middle Management

Paul Thomas • May 4, 2026

Share this article

Boards approve digital transformations. IT delivers them. Consultancies design them. So why does McKinsey research consistently show that around 70 per cent of large-scale transformation efforts fail to meet their original objectives?


Not because the technology was wrong. The platforms are mature. The integrators are competent. The business cases were defensible at the point of approval.


Digital transformations fail in the middle layer of an organisation. The heads of function, the operational leads, the team managers. The people who are expected to absorb the change while still hitting last year’s targets. That layer rarely gets the support to do both.


The Top Floor Decides. The Shop Floor Adapts. The Middle Carries the Cost.


Look at how most transformations are structured. A board sponsor sets the vision. A programme team designs the future state. IT builds the platform. Training is rolled out to end users.


Now look at where the friction lands. The head of operations is being asked to learn the new system, retrain her team, hit quarterly numbers on the old system while the new one rolls out, and represent the change positively to her people. None of which she was resourced for.


She is not resisting. She is overwhelmed. And when overwhelmed middle management quietly de-prioritises the transformation in favour of the day job, adoption stalls. Without adoption, the benefits case collapses. McKinsey’s own transformation practice names a lack of engagement across the organisation as one of the most consistent reasons transformations underperform.


Three Reasons the Middle Layer Gets Left Behind


1. The transformation is treated as a technology programme

If the project plan reads like a system implementation, with phases for design, build, test, go-live, and hypercare, there is no workstream that owns the human change. The assumption is that training plus communications equals adoption. It doesn’t.


Real adoption requires people to change how they do their work. That requires time, support, and permission to slow down temporarily. None of which appear on a typical implementation plan.


2. The middle layer wasn’t involved in design

Programmes that go straight from board sponsor to technical design skip the layer that knows how the work actually gets done. The resulting solution is theoretically correct and operationally awkward. The people being asked to use it can see the friction immediately, and they were never consulted about it.


Once that gap is visible, trust in the transformation drops. Workarounds appear. Shadow processes emerge. The shiny new platform is technically live and operationally bypassed.


3. There is no slack in the system

Organisations run lean. The same managers who own the day-to-day are the ones being asked to own the change. There is no spare capacity to absorb the cost of transition. So either the day job gives, or the change gives, and the day job almost always wins, because that’s what their compensation is tied to.


If the programme didn’t plan for backfill, secondments, or temporary reinforcement at the operational layer, it didn’t plan for adoption.


How to Land Digital Transformation in the Middle


Treat adoption as a workstream, not an afterthought

Give it a senior owner. Give it a budget. Give it a plan that runs alongside the technical build, not after it. Adoption isn’t something you sprinkle on at go-live. It is built into the programme from week one.


Involve middle management in design, not just delivery

The people who run the operation should help shape the operation’s future. Not in a token workshop. In the design decisions that affect their daily work. The cost of involving them is a few weeks of their time. The cost of not is two years of slow adoption.


Resource the transition honestly

If the change is large enough to need a programme, it is large enough to need temporary capacity at the operational layer. Interim project managers, secondments, backfill: whatever it takes to give middle management room to lead the change rather than survive it.


Measure adoption, not implementation

Going live is a milestone, not an outcome. The real measure of transformation is whether the new way of working has displaced the old one twelve months after go-live. If it hasn’t, the platform may be running, but the transformation hasn’t happened.


The Pattern We See Most Often


Halfway through a transformation, the programme is technically on track. The platform is being built. The board reports are green. But there are quiet signals from the operation. Questions that aren’t getting answered. Training dates being pushed. Change champions going silent. The middle layer is starting to disengage.


That is the moment to intervene. Not at go-live. Not in hypercare. Now. The cost of fixing adoption mid-programme is a fraction of the cost of fixing it after launch, when habits have set and the platform has already missed its first benefits milestone.


If your digital transformation is technically on track but operationally quiet, that quiet is the warning sign. We help mid-market organisations land transformation where it has to land: in the layer that has to live with it.

Free Project Assessment & Audit, Tailored to You

Not sure where your project really stands? We assess what's happening, and give you a clear and honest picture at no cost. Every engagement starts with understanding your specific situation, because no two organisations are the same.

Totally free. No commitment needed.

Recent Posts

By Bernadine Dela Cruz • September 17, 2026
Learn the realistic timeline for PMO setup. Get expert guidance on phases & common pitfalls to scale your delivery capability effectively.
Four colleagues review notes around a table in a modern office, with a whiteboard and sticky notes nearby.
By Paul Thomas • September 15, 2026
What does project recovery actually cost in the UK? A board-ready breakdown of pricing, timelines, and what drives the number up or down.
PMO blocks beside “Project Management Office” on a white desk with clips and keyboard
By Paul Thomas • September 8, 2026
Interim PMO leadership explained: what it covers, when it's the right call, and what a senior interim PMO lead actually does in the first 30 days.
Business meeting with two people across a table, one using a tablet and the other smiling in an office.
By Paul Thomas • September 7, 2026
Deciding between an interim project manager and a permanent hire? Here's how to make the call in a week, with real cost and speed comparisons. Free assessment.
Hands holding a tablet with charts in a business meeting over papers and a laptop
By Paul Thomas • September 2, 2026
Rolling out Agile or SAFe hasn't fixed your transformation's adoption problem? Here's why frameworks and adoption are different problems entirely.
Modern glass skyscrapers, including a twisting tower, against a clear sky
By Paul Thomas • August 31, 2026
A practical checklist for vetting agile consulting firms in the UK, CVs, conflicts of interest, exit plans, before you sign anything.
Three coworkers in business attire discussing a tablet in a bright office lounge
By Paul Thomas • August 29, 2026
Six questions to ask any agile project management consultancy before you sign, so you know what you're actually buying.
Agile Consultancy: What the Term Actually Means | Agileminds
By Bernadine Dela Cruz • August 26, 2026
Searching for an "agile consultancy" in the UK? Here's what the term really covers, and how to tell a framework vendor from a delivery partner. Free assessment included.
Colleagues reviewing documents at a shared office table with laptops, one person leaning over to help
By Paul Thomas • August 23, 2026
A PMO should remove friction, not create it. Learn how engineering-focused PMOs improve delivery without adding unnecessary process or overhead.
Two people review a document at a desk, one pointing while the other writes notes.
By Paul Thomas • August 23, 2026
Before you hire a project recovery consultancy, ask these six questions on speed, seniority, independence and proof. Start with our free two-week assessment.
Show More