At our recent EngineeringX dinner in London, the platform engineering team from a major financial institution shared how they're modernising software delivery at massive scale. Tens of millions of customers, 24/7 operations, heavy regulation. Their openness about what worked and what didn't set the tone for the whole evening.

The core argument they made early on: engineering transformation at scale isn't a technology problem. It's a complexity problem. Decades of accumulated tech, thousands of applications, regulatory demands at every step, and a talent equation that makes it all harder. Attracting and retaining good engineers means giving them an environment where they're not fighting tooling all day.

Measuring Success Across Three Dimensions

Our guest presenters shared a scorecard they use to track progress across three areas:

• Customer outcomes. Better features, fewer outages, and the ability to deploy so confidently that releasing software becomes unremarkable. That's what "instant change" actually means. Not reckless speed. Boring, reliable releases.
• Developer experience. Less context switching, less cognitive load, and a deliberate effort to eliminate technical debt across processes, tooling, and architecture. They used the phrase "engineering quality of life," and everyone knew exactly what they meant.
• Controls and governance. The principle that got the strongest reaction: make it easy to do the right things, and hard to do the wrong things.

Too many organisations only optimise for delivery velocity. Defining success across all three dimensions is what separates real progress from optimising in the wrong direction.

Software Delivery Is 30+ Workflows

One of the standout moments was a slide mapping out more than 30 distinct workflows in modern software delivery. Testing alone covers unit, integration, functional, API, load, and resiliency. Security includes code scanning, open-source dependencies, compliance enforcement, supply chain, and AI vulnerability scanning. Deployment spans code, infrastructure, databases, feature experiments, verification, and rollback.

The point was to make visible what most organisations manage inconsistently, in fragments, with different tools and processes across multiple teams.

The table discussions kept surfacing the same pattern: engineering teams fix the pipeline, only to find the real bottleneck was somewhere else. A manual approval gate. A test environment that didn't match production. A change management process designed for quarterly releases.

The presenters described their own starting point: governance was manual and script-based, advanced deployment strategies didn't exist, feature flags weren't integrated with the pipeline, and change management needed custom scripting for every integration. Engineers spent their time fighting tooling instead of writing code.

If delivery feels slow and fragile, the answer is almost always spread across dozens of workflows, each with its own gaps. You have to map the whole system to fix it.

What Their Golde Path Looks Like

The team walked through their target delivery pipeline: continuous integration through zero-trust validation, pre-flight checks, deployment and verification, governance and risk controls, then a release and feature toggle that decouples deployments from customer exposure.

A few areas generated the most discussion during the evening:

• Policy-as-code. Instead of manual approval gates (which are slow, inconsistent, and leave unreliable audit trails), an automated policy engine makes governance decisions based on evidence gathered throughout the pipeline. The result is instant approval by evidence-based policy. Faster, more consistent, and more auditable than having a human in the loop.
• Progressive deployment and feature flags. Decoupling the act of deploying code from releasing it to customers. This shifts risk management from a binary "ship or don't ship" to controlled exposure, where issues get caught before they reach everyone.
• Shifting left on quality and security. Embedding testing, scanning, and compliance checks as close to the developer as possible. Giving them the right data to make informed decisions that prevent problems further down the delivery process.

The question that came up at several tables: how many organisations are still treating deployment as a high-stakes, irreversible act when the tools to make it low-risk and reversible already exist?

The Numbers

Our presenters shared the metrics anchoring their transformation:

• 88% improvement in lead time to deploy, from 76 days down to under 8
• 80% faster mean time to recovery
• 80% reduction in failed releases
• ~40% reduction in engineering toil

These metrics map directly to their three-dimensional scorecard: better outcomes for customers, better experience for developers, more efficient controls.

Most organisations still measure what's easy to count rather than what matters. Shifting from activity metrics (deployments per day, story points) to outcome metrics is a cultural change, not just a tooling one.

Technology Isn't the Hard Part

The section that got the most discussion was about people and process. Three challenges resonated:

• Battling inertia. Old habits and risk tolerances built up over years of working a certain way. It's not laziness. Those decisions made sense at the time. Overcoming inertia means sustained leadership attention and making the new way of working the path of least resistance.
• The "not built here" instinct. Teams tend to distrust solutions they didn't design themselves and reach for custom alternatives even when proven options exist. The fix: prove value quickly with pathfinder applications, and build internal advocates who spread adoption from within.
• Structured enablement. The team described a layered approach: instructor-led training, internal roadshows, self-paced learning, an automated onboarding portal, and a train-the-trainers model. All of it backed by executive sponsorship and a group-wide mandate. This kind of transformation doesn't happen by accident.

The organisations making the most progress are investing as heavily in change management and people development as they are in platforms and pipelines. The technology, in many ways, is the easier problem.

From Conversation to Action

Overall, it was a wonderful evening with guests enjoying spectacular views of the London skyline. The roundtable discussions reinforced a few things. "Instant change" isn't aspirational. It's achievable when the right architecture, governance model, and culture are in place. The complexity of software delivery is worth mapping and managing rather than ignoring. And the hardest part of engineering transformation isn't the technology. It's the sustained work of changing how organisations think and operate.