Why Financial Services Firms Are Replacing DevOps Teams With Platform Engineering

In most regulated banks I work with, the DevOps team has become the thing DevOps was supposed to abolish.

This is not a slogan. It is a structural observation. The idea behind DevOps, twenty years ago, was that the wall between developers and operators was the bottleneck, and removing it would let software flow. The wall did come down. What rebuilt itself, slowly and almost unnoticed, was a different bottleneck — a small central team that ended up owning every cluster, every pipeline, every IAM role, every environment, every approval. The wall did not go away. It moved, and it acquired a Jira queue.

Platform engineering is not a rebranding of DevOps. It is the recognition that the original arrangement broke under load, and that what regulated organisations actually need is a different shape entirely.

The shape DevOps actually produced

The early version of DevOps was a cultural argument. Developers and operators should work as one team. The toolchain should be unified. The deployment pipeline should be automated. The operational concerns should shift left into the developer's day. None of this was wrong. Most of it was useful.

The problem was that "shift left" did not scale into a regulated bank the way the original proponents imagined. It scaled into something else. The developers acquired a long tail of operational responsibility — Terraform, IAM, observability stacks, security tooling, secrets management, compliance scripts — that they had neither the time nor the appetite to own. The operators acquired a long tail of platform responsibility that nobody was funding as a platform. The middle, the place where developers and operators were meant to converge, filled up with brittle bash, half-documented runbooks, and people-as-load-balancers.

What I see now, in most banks, is a development organisation where a non-trivial fraction of every engineer's day goes into something that is technically beneath the work they were hired to do. The number I hear quoted is roughly a third. That is one engineer-day in three spent on infrastructure plumbing the engineer does not enjoy, does not specialise in, and was not supposed to be doing.

The other side of this is even worse. The small central team that ended up notionally owning the platform — sometimes called DevOps, sometimes SRE, sometimes Cloud Engineering — is operating reactively. It is fielding tickets. It is unblocking builds. It is approving security exceptions one at a time. It is not building anything. It has the title platform without the practice of platform.

This is the arrangement that broke. The cultural idea of DevOps survived. The operational implementation of it, in any organisation past a certain size and regulatory weight, did not.

What platform engineering is actually doing

Platform engineering names something different. The central team stops being a ticket queue and starts being a product team. The product is the internal developer platform. The customers are the application engineers. The success metric is whether the customer can ship without filing a ticket.

The substantive change is that the platform's surface becomes a product surface, not a tooling stack. The application engineer interacts with an API or a CLI or a portal that knows what their team is allowed to do, applies the appropriate guardrails automatically, and produces the right artefacts for audit. The application engineer is not configuring Kubernetes by hand. The platform engineer is not approving the application engineer's request to use Kubernetes. The configuration is encoded in the platform; the request is implicit in the engineer's action; the approval is the platform's policy, evaluated at runtime.

This is a different organisational shape. It has implications most banks have not yet processed.

The platform team has to be funded as a product team. It needs a roadmap, a sponsor, a metric for adoption, a discipline of usability. The metric "uptime of the platform" is necessary but insufficient — the metric that matters is "fraction of application teams that can complete a typical change without speaking to the platform team." If the platform team is still being called for every change, the platform is not a product. It is a service desk in costume.

The compliance and risk functions have to be willing to encode policy in the platform rather than enforce it through review. This is the move that takes longest, because it requires the risk function to trust that the platform is doing what the review was doing. The risk function is right to be cautious here. The platform team is right to push for the encoded version. The path through this tension is a slow, evidence-based conversation, and it is the single biggest determinant of whether the platform succeeds or not.

The application engineers have to give up the autonomy to choose their own toolchain. This is harder than it sounds in an organisation that has spent a decade telling engineers that autonomy is good. The shape that works is "the platform constrains the choices, and within those constraints the engineer is fully autonomous." Most engineers, in my experience, end up preferring this once they have lived inside it. The cost they pay in flexibility is more than compensated by the cost they no longer pay in plumbing.

What I see when the transition works

The clearest example I have of this transition was at a UK challenger bank that had spent four years accreting a DevOps function that nobody was happy with. The application teams were slow, the central team was overworked, the regulatory audits were uncomfortable. We did not solve any of this by adding more DevOps engineers. We solved it by reconstituting the central function as a platform team with a product manager, three engineers, and a deliberate policy of refusing tickets that did not represent a platform gap.

Within six months, the application teams stopped calling the platform team for routine work. The platform team stopped writing scripts for individual application teams and started writing capabilities that all application teams used. The cycle time on a typical change dropped substantially. The audit conversations got easier, because the audit evidence was a query against the platform, not a forensic exercise across half a dozen separately-owned tools.

What stood out, watching this happen, was how unspectacular the engineering was. There was no exotic stack. The platform was built on commodity infrastructure with a thin product layer on top. The hard part was not the engineering. The hard part was the organisational rewiring — convincing the application teams to use the platform exclusively, convincing the security function to encode their controls into it, convincing the leadership team that funding a non-customer-facing team was a good use of money. The engineering followed once those decisions were made.

The counter-argument

The honest objection is that platform engineering is just DevOps with new vocabulary. Same people, same tools, same problems, fresh hype cycle. I have heard this from enough senior engineers to take it seriously, and they are partially right. The technical content of platform engineering is not new. Infrastructure as code, self-service deployment, encoded policy, observability — all of these have been part of the DevOps conversation for years.

What is new is the organisational arrangement. The platform team is funded and incentivised as a product team. The application team is treated as a customer with measurable adoption and satisfaction. The platform's surface is a deliberate product surface, not an emergent collection of scripts. None of these are technical changes. They are operational and cultural changes that, in retrospect, the DevOps movement should have made explicit and did not.

I think the people who say "this is just DevOps rebranded" are correct that the techniques are continuous. They are wrong that nothing has changed, because the shape of the team and the relationship to its consumers has changed. In an organisation where this is a vocabulary swap and nothing else, it will not work. In an organisation that takes the product framing seriously, it does.

What this means for a financial institution

Three moves matter.

First, stop hiring DevOps engineers as ticket-fielders. The next hire on the central team should be a product manager, not another senior SRE. The team needs someone whose job is to understand the application engineers' day and turn it into a platform roadmap. Without that role, the central team will continue to be a service desk regardless of what it is called.

Second, measure the platform's success by adoption inside the institution, not by uptime. Uptime is necessary. Adoption is sufficient. If application teams can do their work without calling the platform team, the platform is succeeding. If they cannot, it is not, regardless of how stable the underlying systems are.

Third, treat the encoding of policy in the platform as a multi-year programme, not a quarterly initiative. The risk and compliance functions will not move quickly on this, and pushing them to is counter-productive. What works is a slow, sustained pattern of encoding one control at a time, each backed by evidence that the encoded version is at least as strong as the manual version. The institutions that do this build a structural advantage that compounds. The institutions that try to do it in a single quarter usually find themselves rolling back, having scared their risk function badly.

The banks that are ahead on this in eighteen months will not be the banks with the biggest platform teams. They will be the banks whose platform teams have got smaller as a fraction of the engineering organisation while the engineering organisation has got faster. That ratio — engineers shipping per platform engineer employed — is the number I would track. It is the only number that reliably distinguishes a real platform from a renamed DevOps function.

platform-engineering, devops, engineering-leadership, financial-services, internal-developer-platforms