Banking at scale: a blueprint for delivery transformation using Team Topologies
Photo by Tima Miroshnichenko from Pexels: https://www.pexels.com/photo/a-person-working-on-a-project-6614837/
Key Takeaways
Peer proof beats methodology: One internal team successfully doing the work is worth ten framework presentations. Internal proof unlocks leadership confidence.
Break the business-IT wall structurally: Place Customer Journey Experts and Product Owners (POs) directly inside squads based on their strengths. Outcome ownership matters far more than their original place on the org chart.
Backlog structure is a thinking problem, not a tooling one: While digital task boards helped, the real shift was cultural. POs had to learn the difficult skill of splitting complex features into independently releasable increments.
Governance is not the enemy of autonomy: By introducing QBRs and transparent dashboards, we made autonomous teams safe for leadership to trust.
Geography is secondary when teams share backlogs and goals: Operating across four countries wasn't a barrier once we aligned everyone to one shared backlog and outcome.
Overview
In 2022, I was part of a transformation team at a large European bank. We were mid-flight in a massive digital transformation, operating with distributed teams across four countries and five tribes. The core question we faced was daunting: what happens when a waterfall organisation is handed a framework almost nobody had heard of?
The prior context: a fractured foundation
At the time, our context was highly disjointed. We were trapped in a duality of project-based teams—where engineers were hired for a specific approved project and immediately disbanded upon completion—and siloed business functions strictly divided by capabilities like Dev, QA, Business Analysis, and Operations.
While we had nominally created "squads" for agile delivery, they were falling apart. The reality on the ground was chaotic. We suffered from unversioned Excel spreadsheets serving as backlogs, owned individually by team leads without any shared visibility. Feature Engineers were expected to act as Product Owners but were given no real mandate or authority. Furthermore, our offshore engineers were often on fixed-price contracts—assembled for a quick build and then gone. Quality was supposedly everyone's responsibility, which meant it was actually no one's. With releases coordinated centrally and without Product Owner involvement, decisions completely lacked business context and became incredibly coordination-heavy. There was simply no flow.
Ethnic day on campus with the customer teams - photo from Rachana Pujar
Techies in my team - photo from Rachana Pujar
The techniques used: leading with Team Topologies
To overhaul this, we knew we had to start with leadership, not with the teams. In 2022, Team Topologies was a nascent concept globally with no large bank playbook available. Initiated by our CTO, we heavily coached our IT Area Leads on four core principles from Team Topologies: reducing handoffs, accelerating flow, limiting cognitive load, and aligning with Conway's Law.
The hardest battle was shifting mindsets from project-based to product- and outcome-based delivery, as corporate budgets and career paths were firmly wired to projects. To restructure, we adopted a topology-aligned model:
Stream-aligned teams (delivery squads): These became business and IT co-owned units. They featured lean core engineers, a Product Owner, and 2-3 Customer Journey Experts (CJEs) from the business side, supported by embedded offshore engineers and quality assurance engineer. They shared one backlog and one goal.
Platforms: We centralized our Chapter Leads for Java, Azure, .Net, and Cloud here to own DevOps and test automation capabilities.
Enabling teams: Roles like Agile Coaches, Project Managers, and Change Execution professionals (like myself) were reframed from process controllers into accelerators.
To prove this model, we launched a pilot that was not a single squad, but a massive cross-tribe initiative for a new lending product cutting across four tribes simultaneously. If the topology held under real cross-tribe dependency pressure, it would hold anywhere.
Image by Rachana Pujar
We replaced the chaotic Excel sheets with Azure Boards, establishing a strict work item hierarchy: Epic, Feature, User Story, and Task. To govern this safely, we instituted Quarterly Business Reviews (QBRs), live dependency trackers, and weekly squad health dashboards. We mandated a 15-day release cycle, embedded one QA engineer per squad, and strictly reserved 10% of every sprint capacity for technical debt. We didn't just run workshops and leave; we embedded ourselves inside sprint planning, daily standups, and retrospectives.
The results and ROI: business and IT alignment
When structure changes, outcomes follow. By bringing business and IT into co-owned squads, the wall between the two stopped making sense. Business KPIs became visible to delivery teams, and delivery metrics became visible to business leads. For the first time, both sides were reading from the same page.
Recreation of tribe and squad dashboards using non-live data - Image by Rachana Pujar
The ROI was substantial. On the IT side, DORA metrics improved significantly: cycle time reduced, deployment frequency increased, lead time for changes fell, and change failure rates decreased. Unpredictable project bursts were replaced by consistent sprint delivery, and automated flows replaced manual interventions.
This directly accelerated business impact. We saw:
customer acquisition growth increase
new business growth increase
conversion rates increase
Loan Origination cycle times dramatically reduce
Loan approval rates, NPS, and CSAT all moved positively, proving that time-to-market had shortened across all tribes.
Personal reflection
Reflecting on this journey, I've realised that you don't need a massive team to drive transformation; you just need the right mix of perspectives across technology, ways of working, and change execution. You have to be willing to start before you fully understand it, prioritising flow over handoffs and outcomes over projects.
Above all, Team Topologies is not a destination. Team Topologies is a lens that forces you to constantly ask: does our structure enable flow, or obstruct it? By changing the conversation before the org chart, we allowed a sustainable, high-performing structure to follow naturally.
About the author:
Rachana Pujar, Enterprise AI & Transformation Consultant
Rachana Pujar is an independent Enterprise AI & Transformation Consultant with 16+ years of hands-on experience leading delivery transformation, Agile operating model change and GenAI programme delivery for enterprise clients across banking, insurance, AgriTech and public transport sectors globally.
Read more on Team Topologies
