I've spent my career inside banks — running them, fixing them, and building them. And if there's one thing I've learned, it's this: transformation programs fail far more often than they succeed.
Not because the technology isn't good enough. Not because the people aren't smart enough. They fail because the approach is wrong. Banks treat transformation as a series of disconnected projects — a core system upgrade here, a process redesign there, a cost-cutting initiative somewhere else — and wonder why nothing fundamental changes.
Real transformation is different. It requires four things to move together: people, process, technology, and finance. Miss one, and the whole thing eventually stalls.
That's not a theory. It's what I've seen play out over and over.
How I think about transformation at banks
A simpler transformation framework that works
There are various transformation frameworks developed by top management consulting firms. All are great! But the one I find most useful in practice is from Deloitte. It recognizes that transformation isn't a single project. It's a structured process that moves an institution from its current state to a different operating model.
The methodology follows a clear sequence: understanding where you are, defining where you need to be, and executing a roadmap to get there.
In banking, that discipline matters. Banks are complex organizations with deeply interconnected systems, processes, and balance sheets. Without structure, transformation efforts become fragmented before they even start.
Understanding where you are
You can't fix what you don't understand.
So the first thing I do is get under the hood. Not just look at the org chart, but actually understand the technology architecture, the core systems, the operational workflows, the financial performance, and the governance structure. How do decisions get made? Where do things break down? What's actually causing the friction?
Most banks have accumulated layers of complexity over decades. Systems were bolted on to solve specific problems. Processes evolved to meet regulatory requirements. Teams built workarounds to compensate for platform limitations. Over time, it becomes hard to tell what's intentional and what's just accumulated.
A good diagnostic cuts through that. It identifies the real bottlenecks — whether they're in the technology stack, the workflows, the organizational structure, or the financial model.
Skip this step, and you'll end up solving the wrong problems.
Defining the Target Operating Model
Once you know where you are, the next question is where you need to be.
That's the Target Operating Model — the TOM, in consultant-speak. But I don't treat it as a theoretical exercise. It's a set of concrete answers:
How should this bank actually operate in three years?
What technology architecture will support it?
How will work flow through the organization?
Who makes which decisions?
How do we measure success?