DevOps fundamentally is an arbitrage play: it exploits the idea that if the things you are developing and operating are known to be stateless and immutable and ephemeral you can move very quickly, because there are a bunch of things you just don't need to do. And this is true, you can, and you don't.
But "traditional" IT is all about managing statefulness and controlling the transitions between states (or "mutation" if you prefer). A database server, a file server. A database server for example: once you have made changes to a schema and data has gone in, you can no longer "roll back" because you probably have nowhere you can put that data that satisfies the constraints of all the stakeholders. If the database server goes down you can't just spin up a new one, it has to be exactly the same to the greatest extent possible, and you need to have a plan for resolving the deltas. DevOps doesn't really address this and even worse, the typical DevOps pitch includes some jabs at "traditional" IT for being slow and obsolete, without any acknowledgement that maybe there were reasons for things to be done the "old fashioned" way other than the practitioners being dinosaurs.
What that sounds like to a stakeholder is that DevOps people are willing to take risks with the company's most precious assets - customer records, accounts, inventory control, all the other things that typically reside in the stateful parts of the technology infrastructure. Therefore to work with and bring on board skeptics the very first thing you must do is convince them that you have mitigated all the risks of operating the stateful parts of the infrastructure in a DevOps fashion.
I will wager that some variation on this theme is the root cause of TSB's woes at the time of writing. They failed to exercise sufficient care with the stateful parts of their system.