Should operating models be considered at the start of transformation, rather than at the end?

Anchora recently attended the MarTech World Forum, one of the strongest discussions we were a part of centred on a question many organisations are still grappling with:

Should operating models be considered at the start of transformation, rather than at the end?

On the surface, it sounds like an easy yes. But the conversation was more nuanced than that.

Because while many leaders agree that operating model thinking comes in too late, the reality is that transformation rarely happens in a perfectly linear way.

Priorities shift. Teams evolve. Capability gaps become visible only once implementation is underway.

In regulated or complex environments especially, not everything can be known upfront. Still, one thing was clear: when the operating model is left too late, organisations often end up solving avoidable problems after the fact. That might look like a platform that has technically been implemented, but isn’t being used well. It might look like business teams with ideas they can’t get to market because the right support structures aren’t in place. It might look like strong ambition around personalisation, but weak alignment around what personalisation actually means, what data is needed to support it, and who is responsible for delivering it.

In those situations, the issue is often described as a technology problem. But in reality, it usually runs deeper.

Technology is rarely the whole story.

One of the clearest themes from the conversation was that many transformation challenges are blamed on the platform when the real barriers sit elsewhere. Sometimes the technology is sound, but adoption is low. Sometimes the capability doesn’t exist in-house to extract value from what has been implemented. Sometimes the process hasn’t been redesigned to support the new way of working. Sometimes the business and technology teams are both engaged, but not aligned enough to deliver outcomes together.

This is where transformation can stall. Not because the tool is incapable, but because the surrounding model for using it hasn’t kept pace.

That distinction matters.

Because if the problem is framed purely as “the technology isn’t working”, the response is often more implementation, more customisation, or more tools. But if the underlying issue is actually operating model, ownership, process or capability, then those responses can deepen the problem rather than solve it.

Operating model is not just structure

Another important point raised in discussion was that operating model is not the same thing as an org chart. It is not always about restructuring teams. In many cases, it is more practical than that. It is about clarifying how decisions are made, where ownership sits, how teams work together, which capabilities are needed to keep momentum, and what processes need to change to support the outcomes the business wants from its investment.

That can mean bringing lifecycle thinking into the way teams are organised around customer needs. It can mean defining shared goals across functions that do not naturally collaborate. It can mean testing new ways of working in shorter, focused periods before formalising larger changes. And it can mean accepting that the model may need to evolve as the organisation learns.

So while the operating model does not need to be fully locked down on day one, there does need to be enough clarity early on around vision, value, ownership and required capability.

Without that, the business is often left trying to retrofit alignment once complexity has already set in.

Cross-functional is easy to say, harder to do

Most organisations know that successful transformation depends on cross-functional involvement. Marketing, technology, data, brand, delivery and BAU teams all influence the result. But knowing that and doing it are two different things.

One of the most practical observations from the event was that cross-functional ownership often sounds right in principle, but breaks down quickly in practice. Functions revert to their own priorities. Decisions are made through internal lenses instead of customer ones. Teams are asked to collaborate without shared measures of success. Executive sponsorship exists on paper, but not in a way that resolves friction.

This is where operating model design becomes critical.

If there is no clear mechanism for bringing teams together, no agreed owner above competing functions, and no structure that forces shared accountability, transformation quickly becomes harder than it should be. The organisations that tend to do this better are not necessarily the ones with the most resources. They are often the ones that are more deliberate about creating alignment, rather than assuming it will happen organically.

So, should operating models be considered at the start?

The strongest answer from the discussion was not that everything must be designed upfront. It was that the right things need to be considered early enough.

That includes:

  • a clear view of the value the organisation wants to unlock
  • shared understanding of the problem being solved
  • the capabilities needed to support delivery and adoption
  • realistic ownership across business and technology
  • enough process design to make execution possible
  • room to adapt as the organisation learns

In other words, not a fixed blueprint and not an afterthought either. Because transformation does not fail only when the technology is wrong. It also fails when the model for making that technology useful is unclear, fragmented or left too late.

Share: