A companion to the forthcoming second edition of The Strategic Flywheel.
Years ago at Citibank, we were working on a change that was expected to save the bank millions of dollars a year: move retail customers with little account activity to quarterly statements.
Everyone said they supported it. Getting the people and testing time we needed was another matter. Key stakeholders missed project meetings. Technology had competing priorities. The team kept running into commitments that had already been made elsewhere.
One obstacle was particularly difficult. We had two release-testing environments with calendars that followed the real calendar. To test multiple quarterly cycles within a workable timeframe, we needed to take over one environment and accelerate its clock. A test day might represent a week or even a month.
The person responsible for the environments pushed back hard. Other projects depended on them. Changing the calendar would be disruptive and he was concerned about the risk. His answer was that it was impossible.
Members of my project team were there. I could see them losing hope that we would get past it.
The exchange, as I recall it, went like this.
“What would it take to make it happen?”
“An act of God.”
“No problem. I know God.”
I went to see Angelo Incorvaia, who was responsible for core and liability systems for Citibank North America at the time. I explained what we needed and why. He supported the request.
There was still an enormous amount of work ahead. The project required coordination of interest and statement-cycle tables across multiple core systems. The team pulled it off. Getting past that first “impossible” gave people renewed confidence that we could finish the job.
Find the decision behind the obstacle
I think about that project when I hear an AI initiative described as a strategic priority.
At Citi, the intended benefit was clear. The conflict involved a shared environment, other projects and the authority to make a decision across them. The environment manager had responsibilities beyond our project. Those responsibilities deserved to be part of the discussion.
Asking what it would take helped us understand where the decision belonged. Angelo could consider the request across the systems he led. The team could then get on with the difficult delivery work.
For a similar request today, I would ask the responsible teams to set out the dependencies, the likely disruption and the options for managing it. Leadership can then weigh those consequences against the value and timing of the change. The concern belongs in the decision, with someone accountable for acting on it.
That is the part of transformation I want leadership to pay attention to. An approved business case creates commitments throughout the bank. Someone has to reconcile them.
AI brings those commitments into the same room
Suppose your bank wants an AI assistant to review lending documents. The lending team wants quicker turnaround. Operations needs a process its employees can handle. Technology has to work through data access and integration. Finance needs to understand the cost of running the service after the pilot.
There are decisions about authority too. Drafting a summary for an employee and sending a request directly to a customer require different permissions. I would settle that scope early, with the people who own the lending process involved.
Their experience should shape the experiment. They know which documents create confusion and which apparently ordinary applications require special handling. Give them time to explain those cases while the design can still change.
The latest technology can create a useful opportunity. We still need to decide how that opportunity fits the bank we are running today.
Put the four pillars to work
In the second edition of The Strategic Flywheel, I describe four pillars leadership must bring together: Strategic Priorities, People & Organizational Structure, Technology & Architecture and Money.
The Citi project touched every one. A worthwhile priority needed people who could participate, a testing environment that supported the work and a decision justified by the expected financial benefit.
For our illustrative AI initiative, I would bring those same choices into one discussion. Agree on the outcome worth pursuing. Name the people needed and make room in their schedules. Establish the technical boundaries and the path into everyday use. Fund the ongoing responsibilities alongside the initial build.
Run, Change and Innovate stay involved throughout. The people running the bank bring operating knowledge. The people delivering change work through implementation and adoption. The people exploring possibilities test what could be useful. Findings should move among all three.
An experiment might reveal a data problem that operations can fix immediately. An operating concern might change what the experiment attempts. That exchange gives each team something useful to work with.
A bank can start with a narrowly scoped experiment while continuing to improve its existing systems. Size the commitment to the people and controls available. Use the findings to decide what deserves more investment. That gives the bank a way to learn while protecting the services customers already depend on.
The four pillars support all three gears. The operating rhythm keeps leadership’s decisions about priorities, people, technology and money connected to the work.
Keep making the decisions after kickoff
The book’s One Project List puts competing commitments where leadership can see them. Its operating rhythm gives leaders a regular time to act: weekly attention to risks and exceptions, monthly portfolio decisions and quarterly reprioritization.
Apply that rhythm to the AI work alongside the rest of the portfolio. When a production issue pulls a specialist away, record the effect on delivery and agree when the person can return. When a pilot produces useful evidence, make a decision about its next step. When the benefit disappoints, examine the scope and the assumptions.
These conversations give employees a way to raise a conflict before it becomes another missed date. Leadership then owes them an answer they can work with.
The three companion articles take that responsibility further: making room for experienced staff, giving operations ownership from the beginning and deciding how to put verified savings to use. Each starts with something I encountered in a bank transformation.
Give the team a fair chance
As I finish the second edition, the Citi experience stays with me because of what changed for the team. Once the first obstacle could be addressed, people saw a way forward. Their knowledge and effort carried the project through.
That is what I would want an AI team to experience: a worthwhile problem, access to the people who understand it and leadership prepared to work through the constraints.
And when you hear “impossible,” take the concern seriously. Find out what would have to change and who needs to help make that decision.
Before approving the next AI initiative, take the OptimizeCore® Strategic Flywheel Readiness Assessment to examine where your operating model needs attention. Bring the readiness assessment into a discussion with the people responsible for priorities, staffing, technology and funding.
The forthcoming second edition of The Strategic Flywheel develops these connections further, including its new chapter on AI transformation. Visit the book’s page for publication updates.
#CoreBankingTransformation #BankingAI #BankingTransformation
