Transform · Technology & Operating Model Transformation

Technology does not transform a company. Operating models do.

For companies where the technology opportunity is no longer in doubt and the organisation still cannot move — and where what is needed is senior judgment about direction, not another implementation programme.

Technology applied to a bad process produces a faster bad process, and a larger budget line to defend it with.

The pattern

The stall is rarely about tools. Pilots demonstrate well and never reach production. Automation exists in a dozen places and belongs to nobody. Technology and business functions each hold half of the problem. Software has accumulated for a decade without an architecture, and critical work quietly runs on spreadsheets, local tools and, increasingly, on AI nobody has inventoried.

Each of those is a symptom of the same thing: technology decisions being made at the level of individual projects, while the constraint sits in the operating model — how work is divided, who owns which process, where accountability ends and what the organisation is capable of running.

AI raises the stakes on both sides. It makes far more possible, and it makes it far easier to create dependencies faster than governance can absorb them.

What this is, and what it is not

This is direction and judgment: what to change, in what order, what to stop, and what the organisation actually has to become for the technology to matter. Implementation is done by internal teams or selected partners — the advantage here is independence, not delivery capacity.

It is deliberately not a large programme that grows with the recommendations it makes. Where a programme is the right answer, saying so and stepping back is part of the work.

01

Situations this addresses

Written as they are usually described in the first conversation.

Stalled change

  • AI pilots demonstrate well and never scale
  • A transformation programme has been running for years with unclear results
  • Technology and business teams are working on different problems
  • Automation exists in fragments and belongs to no one

Accumulated technology

  • Software has grown without architecture and every change is expensive
  • Critical processes run on spreadsheets and local tools
  • AI is being used across the business without an inventory or a policy
  • Data cannot move through the business without manual handling

Unclear economics

  • Technology cost is high and the business value is not visible
  • Robotics or automation projects with unconvincing payback
  • Build, buy, platform or stop — decided repeatedly and inconsistently
  • Post-merger technology and process rationalisation

Ownership and control

  • Nobody can say which systems are business-critical
  • Convenience has quietly become critical infrastructure
  • A new operating model is needed before the next technology investment
  • A private-equity owner needs a credible hundred-day technology plan

02

How the work runs

Short, direct, and structured so it ends with decisions rather than with a phase two.

  1. What the company is actually trying to change

    The stated objective and the operational one are often different. Everything downstream depends on separating them at the start.

  2. How the work really runs today

    Process, systems, data flows, ownership and the informal workarounds that hold the whole thing together. The workarounds are usually the most informative artefact in the company.

  3. Opportunity and dependency, mapped separately

    Where AI and automation can genuinely take out cost and time, and where the business already depends on things that are not built to be depended on. Both belong in the same conversation and almost never are.

  4. Sequence and operating-model implications

    What has to change in what order, what the organisation must be able to run, what should be stopped, and which decisions can be deferred without cost.

  5. Read-out and challenge

    Presented to the people who can decide, argued rather than delivered, and written so it can be circulated and disagreed with.

03

Typical engagements

Bounded pieces of work, chosen for the situation rather than assembled into a programme.

  • Technology transformation assessment
  • Operating-model review
  • AI opportunity map, with the cases that do not pay marked as such
  • Process architecture review
  • Automation portfolio review
  • Robotics opportunity assessment
  • Build, buy and platform decisions
  • Technology portfolio rationalisation
  • Hundred-day value-creation planning
  • Red-team review of an existing transformation plan

Most engagements are one or two of these, not all of them. A long list here is a description of the range, not a proposal.

04

Where this is worth doing

A good fit

  • A leadership team that wants its plan attacked before it is funded
  • Owners or boards who suspect the transformation is producing activity rather than change
  • Companies where AI ambition is real and the operating model has not been examined
  • Post-merger situations with two of everything and no decision about which one survives
  • Portfolio companies where the value-creation plan depends on operational change

A poor fit

  • Implementation capacity, interim management or an outsourced technology function
  • A recommendation to buy a specific tool
  • Change nobody in the leadership team actually wants

Bring the operating problem

Describe what has not moved, what has been tried, and what the organisation believes is in the way.

For owners, CEOs, managing directors, boards and private-equity operating partners.