Your digital transformation team can't live inside IT

The transformation programmes I get called into are usually dying for the same reason, and it isn't the technology. The team is talented. The platform is fine. What's killing the work is the org chart — where the team sits, and what that placement forces it to become.

Put a digital transformation (DX) team inside enterprise IT and you've already made the critical mistake. Not because IT is incompetent. Because IT is optimised for something else entirely.

The operational backbone is doing exactly what it's supposed to do

MIT CISR researchers Jeanne Ross, Cynthia Beath, and Martin Mocker named a concept most executives nod along to but never operationalise: the operational backbone. It's the stable, standardised enterprise IT platform that keeps the business running — ERP, core banking, order management, finance infrastructure, the machinery of business as usual — and its whole mandate is reliability, compliance, and efficiency. Controlled change. Rigorous governance. Release cycles and architecture review boards that exist to protect production and stop technical debt accumulating at scale. The idea is developed in full in their book, Designed for Digital.

None of that is dysfunction. It's engineering discipline applied to systems the business depends on every day. The backbone is supposed to be hard to change quickly. That's the feature, not the bug.

The problem starts when you feed a transformation through the same machine.

Wire DX into IT governance and you get slow death

Wire a DX team into enterprise IT governance and the same things happen, in roughly the same order.

• Releases queue behind the quarterly cycle. A two-week experiment ships in three months and the learning it was meant to generate arrives too late to matter.
• Each impacted business unit has its own approval silo, so one initiative ends up answering to half a dozen change boards with different cadences and different vetoes.
• Review boards do what they were built to do and treat every new pattern as a risk to be minuted.
• Funding is annualised and scope-locked. What the team learns can't change the plan without a change request.
• And the team you hired for product speed spends its sprints writing compliance artefacts.

So an initiative that started with real momentum slowly suffocates inside the machine. Delivery slows, the team spends more time navigating process than building product, scope gets cut to protect dates, and the business quietly stops believing. Eventually someone declares failure and writes it off as 'the wrong technology' or 'not the right time'. That diagnosis is almost always wrong — the technology was fine, the timing was fine, the operating model was the problem.

What structural separation actually looks like

Separation isn't a skunkworks hiding in the shadows. It's a deliberately different operating context, and in practice it comes down to four decisions.

• A separate funding line with outcome gates, not an annual scope lock.
• Release authority inside the team, with guardrails agreed up front.
• Its own delivery cadence — weekly, not quarterly.
• And a reporting line to whoever owns the outcome, not into the run organisation.

Separation also changes the governance maths. A DX initiative inside IT confronts the whole corporate approval apparatus from day one, for work that is still a hypothesis. Separated, you can build a decision-rights framework sized for what the team actually is — a small group proving a concept — and defer the full overhead until the work is operationalised, which in a well-designed DX programme is after the tech is built and the concept proven. The overhead doesn't disappear. You just don't pay it before you have to.

Separation is not isolation

This is where the model breaks in execution. Organisations hear 'separate the DX team' and read it as 'let them do whatever they want'. That's equally catastrophic, just slower to show, because whatever the DX team builds eventually has to run on the backbone: customer-facing products integrate with ERP, data pipelines connect to enterprise platforms, and security posture has to clear enterprise requirements before anything reaches production scale.

The engineering principle that makes the interface workable is loose coupling. Integrations with the backbone should be few, well-defined, and built with the minimum surface area the outcome allows. Every interface the team takes on drags a slice of the legacy stack into their delivery path — another schema to honour, another change board to brief. Keep the surface small and the team negotiates a contract. Let it sprawl and they're navigating the entire backbone, which is the thing separation existed to avoid.

So the handover gets designed from day one, not bolted on at the end. The team takes embedded enterprise architecture input early — not to gate decisions, but to make sure what they're building can land where it has to land, with security requirements understood up front rather than discovered in an integration sprint six months out.

I've paid for this lesson personally. Project PACE proved the maths and published the paper, and it still never made production planning, because the pathway back into the backbone wasn't designed alongside the work. The separated team did everything asked of it. Separation creates the conditions for speed; only a deliberate, loosely coupled interface with the backbone makes the output usable at scale. You need both.

That's what I saw. Here's what we do about it: change and adoption go into project planning and risk analysis in the very first meetings of an engagement — before anyone has fallen in love with a platform.

The cost of getting this wrong

I keep watching organisations spend the better part of two years — and seven figures — learning this the slow way. The pattern barely varies: a strong start, a slow stall, then the quiet rituals of scope cuts and 'descoping to phase two' until someone resets the programme or kills it. If you've sat through that descoping meeting, you know exactly the silence I mean.

The ones that get it right move faster, ship more, and actually finish. Not because they have better technology or better people. Because they made one structural decision early that protected the conditions their team needed. The Metagenics D2C launch is what that looks like in practice: a new channel run as its own programme with its own cadence, live in six months, on budget, while the 40-year-old practitioner business beside it kept trading untouched.

Digital transformation is not an IT project. It's an organisational change initiative that happens to require technology. Run it accordingly.