Rethinking Delivery for Outcomes: Inside the System 1 & System 2 Model - Part One

Why do banks still struggle to deliver at speed? At Ikigai, we help them unlock speed and autonomy without losing control.

As our CEO, Andy Farmer, notes:

“The biggest challenges I’ve seen don’t come from deciding whether to apply for a licence, they come from moving from strategy to execution. Many brilliant ideas never make it through this gap. Building a bank is unlike anything else in financial services. Most people are used to optimising what exists. But creating something entirely new, with no policies, no processes, no blueprint, is an entirely different challenge.”

Andy highlights a reality that many transformation leaders underestimate:

• Underestimating the build: Too many teams misjudge what it takes to build a bank from scratch and lack the experience to do it.
  
  
• Optimisers vs. creators: Financial services talent is often skilled in transforming existing systems, not designing something from the ground up.
  
  
• Two systems, two realities:
  
  
  • System 1: How customers experience the bank; fast, reliable, secure delivery of software into their hands.
    
    
  • System 2: How teams are organised; culture, leadership, mindset, and purpose. Often, this is the harder challenge.
    

• Vision is nothing without execution: However radical the vision for System 1, it’s System 2 that makes it real.
  

In Part One, we’ll cover:

• What System 1 & System 2 thinking looks like in banking delivery
  
  
• Why mindset and structure must evolve together
  
  
• How decoupling teams creates focus, speed, and flow
  

Let’s dive in.

Understanding the System 1 & System 2 model 

Traditional banking cores are notoriously inflexible, expensive to maintain, and slow to adapt to evolving customer expectations and regulatory requirements. In today’s digital economy, these legacy systems are more than just a technical burden, they actively obstruct innovation, delay time-to-market, and introduce operational risk.

Whether building from the ground up or modernising an existing system, banks need platforms that are agile, scalable, and aligned to customer value. But modernisation at this scale is rarely straightforward.

At Ikigai Digital, we recognise that core modernisation is a complex journey, but it’s also an unparalleled opportunity, one that requires early wins, careful risk management, and a focus on building lasting internal capability.

To support this, we’ve developed a dual-track operating model that reimagines how banks structure, deliver, and scale modernisation. This approach, grounded in delivery realities and mindset shifts, is what we call the System 1 & System 2 model.

This model shifts the centre of gravity from dependency management to true autonomy, where teams own outcomes end-to-end and are accountable for delivering real customer value. Excellence and compliance aren’t bolted on at the finish line but are embedded in everyday practices, shaping how work gets done. 

In addition, by moving away from project deadlines and towards continuous product evolution, the organisation can unlock a culture of iteration, learning, and improvement. The result is a living delivery system one and system 2 that adapts, self-improves, and fuels both innovation and resilience, while making the developer experience more rewarding.

The model is underpinned by two types of teams: System 1 and System 2.

‍System 1 teams are customer-facing product teams, fully accountable for delivering business outcomes with speed and quality. Their focus is on building features and experiences that directly impact the customer, typically external customers. However, the term “customer” can also refer to internal stakeholders. System 1 responsibilities can include delivering for internal customers such as audit, finance or regulatory teams.

System 2 teams are enablement teams. These teams deliver business outcomes such as safe operation for their customers (which happens to be internal customers i.e. other teams in the company). They build the platforms, guardrails, and internal tooling that allow System 1 teams to operate safely, autonomously, and at scale. These teams include but are not restricted to DevOps, infrastructure, platform and security specialists, all working to ensure delivery teams aren’t slowed down by foundational concerns. System 2 encompasses the tooling, platform, and scaffolding that empower System 1.

This separation of responsibilities enables faster, more predictable delivery by creating clarity around ownership while still promoting close collaboration between systems.

That said, in practice, the boundaries between System 1 and System 2 can sometimes be fluid, particularly in early-stage projects or when teams are still maturing. Depending on resourcing, context, or delivery constraints, a team may temporarily take on responsibilities from both systems or sit in between. 

This is where a decoupling strategy becomes essential, a conscious effort to separate concerns while maintaining alignment. Let’s take a closer look at how this plays out.

Decoupling strategy 

For System 1 teams to move quickly and autonomously, they need to be decoupled from the underlying platform and infrastructure. Decoupling isn’t just a technical decision, it’s a strategic one that enables speed, resilience, and clarity of ownership.

Building Self-Sufficient Teams Around Clear Missions

Effective decoupling doesn’t happen by accident. It requires a deliberate, intentional approach. At the heart of this approach is structuring autonomous, cross-functional teams around clear missions. Self-sufficiency within teams is more critical than a specific system.

Self-sufficient teams are the backbone of the System 1 & System 2 model. In the context of System 1, autonomy allows teams to focus relentlessly on delivering outcomes. For System 2, it means building reusable foundations which actively serves the needs for system 1, that does not require constant hand-holding or bespoke intervention. This separation of concerns not only accelerates delivery but also enhances accountability. Each team owns its mission, its progress, and its impact. 

When teams operate with autonomy, coordination shifts from dependency management to alignment on shared outcomes. Clear boundaries of responsibility that are defined early and revisited as teams evolve are critical for sustaining this autonomy. Decoupling needs to be explicitly called out, especially when resourcing or delivery constraints blur the lines between teams. Clear ownership is critical: if a team builds a service or capability, they are accountable for running and supporting it. This ‘you build it, you run it’ mindset ensures accountability doesn’t get diluted across teams.

Independence Requires Interdependence

There’s also a dynamic interplay between independence and dependence within this model. While teams are structured to operate independently, they remain interdependent, each relying on the others to deliver on their part of the puzzle. 

The Key Distinction: Execution vs. Purpose

Decoupled in Execution (The "How")

This refers to the ability of a team to perform its daily work, make decisions, and deliver value without being blocked by or needing constant coordination with another team. It's about operational independence and autonomy. Think of it as teams working in parallel on different parts of a machine.

Interdependent in Purpose (The "What" & "Why")

This means the ultimate success of the teams' collective effort relies on their individual outputs integrating successfully to achieve a larger, shared goal. The value they create is linked. The different parts of the machine they build must fit together perfectly for it to work.

From a product management perspective System one largely operates independently of system two, allowing them to focus on customer needs. However, System two's evolution requires system one teams to adapt to new security and platform requirements.

This mutual awareness is central to the decoupling strategy. It’s about reducing cognitive load by identifying shared requirements early and investing in enablement capabilities that abstract away complexity, enabling teams to move faster without compromising on quality or safety.

Embracing Early-Stage Realities

Approaching this from a technical lens, successful decoupling often begins with “dogfooding”, (i.e. dogfooding refers to the practice where the team building a platform or service also uses it to ensure it's practical, validated, and grounded before being released to other teams). This ensures the platform is grounded in real needs and validated through practical use before decoupling and handing it over to other teams. It also reflects the realities of early-stage delivery, where clear separation between System 1 and System 2 isn’t always feasible. In practice, teams sometimes find themselves operating somewhere in between or temporarily taking on responsibilities outside their intended scope due to constraints like limited resourcing or varying levels of team maturity.

Recognising and planning for this fluidity helps organisations stay on track while still building towards a more sustainable and scalable model.

The Payoff

Done well, decoupling creates the conditions for System 1 teams to focus on delivering value while System 2 teams build the foundations that make that delivery sustainable, enabling pace without chaos, and autonomy without isolation.

In part two of this series, we’ll dive into the heart of both systems: exploring the distinct roles System 1 and System 2 teams play, and how they work together to deliver outcomes with speed, safety, and confidence. Stay tuned.

‍

‍