Banks have spent a decade investing in delivery capability: more squads, more tooling, more agile ceremony. The returns have been real but uneven. Genuine, repeatable gains in customer experience, resilience and cost-to-serve remain out of reach for most..
The constraint is not delivery capacity. It is the model through which engineering work is funded, governed and sustained. When engineering is organised around projects, three things follow by design:
- Work is funded in fixed bursts, so investment in a platform stops the moment the initiative closes.
- Ownership is temporary, so the team that built a capability is gone before anyone fully learns how it behaves under load.
- Success is defined as scope shipped, not problems solved, so nobody is accountable for whether the work improved a business outcome.
The bank accumulates a portfolio of completed projects and, surprisingly, little durable capability to show for them.
This matters with new urgency because AI amplifies whatever operating model it enters. Deploying agents and AI tooling into project-centric delivery is not solving the problem. It is scaling it. An agent built for one initiative and retired when the team disbanded is not a capability. It is a new and more opaque form of technical debt. The operating model question and the AI adoption question are the same question.
Knowledge walks out the door
At Cognizant we see transformation programmes stall at a predictable point. Not when the technology fails, but when the two or three engineers who genuinely understand a critical platform leave. The reasoning behind the credit decisioning logic, the payments settlement rules, the fraud engine configuration exists nowhere searchable, versioned or audited. It lives in memory. When that memory walks out, the bank cannot reconstruct it quickly, cheaply or completely.
For a regulated institution this is more than a delivery risk. It is a governance risk. Under CPS230, demonstrating operational resilience depends on being able to evidence the control environment. Knowledge that cannot be audited cannot be governed — and no volume of retrospective documentation closes that gap after the fact.
Persistent, value stream aligned teams address this directly. When a team owns a platform continuously, knowledge accrues to the team rather than to individuals. A new member joining a Lending squad inherits the squad's accumulated understanding — not just the current state of the code. Governed agents extend this further: when document processing, policy validation and compliance monitoring are versioned and maintained on the product backlog, the logic they encode becomes inspectable in a way that tacit human knowledge can never be. This is what makes AI a governance asset rather than a governance liability.
Specialisation that compounds
The alternative to project delivery starts with a different question. Not “what must we deliver this quarter”, but “what outcomes need to be sustained, and what team structure best supports continuous improvement toward them”.
The answer is persistent, cross-functional teams aligned to specific products or customer journeys - for example, a Lending squad that owns origination, decisioning and servicing end-to-end, continuously, rather than for the life of a project. Domain expertise then deepens with each release cycle. Engineers who have carried a platform through multiple incidents understand its failure modes in ways no documentation can capture. Product owners who have navigated the same lending journey through successive regulatory changes develop an instinct for risk that no onboarding programme can manufacture on demand.
Westpac named this dynamic explicitly in its UNITE programme: a deliberate move away from a “deciduous” model of build, sweat the asset, then pay for a costly upgrade, toward “evergreen” platforms kept continuously current and supported by persistent teams.1 The pattern holds across high-performing institutions. Sustained ownership compounds. Repeated ownership resets do not.
Outcome accountability, not feature delivery
The sharpest difference between the two models is the definition of success. In a project model, success is scope delivered on time and on budget. In an outcome-owned model, success is a measurable improvement in a business problem the bank has committed to solving.
A persistent Lending squad is accountable for a small set of funding metrics: time to conditional approval, straight-through-processing rate, cost per funded loan, first-time approval rate. These are not reporting lines. They determine where investment continues, expands, or stops. A team that ships features but moves none of these numbers has not succeeded.
CBA's BizExpress platform illustrates what sustained ownership produces. By building and continuously improving a single lending capability, combining data assets, AI-driven credit assessment and digital origination, CBA now funds around two thirds of its small business lending through that one platform.2 That is not a project delivery statistic. It is the compounded result of years of continuous ownership aimed at one business outcome.
Governance in this model shifts from milestone tracking to outcome review. Executives assess progress against customer metrics and engineering health. Prioritisation becomes evidence-based: backlog decisions ranked on outcome impact, balancing features, technical debt, agent capability and regulatory obligations — without waiting for a stage gate.
Where it stalls
We should be direct about where these transformations fail, because it is rarely where banks expect.
Funding. The technology is not the hard part. Funding is. Most banks release capital to projects, not products. A persistent team cannot sustain continuous improvement when its funding resets with every initiative. The first conversation that needs to happen is not about squad design — it is between the CIO, CFO and business unit heads about whether the funding model can support the operating model.
Governance transition. The second failure mode is the handover of control. Persistent teams ask executives to give up the project milestone as their predictability mechanism before outcome-based measurement is mature enough to replace it. That gap, between the milestone you have relinquished and the outcomes you do not yet trust, is where most programmes stall. Holding the model steady while evidence accumulates takes senior sponsorship.
Neither is a reason to avoid the shift. They are the specific challenges that need to be named and managed, not assumed away.
The choice
The banks that move fastest treat operating model, measurement and delivery capability as one system. Persistent teams without outcome governance default back to milestone delivery. Outcome metrics without empowered teams become performance theatre. You need both, wired together.
The shift to value stream aligned, outcome-owned teams is ultimately a decision about what kind of engineering organisation a bank wants to be in five years: one that resets with every initiative, or one that compounds its expertise, retains its knowledge, and solves business problems with increasing precision and confidence.
With AI now multiplying the consequences of that choice, it is no longer a strategic aspiration. It is an operational necessity.
