City Shift Finance: Which decision most changed the direction of the transformation?
Ambarish Majumdar: The decision that changed everything was killing the pilot-project mindset. Before the transformation, we had dozens of AI experiments running across the organization, and almost none of them mattered.
Each team had its own pilot, its own vendor, its own definition of success. Learnings never traveled. Nothing graduated to production because nothing was designed to. We were accumulating demos, not capability.
The reframe was simple: stop running AI projects and start redesigning how the organization works. Ways of working first, tools second. That meant defining new roles, new handoffs, and new decision rights before arguing about which model or platform to buy. It meant asking every team the same question: which parts of your weekly workflow change, and what does the new version look like?
Once we made that shift, the scattered experiments collapsed into a single transformation with actual momentum. Teams stopped optimizing their own pilots and started building on shared foundations. The compounding started. In hindsight, the pilot phase wasn’t just slow, it was actively misleading, because it let leadership believe transformation was happening while the underlying work stayed exactly the same.
City Shift Finance: What information did leadership need earlier?
Ambarish Majumdar: We needed an honest baseline of the organization’s real AI capability, not the version in the slide decks. Early on, every readiness assessment told us roughly the same story: high enthusiasm, broad awareness, teams “already experimenting.” It was mostly self-reported, and self-reports measure confidence, not competence.
What we overestimated was readiness. What we underestimated was how much daily workflows had to change. Knowing that a tool exists is not the same as knowing when its output is wrong, and the skill that actually determined success wasn’t prompting, it was evaluation. Very few people had it. The gap between “we have access to AI tools” and “we can reliably do our jobs with AI assistance” turned out to be enormous, and it was invisible in every survey we ran.
If we’d measured task-level capability early, by watching people do real work instead of asking how they felt about AI, we would have sequenced everything differently. Training would have started with judgment and verification, not tool walkthroughs. Change management would have been budgeted as the main event, not an afterthought. The lesson: measure what people can actually do, in the workflow, before you plan the transformation around them.
City Shift Finance: Where did decision authority become unclear?
Ambarish Majumdar: The blurry line was the seam between central AI teams and business units. The central teams were building shared platforms, evaluation frameworks, and core capabilities. The business units were building their own solutions for their own problems, on their own timelines.
Both were doing reasonable work. The question nobody could answer was: who gets to kill a local build that duplicates what central already built?
Without an explicit answer, we got the worst of both worlds. Units duplicated platform work because they didn’t trust the central timeline. Central teams built capabilities nobody adopted because they hadn’t been in the room for the real requirements. Spend doubled, tools conflicted, and every duplication became a small political fight about whose solution survived.
We had to draw the line explicitly, in writing, with names attached.
Central owned shared infrastructure, evaluation standards, and anything that touched customer-facing risk. Business units owned domain workflows and had real input into the roadmap, plus a clear escalation path when central was too slow. The clarity didn’t end disagreement, but it ended duplication. Ambiguity is expensive in a transformation because every unclear decision gets made twice.
City Shift Finance: Which part of the organization proved hardest to change?
Ambarish Majumdar: Middle management, without question. Individual contributors adopted the tools fast because the tools made their work visibly easier.
Senior leaders sponsored the change because the strategy was legible to them. The layer in between had the most to lose, and that’s exactly where resistance concentrated.
It wasn’t irrational. A meaningful part of a middle manager’s value was coordination: gathering information, synthesizing it, routing decisions. AI assistance automates large chunks of exactly that work.
Add redefined roles, shifting team compositions, and the quiet fear that a smaller, AI-fluent team needs fewer managers, and you have a group whose incentives pointed directly away from the transformation.
Their performance metrics still rewarded headcount and process ownership while the transformation was trying to reward leverage and outcomes.
What worked was being explicit about the new job. We redefined the management role around judgment, coaching, and accountability for AI-assisted output quality, and we involved managers in designing that definition instead of handing it down. The ones who made the shift became the transformation’s best evangelists. The resistance was never about the technology. It was about people being asked to dismantle the thing their careers were built on without being shown what replaces it.
City Shift Finance: How did leadership decide whether to fix execution or change the plan?
Ambarish Majumdar: We separated the question into two parts: are we measuring the right things, and what do the measurements say? The metrics that mattered were leading indicators of real adoption, not vanity numbers. Logins and seat licenses told us nothing. We tracked adoption depth: were teams doing actual work through the new workflows, or were they logging in once and going back to the old way? That distinction turned out to be the whole game.
We reviewed those indicators monthly, workstream by workstream. The rule was simple: if a workstream missed its leading indicators two cycles running, we changed the plan instead of pushing harder on execution. No heroics, no extended deadlines, no “just one more month of training.” Two misses meant the plan was wrong, not the people.
Changing the plan took different forms. Sometimes it meant rescoping a workflow that was too ambitious. Sometimes it meant replacing a tool that didn’t fit the actual task. Once or twice it meant killing a workstream entirely and reallocating the team. The discipline mattered more than any individual call. Without a pre-committed rule, every struggling workstream becomes a debate about effort. With the rule, it becomes a decision, and decisions are cheaper than debates.
City Shift Finance: Which operating tradeoff created the most disagreement?
Ambarish Majumdar: Speed versus governance, and it wasn’t close. The business units wanted AI in their workflows immediately. They had targets, competitors, and no patience for a six-month evaluation process before they could use a summarization tool. The central teams, meanwhile, were accountable for what happened when AI got things wrong, and “move fast” is easy to say when someone else owns the failure modes.
A single governance standard for everything would have satisfied nobody. Applied to low-risk internal tools, full evaluation rigor was pure overhead. Applied to high-stakes customer-facing systems, moving fast was reckless. The disagreement was really about the absence of a shared language for risk.
The compromise was tiered risk. We defined risk tiers explicitly: low-risk use cases, internal, reversible, no customer impact, moved fast with lightweight review. High-stakes use cases, customer-facing, consequential decisions, went through full evaluation before deployment. Everything in between got proportionate scrutiny. Once the tiers existed, most of the conflict evaporated, because both sides were right about their own tier. The business got speed where speed was safe. Governance got rigor where rigor mattered. The lesson generalizes: most speed-versus-safety fights are really fights about treating unlike risks alike.
City Shift Finance: Which governance practice helped most, and which slowed execution?
Ambarish Majumdar: What helped most was replacing the committee with a small, empowered review group operating on a 48-hour SLA. The group was senior enough that its decisions stuck, small enough to actually convene, and bound by a clock: every submission got a decision within 48 hours. That SLA changed behavior more than any policy document. Teams submitted early and often because review was predictable instead of dreaded. The review group became a service, not a gate.
Contrast that with what slowed us down early: applying identical approval rigor to everything. An internal meeting-summarization tool went through the same review as a customer-facing model influencing real decisions. Same forms, same waiting period, same scrutiny. It was overkill, and everyone knew it was overkill, which is corrosive. When governance is visibly disproportionate, people stop respecting it entirely and start routing around it, which is worse than having no governance at all.
The fix was making review proportionate to risk, which connected directly to the tiered model. Low-risk tools got a fast lane.
High-stakes systems got the full treatment. Governance works when it’s predictable, fast, and visibly calibrated to what’s actually at stake.
Committees optimize for nobody being blamed. Small empowered groups with a clock optimize for good decisions quickly, which is the actual job.
City Shift Finance: What showed the transformation had become part of normal operations?
Ambarish Majumdar: Two signals, one cultural and one institutional. The cultural signal was when teams stopped asking permission to use AI. Early in the transformation, every new use case came with a request, a proposal, a check-in. At some point that just stopped. People started with the assumption that AI assistance was part of the toolkit, the way you’d assume access to a spreadsheet. Nobody announces they’re going to use a spreadsheet. When AI reached that level of unremarkableness, the culture had shifted.
The institutional signal was stronger: performance reviews started judging the quality of AI-assisted output. That’s when it stopped being a program and became the job. Programs have names, dedicated teams, and end dates. The job is just what you’re expected to do. Once “how well do you leverage AI assistance, and how rigorously do you check its work” became a review criterion, the organization had made its expectations explicit and permanent.
Together those two told us the transformation was over in the best sense. Not because every workflow was perfect, but because the new baseline was self-sustaining. Nobody needed the transformation team anymore. The measure of a successful transformation isn’t what the program achieved. It’s what continues after the program ends.
