← Portfolio

Shawbrook BankDiagnosing structural misalignment, designing an incentive-driven shared services model, and the gap between product-led ambition and organisational reality

A bank organised into independent verticals was duplicating solutions and fragmenting its technology, while aspiring to operate as an integrated product-led organisation. I diagnosed this as a structural problem and proposed a shared services model designed around natural incentives: business verticals would retain full autonomy, but shared capabilities would be free to consume, creating a free market inside the organisation where adoption had to be earned through quality and relevance.

The proposal was respected but deferred in favour of project-based consolidation. This is the story of the diagnosis, the design, and what followed.

1. The Problem

Shawbrook Bank, like many traditional banks, was organised into independent business verticals (Mortgages, Asset Finance, Savings, and others). This separation was originally deliberate: keeping each business unit structurally independent preserved the flexibility to divest individual verticals as needed. Over time, the bank’s strategic direction shifted towards closer integration across the group, but the organisational structure remained in place. Each vertical had its own leadership, commercial goals, technology stack, and product managers. These product managers were measured on delivery within their own vertical, under tight deadlines, with limited visibility into what other parts of the bank were building.

The result was predictable: duplicated solutions, fragmented technology, and no mechanism for reuse. If one vertical built functionality to retrieve credit bureau data, another vertical would build their own version independently.

At the same time, the organisation was championing a product-led vision from the top down, with genuine commitment from senior leadership including the CEO. But the underlying structure contradicted that ambition. Individual PMs had no structural permission to think beyond their vertical. There was no incentive to do so, no capacity for it, and no framework to support it.

The organisation wanted cultural change without organisational change. That is a contradiction.

2. The Diagnosis

I joined Shawbrook in a cross-functional capacity, with visibility across the bank rather than within any single vertical. In an organisation where every other product manager was embedded in one business unit, this was an unusual vantage point.

The PMs were talented and motivated, and the organisation had clear ambitions for how it wanted to operate. The incentive structure, though, pulled in a different direction. The more I looked at the pattern across verticals, the more it pointed to something structural: the organisation made cross-bank thinking an irrational use of time for anyone measured on vertical delivery. It was a problem of organisational architecture.

“His role gave him responsibility and visibility across multiple parts of the organisation, rather than sitting within a single product or business unit. This allowed Steven to take a cross-bank perspective, helping surface challenges that cut across teams and domains, and contributing thoughtful perspectives on shared services and organisational structure.”

Michael Bocking · Product Manager, Shawbrook Bank

I talked openly with product managers across the verticals, listening to how they experienced the organisation and sharing early ideas as they developed. Their perspective shaped what eventually became the proposal.

The bank’s stated direction was product-led, and the PMs wanted to operate that way. But their objectives, timelines, and accountability were all scoped to their own vertical, and in some cases business leaders within a vertical would define the solution they wanted, making the PM’s role one of coordination and delivery.

3. The Proposal

The proposal was designed around the existing culture, introducing a structure that would generate natural incentives for the outcomes the organisation was already working towards.

I proposed introducing a shared services (or platform) capability alongside the existing structure. The verticals would remain intact, every existing product manager would stay in place, and every business unit would retain full autonomy.

The shared team would be responsible for building and maintaining shared services. Decisions about where a given initiative belonged (within a vertical, as a shared capability, or both given specific constraints) would be made collaboratively, with any product manager able to participate on a rotating basis. This kept vertical expertise at the centre of cross-bank decisions, while giving PMs direct exposure to the broader picture.

The starting point would be a single customer view: a capability every vertical needed and a strong candidate for proving the model.

The most important design principle was voluntary adoption. Top-down mechanisms can be wrong, and no one should force a solution on a business that knows its own needs best. But bottom-up teams, while closest to their own business, need a reason to change. The proposal addressed both sides.

Every business unit retained full autonomy: they could build their own solution, work with a vendor, or disregard the shared capability entirely. But the funding model created a natural incentive. Business verticals paid for their own solutions, while shared services would be free to consume.

4. The Incentive Model

This created a free market inside the organisation. Internal departments became, in effect, customers of the shared team, with the same freedom to walk away. The shared team could not force adoption. They had a cost advantage over external competitors and vertical-specific builds, but that alone would not be enough for an autonomous business vertical to change their approach. Verticals would only switch if the solution met their needs.

This placed genuine accountability on the shared team. Their success would depend on building things that people chose to use, earning adoption the same way an external provider would.

This design also respected what was already working. The existing business units were performing well, and the structure preserved that. The goal was to create a better path alongside them. As shared capabilities earned adoption by meeting real vertical needs, cross-bank functionality would gradually accumulate, and with it, a culture of thinking beyond the individual business unit.

5. What Happened

The proposal was not taken forward. The Chief Product Officer’s view was that the product function had not yet earned the credibility within the bank to drive a change as broad as organisational architecture. The team needed to demonstrate delivery capability on specific initiatives first. This was a judgement about timing and trust, with the model itself respected.

The bank addressed fragmentation through time-bound projects instead: consolidating specific systems, replacing duplicated platforms, and delivering defined commercial outcomes. It was a more controlled, more familiar approach, and it addressed real technical debt and delivered commercial value.

Despite proposing a different long-term approach, I was fully committed to the chosen direction. I joined the core banking initiative and contributed to the work that followed.

“He was an advocate of building standard platforms which we could build our products on, to increase reuse and speed up feature development, and we successfully worked together to promote that approach more widely.”

Steve Gardner · Director of Engineering, Shawbrook Bank

6. What I Observed

Working on the project-based approach first hand, I saw it reduce technical fragmentation. It also brought people from different verticals together around shared problems, consolidating customer accounts across multiple systems into a single source of truth. That created real cross-bank conversation and thinking, within the scope of the project.

The two approaches were complementary. The project-based work consolidated systems and delivered commercial value. The organisational model would have made that kind of cross-bank collaboration structural, extending it beyond individual projects and into how product decisions were framed day to day.

Solution architecture addresses how the organisation solves problems today. Organisational architecture determines how it will solve problems in the future.

7. What I Would Refine

If I were to propose this again, I would start with a single pilot capability, demonstrate value within one or two verticals, and let the structural argument emerge from evidence.

The concept was sound. Presenting the evidence before the full model would have let the work speak for itself. That is the lesson I would carry forward.

“He’s a person with an open, analytical mind, who understands the realities of software development well. Thanks to his [insight, he] identifies potential risks and bottlenecks in the solution.”

Bartosz Maciag · Solution Architect, Shawbrook Bank