Every transformation conversation eventually reaches the same practical question: what does actually working together look like. Not the strategy, not the roadmap, but the shape of the engagement itself. Get that wrong and even a well-scoped programme with the right outcomes defined can still fail on delivery, because the commercial and operational model underneath it doesn't fit what the business actually needs.

‍

This gets less attention than it should. Most transformation conversations focus on what needs to change, not on how the relationship with the people delivering that change should actually be structured. But the delivery model shapes almost everything downstream, including cost, pace, risk, and how much capability the business is left with once the engagement ends.

‍

Why one model doesn't fit every business

‍

The instinct, especially from traditional consultancies, is to have a single way of working and fit every client into it. That's convenient for the consultancy. It's rarely convenient for the client. A PE-backed business six months from exit has very different needs to one eighteen months into a hold period with a clear growth thesis still being built. A business that already has strong internal engineering capability and just needs specific expertise plugged in for a defined initiative needs something different again.

‍

Every model should be sized for the outcome the business actually needs, not for the utilisation curve of whoever is delivering it. A lot of engagement structures exist to keep a delivery team busy and billing, rather than to match what the client genuinely requires at that point in their journey.

‍

The three shapes a transformation engagement can take

‍

Broadly, there are three ways this tends to work, and most transformation needs fall into one of them.

‍

The first is an embedded transformation partner model, where the external team works alongside the client's own team as an extended delivery capability, leading or co-leading a defined programme end-to-end. This suits businesses that need real delivery capacity, not just advice, and where the scope is broad enough to justify a genuinely embedded team working inside the organisation rather than around it.

‍

The second is a focused discovery engagement, producing a clear, costed transformation roadmap with board-ready output. This is the right starting point when the business isn't yet sure what the right programme even is, or needs something concrete to take to a board or investment committee before committing to a larger piece of work. It's lower commitment and faster, and it should stand on its own rather than being a thinly disguised sales pitch for a bigger engagement.

‍

The third is specialist augmentation, where experienced practitioners are embedded into the client's existing team where specific capability gaps exist, to accelerate ideation, design and delivery of a particular initiative. This suits businesses with strong internal teams that just need a specific gap filled quickly, rather than a broader external delivery structure.

‍

Matching the model to where the business actually is

‍

The mistake most businesses make isn't picking the wrong model outright. It's not being clear enough about what stage they're actually at before the conversation starts. A business heading toward exit within eighteen months has a different set of priorities to one in the middle of a growth phase, and those priorities should shape the delivery model, not just the roadmap content.

‍

If the priority is proving to a future buyer that the business understands its own technology risk and has a credible plan, a focused discovery engagement that produces board-ready output might be exactly right, even if it doesn't deliver any code. If the priority is actually shipping a specific capability gap that's been holding the business back, specialist augmentation gets there faster and cheaper than standing up a full embedded team. If the transformation is broad, foundational, and needs real delivery capacity over a sustained period, the embedded partner model is usually the only one that actually works.

‍

Discovery before delivery, regardless of model

‍

Whichever shape the engagement ultimately takes, the sequencing matters more than the label. Understanding the commercial reality of the business before the technical one changes what gets prioritised, and that holds true across all three models. A timeboxed discovery phase, typically weeks rather than months, that produces a prioritised roadmap rather than a long report, gives both sides a clean decision point before committing to anything larger.

‍

This matters commercially as much as it matters practically. It means the client isn't locked into a large engagement before anyone has properly tested the assumptions underneath it, and it means the delivery team assembled for the next phase is the right team for the actual work, not a generic team assigned before the scope was properly understood.

‍

Why this connects back to capability transfer

‍

The delivery model also determines what the business is left with once the engagement ends. An embedded partner model that treats capability transfer as a planned part of the programme, not an afterthought bolted onto the final few weeks, leaves the client with people who genuinely understand and can maintain what's been built. A model that doesn't plan for that leaves the client dependent on the external team indefinitely, which is a liability for any business, and a specific one for a PE-backed business approaching exit, where buyers are increasingly testing exactly this question.

‍

Getting the delivery model right isn't a formality before the real work starts. It's one of the decisions most likely to determine whether the transformation programme actually holds up, both during the engagement and long after the external team has gone.

‍