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

In this second part of the series, we dive into the inner workings of each system, beginning with System 2: the enabler. From paved roads and embedded guardrails to developer experience and governance, we explore how System 2 creates the conditions for System 1 teams to thrive. We then turn our focus to System 1 itself: what autonomy really looks like in practice, how it’s earned, and how it accelerates delivery when properly supported.

System 1 & System 2: Two Engines, One Mission

In Part One, we introduced the System 1 & System 2 model, a dual-track approach that enables speed, autonomy, and better outcomes in banking delivery.

At Ikigai, we believe delivery excellence comes from clarity of purpose and separation of concerns. System 1 and System 2 teams play distinct but complementary roles and both are essential.

In this second part of the series, we’ll dive into: 

• The mission of System 2 teams: paving the road to System 1 to thrive. 
• We then turn our focus to System 1 itself: what autonomy really looks like in practice, how it’s earned, and how it accelerates delivery when properly supported.

System 2 as an enabler, not a bottleneck

As established in Part One, System 2 provides the critical scaffolding that empowers System 1 teams to succeed. These teams focus on building internal platforms, shared services, and robust guardrails that remove friction from product delivery. By investing in developer experience, platform reliability, and cross-cutting capabilities, System 2 creates the conditions for System 1 teams to deliver autonomously and at pace. Their role extends beyond infrastructure, they actively identify bottlenecks, reduce dependencies, and continuously improve the ecosystem in which product teams operate.

When speaking to Ikigai’s Product Leads, “System 2 handles foundational capabilities, which directly improves System 1’s delivery time.”. There is a direct correlation emphasing System 2’s important role in creating the base for efficient delivery. 

Paved Roads & Reusable Components 

A core function of System 2 is to remove the burden of building and maintaining the foundational scaffolding from System 1 teams. It “paves the road” by offering reliable, reusable building blocks that reduce cognitive load and operational friction. These include infrastructure, CI/CD pipelines, security guardrails, observability tooling, and service templates, all designed to accelerate delivery without compromising on quality or compliance.

As our Product lead states, “We can essentially add new System 1 teams and they can get up and running and be effective in basically no time at all. System 2 really creates that environment where we've been able to add new teams quickly and easily because of all the kind of great work that goes on in System 2.”

This sentiment was echoed by the engineering leads, describing how their enablement team created reusable CI pipeline components “Lego blocks”, that can be assembled and customised to fit the specific needs of a given team or project.

When these foundations are in place, product teams no longer have to reinvent the wheel. They can focus on delivering features that create value, confident that the underlying systems are secure, scalable, and built for continuous delivery from the outset.

Embedding Non-Functional Requirements

Non-functional requirements (NFRs) such as security, performance, compliance, auditability, and observability are often overlooked or deprioritised in favour of speed and feature delivery. But in the System 1 & System 2 model, they are treated as first-class citizens from the start.

System 2 plays a critical role in identifying, standardising, and embedding these cross-cutting concerns into the developer workflow, ensuring they are built into the delivery process rather than added on later. As one tech lead explained, “System 2’s primary benefit is in improving delivery lead time through automation, especially in regulated environments.” By proactively surfacing requirements from API standards to auditability, System 2 teams reduce the burden on System 1 teams and enhance developer confidence.

Another tech lead echoed this, advocating for well-documented requirements that reduce the need for constant back-and-forth. Clear, discoverable documentation; whether through formal channels or well-curated developer tools; gives teams confidence to move fast without compromising on quality or safety.

By embedding these non-functional requirements into the platform, System 2 ensures that all teams are operating within guardrails that support resilience and compliance by design. This reduces the likelihood of late-stage rework, avoids fragmentation across teams, and enables consistent, scalable growth.

In this way, NFRs (Non-Functional Requirements) become accelerators rather than blockers, deeply aligned with the core goal of the System 1 & System 2 model: empowering product teams to deliver outcomes quickly, safely, and sustainably.

Improving Developer Experience

A key measure of a high-functioning delivery environment is how well it supports its developers. In the System 1 & System 2 model, developer experience isn’t a luxury, it’s a strategic enabler of autonomy, speed, and quality.

System 2 teams are responsible for creating the environment in which developers can thrive. This includes intuitive tools, robust documentation, sensible defaults, and clear feedback loops, all of which reduce friction and cognitive load. 

When developers do not have to worry about configuring pipelines from scratch, chasing down compliance guidelines, or navigating unclear architecture decisions, they’re free to focus on what really matters: building meaningful customer outcomes. That’s where System 2 shines, by removing blockers before they arise and enabling a seamless experience from idea to production.

One of the tech leads we spoke to, highlighted the importance of self-service capabilities and well-documented, discoverable resources. Even informal channels like Slack, they argued, should ultimately direct developers to a single, trusted source of truth. This not only prevents duplication of effort but fosters confidence and consistency across teams.

Moreover, improving the developer experience is a flywheel. When platforms are intuitive and reliable, adoption increases. When adoption increases, so does feedback. And with feedback comes continuous improvement, a self-reinforcing loop at the heart of System 2 maturity.

Governance & Guardrails

System 2 doesn’t just provide tools or build infrastructure, it creates the conditions for teams to move fast without breaking things. Governance is embedded into the platform itself with security, compliance, and best practices built in as guardrails to guide teams without slowing them down.

As our Tech Lead explains, manual reviews are often needed early on to catch common issues, but the long-term goal is to automate these guardrails and “remove the manual gatekeeping over time.” This shift not only accelerates delivery but also improves consistency and reduces human error.

This approach was echoed by Ikigai’s leadership, noting that Ikigai automates standard changes while retaining manual reviews for cross-cutting or high-risk decisions, striking the balance between speed and oversight.

Ultimately, good governance isn’t about slowing things down. It’s about setting teams up to move quickly, safely, and with autonomy, a core tenet of the System 1 & System 2 model.

New Banks vs Core Modernisation

Reusable components, platforms, and automation are particularly impactful in greenfield initiatives such as new bank builds. With the opportunity to start from scratch, there’s a clean slate to define responsibilities clearly, design for decoupling from day one, and embed automation across the stack. As one tech lead noted, System 2 maturity, particularly around automation; can enable daily deployments of new services from early in a programme. This creates a strong foundation for delivery velocity, scalability, and resilience, while ensuring that non-functional requirements like security and observability aren’t treated as bolt-ons.

In contrast, modernising a legacy core is a more complex and delicate endeavour. Existing systems often come with deeply entangled architectures, limited automation, and tightly coupled infrastructure, all of which make rapid iteration and frequent releases difficult. As another tech lead explained, System 2’s role in these programmes often centres around enabling safe migration, whether through test harnesses, regulatory compliance tooling, or secure transitional environments. These capabilities help mitigate the inherent risks of modernising in-flight systems while maintaining business continuity.

Ikigai leadership states the key difference: “New bank builds start from scratch with fully decoupled systems, whereas core modernisation often involves integrating with existing, potentially legacy, system 2 components.” In such contexts, System 2 must work harder to balance innovation with stability, gradually building the platform capabilities that allow System 1 teams to break free from legacy constraints.

Ultimately, the principles of the System 1 & System 2 model hold true in both contexts. But the execution must be tailored to the level of technical debt, regulatory pressure, and organisational readiness that each scenario presents.

System 1 autonomy

As we explored in the previous section, a significant part of System 2’s mission is to create the conditions for System 1 teams to thrive. By investing in platforms, shared services, and embedded guardrails, System 2 enables System 1 teams to remain laser-focused on building high-quality, customer-facing banking services. These product teams are empowered to take ownership of the entire delivery lifecycle from shaping the roadmap to deploying and running their services and, crucially, to own the outcomes.

Autonomy is one of the most powerful outcomes of a well-structured System 1 & System 2 model. It enables teams to focus on delivering real value rather than managing dependencies. But autonomy doesn’t mean isolation. It’s about empowering teams to take full ownership of their mission, make local decisions, and ship independently without constant handoffs, approval chains, or bottlenecks. 

The shift from project-based teams to product-led teams has been instrumental in reinforcing a customer-centric mindset. This model brings sustained ownership, clearer accountability, and a sharper focus on delivering outcomes that matter. As a product lead explained, “the introduction of product managers naturally redirected attention toward customer needs, reinforcing and operationalising customer-centric principles across teams”. This clarity helps prioritise what truly matters, avoids unnecessary complexity, and ensures that System 2 teams are more attuned to their internal customers; the System 1 teams they support. This renewed focus on ownership and alignment naturally creates the conditions for autonomy. They’re not held back by duplication of effort or dependency chains because the right tooling, patterns, and capabilities are already in place.

That said, achieving this kind of autonomy isn’t without challenges. At the start of a programme, teams might find themselves straddling both systems especially when resourcing is limited or maturity is still developing. As we heard from our engineering leads, some teams start off as “reluctant System 1” teams, pulled into delivery before the supporting platform is ready. In these cases, autonomy is not yet feasible and expecting it prematurely can create confusion and burnout. That’s precisely where a clear decoupling strategy becomes critical. 

As noted earlier, fostering autonomy extends beyond the provision of tools; it requires deliberate design, clearly defined roles, and appropriate support structures to enable teams to mature into independence. Furthermore, based on our experience at Ikigai, our squads employ battle tested accelerators, utilised by both our System 1 and System 2 teams, to effectively initiate programmes and mitigate early stage challenges.

True autonomy is a balance: independence without fragmentation, speed without recklessness, and ownership without isolation. It’s what turns teams into trusted engines of change and what makes the System 1 & System 2 model sustainable at scale. When autonomy is in place, it transforms delivery, shaping how teams prioritise, collaborate, and deliver value at pace.

Summary 

The System 1 & System 2 model isn’t just a re-org, a tooling initiative, or a mindset shift, it’s all of those things working together, in service of better delivery. As we've seen in this instalment, System 2’s mission is to build the scaffolding that allows System 1 teams to move with speed and confidence. When both systems are working in sync, autonomy becomes scalable and delivery becomes dependable.

In the final part of this series, we’ll explore how this model impacts delivery outcomes in practice. We’ll look at the mindset shift required across both systems, the critical importance of communication and collaboration, and how this model can evolve. It’s here that the real transformation happens, not just in what we deliver, but in how we think, work, and grow together.

‍