By Matt Kearney, Head of Consulting, Insurance, Pensions & Investments, NTT DATA UK&I
New teams and Agile ways of working can improve ownership. But financial services firms will struggle to respond faster to customers and regulators while critical changes remain caught in the same technical bottlenecks.
When a bank cannot implement a regulatory change quickly, the consequence is rarely confined to its technology department. Delayed fixes can prolong manual work, raise operating costs and leave customers waiting for better services. An insurer unable to adapt a product or amend a claims process faces similar pressures. These are business problems, even when the immediate cause is a release window, an integration or an ageing core system.
Financial services firms have spent years investing in new ways of working, from Agile delivery methods to product-led operating models. McKinsey identified banks and other financial institutions as early adopters of Agile. Its research also found an association between Agile adoption and stronger financial performance, with organisations that had fully or partially adopted Agile operating models reporting better results than their peers.
Agile and product-led approaches can improve collaboration, decision-making and accountability. However, as explored in NTT DATA’s white paper, The Platform Model Paradox, reorganising teams around modern ways of working without addressing the underlying technology risks undermining the benefits of transformation.
Measure the time that matters
Transformation programmes often celebrate the number of product squads established or improvements in sprint velocity. These measures can be useful inside a team, but they say little about when a customer, adviser or employee actually benefits. The more revealing measure is elapsed time from an agreed business need to a working change in production.
Follow that journey and count the waits: shared platform dependencies, unresolved data issues, supplier hand-offs and restricted deployment windows. The delays between teams can outweigh the time spent building the feature.
Speed alone is an incomplete goal in a regulated business. Leaders should look at delivery time alongside failed changes, rework, service disruption and customer impact. The test is whether the firm can put an important change live sooner without making the operation less stable. A quicker release that increases incidents or creates remediation work is no improvement.
The constraints sit beyond the product team
A product teams may be accountable for improving customer journeys without having the authority to resolve the shared technology and operational dependencies holding them back.
This is an enterprise leadership and investment issue. Technology, operations, risk and business leaders need a shared view of the constraints affecting the most important customer journeys. An executive sponsor should own the end-to-end outcome, with named owners and funded plans for the shared platforms and controls that individual product teams cannot change. Otherwise, each team is left negotiating the same bottlenecks separately.
Data quality is another consideration. Rather than launching broad transformation programmes, firms should prioritise fixing the specific data hand-offs delaying delivery.
Modernise the bottlenecks, not everything
None of this means every legacy system should be replaced. Many core platforms are dependable at the jobs they were designed to do. The question is whether their dependencies make necessary change disproportionately slow, costly or risky. Firms should prioritise the systems and interfaces that repeatedly hold up high-value customer journeys, regulatory responses and product updates.
Sometimes the right step is to decouple a particular service, improve an integration or make a shared capability reusable. APIs, modular services and better access to trusted data can help teams work more independently. But a modern interface cannot remove every limitation of the system behind it. If a transaction still relies on overnight processing or a quarterly core release, wrapping it in an API does not make that underlying change instantaneous.
Controls should be redesigned alongside the technology. Automated testing, clearer evidence trails and security checks built into the delivery process can reduce avoidable queues while preserving oversight. The aim is to make safe changes easier to deliver, with the right scrutiny applied throughout rather than accumulated at the final approval gate.
A better test of transformation
Operating model reform and targeted technical modernisation need to be planned and funded together. Product teams can clarify priorities and ownership, but enterprise leaders must tackle the shared dependencies that prevent those teams from delivering. Progress becomes visible when waiting times fall, releases become more dependable and improvements reach customers and colleagues sooner.
This also requires a change in how transformation success is judged. A new operating model may improve collaboration and accountability, but those benefits should ultimately translate into better business outcomes. For financial services firms, that means responding more quickly to regulatory requirements, adapting products to changing customer needs and reducing the cost and complexity of delivering change.
When assessing whether investment in a new operating model has delivered meaningful results, the question for the board is straightforward: can the firm take an important idea, regulatory requirement or customer improvement into production materially faster than before, without increasing failure, customer harm or operational risk?
