Every few years, a new wave of technology promises to fix what ails banking. Mainframe modernisation. Service-oriented architecture. Cloud migration. Microservices. AI. Each wave brings genuine capability, and yet the same problems persist: slow delivery, duplicated systems, inconsistent customer experiences, and mounting operational cost.

The diagnosis almost always points to the same culprit: legacy technology. But after spending ten years leading digital transformation inside a major regional bank — building products from scratch, scaling teams, and shipping through every kind of organisational friction imaginable — I have come to a different conclusion. The most underestimated driver of complexity in banking is not technology. It is organisational structure.

“You can replace every system in a bank and still deliver the same broken experience — if the org structure hasn’t changed.”

This is not an argument against investing in modern technology. It is an argument for sequencing the work correctly — and for being honest about where the real friction lives.

Product Models in Name Only

The shift toward product-based operating models has become the dominant strategic narrative in banking. Boards approve it. Consultants recommend it. Executives announce it. And then, eighteen months later, the org chart looks remarkably similar to what it did before.

In practice, the “product model” label is often applied to structures that are still fundamentally functional at their core. What I typically observe on the ground:

  • Fractured ownership of the customer journey. A home loan application might touch originations, credit risk, operations, legal, and IT — each owned by a different team with different priorities and different definitions of “done.”
  • Layered approval chains. A change that should take a week requires sign-off from five committees — not because the risk warrants it, but because accountability is shared and no single team is confident enough to act alone.
  • Unclear accountability. When a customer complaint surfaces, the investigation reveals that everyone owns a piece of the process and nobody owns the outcome.
  • Cross-departmental dependencies as the default. Teams spend more time negotiating priorities with other teams than actually building or improving products.

A product model is defined by who is accountable — not by what the team is called. Renaming a functional silo a “product squad” does not change the incentives, the dependencies, or the decision-making dynamics. Real product ownership means a single team has the mandate, the capability, and the authority to deliver an outcome end to end.

What Fractured Structure Produces

Organisational friction does not stay contained within the org chart. It leaks into systems, processes, and ultimately into the customer experience. The consequences compound over time:

Symptom Root Cause Business Impact
Fragmented systems Each team builds its own solution High integration cost; data inconsistency
Duplicated capabilities No shared ownership of platforms Wasted investment; diverging roadmaps
Slow delivery Multi-team sign-off for every change Lost competitive advantage
Inconsistent customer experience No single owner of the journey Customer attrition; regulatory risk
Shadow IT Teams bypass slow central processes Security gaps; ungoverned data

The pattern is self-reinforcing. Fragmented teams build fragmented systems. Fragmented systems make it harder to reorganise teams. The longer this persists, the higher the cost of change — and the more tempting it becomes to frame it as a technology problem.

Conway’s Law Is Running Your Bank

In 1967, computer scientist Melvin Conway observed that organisations design systems that mirror their own communication structures. This principle — known as Conway’s Law — has since been validated repeatedly in software engineering research. It is also, quietly, one of the most consequential forces shaping banking technology today.

“Systems reflect how teams are structured. If ownership is split, systems will be split. If responsibilities overlap, systems will overlap.”

When a bank has three teams responsible for customer identity — one in retail, one in business banking, one in digital — it will eventually have three identity systems. Not because anyone chose to build three, but because the structure made it the path of least resistance.

The inverse is equally true. Teams that share a clear mandate tend to build coherent, reusable platforms. The architecture is a byproduct of how people are organised and incentivised.

This has a direct implication for transformation strategy: if you want to simplify your systems, you first need to simplify your structure. Attempting the reverse — redesigning the architecture while leaving the org intact — is an exercise in swimming against the current.

What Real Transformation Requires

Structural change is harder than technology change. It threatens established power bases, disrupts career paths, and requires leaders to relinquish control they have spent years accumulating. This is precisely why it is so rarely done well — and why so many transformation programmes default back to technology as the primary lever.

But the banks that have genuinely improved their speed, quality, and customer outcomes share a common set of structural characteristics:

  • Clear end-to-end ownership. A single team or leader is accountable for the full customer journey — not just their slice of it. This team has the authority to make trade-offs across the journey without escalating to a committee.
  • Fewer handoffs. Every handoff between teams is a potential failure point, a delay, and a place where accountability diffuses. High-performing banking organisations relentlessly reduce handoffs — not by working harder, but by consolidating ownership.
  • Aligned incentives. Teams measured on their own output will optimise for their own output. When incentives are aligned to shared outcomes — customer satisfaction, time-to-market, cost per transaction — behaviour changes naturally.
  • Accountability over hierarchy. The question is not “who is senior?” but “who is responsible?” Accountability should be explicit, named, and tied to outcomes rather than activities.

A useful diagnostic: ask ten people across the organisation who owns the end-to-end customer onboarding journey. If you get ten different answers — or ten variations of “it’s shared” — the structure has not yet changed, regardless of what the org chart says.

Technology Follows Structure

This is not an argument for delaying technology investment. Modern cloud infrastructure, AI-assisted decisioning, and API-first architecture genuinely expand what is possible. The argument is about sequencing and causality.

Technology is most powerful when it is deployed into an organisation that knows what it is trying to do, who is responsible for doing it, and how success will be measured. When technology is deployed into structural ambiguity, it amplifies the ambiguity — faster delivery of conflicting priorities, automated duplication of fragmented data, AI-assisted navigation of broken processes.

“Technology follows structure — not the other way around. The most dangerous belief in banking transformation is that the right platform will fix the wrong organisation.”

Before the next major technology programme, ask the structural questions first:

  • Who owns this capability end to end?
  • What happens when two teams disagree on direction?
  • How many approvals does a change require, and why?
  • Are the people making technical decisions the same people accountable for outcomes?

If those questions do not have clear, consistent answers, the technology investment will be constrained by the same structural friction it was meant to solve.

Closing Thought

The banks that will lead the next decade are not necessarily those with the newest technology stack. They are those that have done the harder work: clarifying who is responsible for what, aligning incentives to shared outcomes, and building structures that let talented people move fast without creating chaos for their colleagues.

Structure is not glamorous. It does not headline conference keynotes or generate analyst reports. But it is the substrate on which everything else is built — and until it is right, no amount of technology investment will deliver the transformation that banking organisations need.