Q1. To begin, could you briefly describe the roles where you were directly accountable for transformation outcomes, and the types of decisions where failure would have had visible operational or organizational consequences?

In my recent roles, I was directly responsible for ensuring successful transformation outcomes, and I had the authority to make decisions where any misstep would have had an obvious impact—whether operational, financial, or organizational. I’ve felt that weight personally, knowing that if something went wrong, it would be immediately visible across the business.

For example, when I was Director – Strategy & Transformation Consultant and led the Transformation & Innovation Office (TIO), I was hands-on in designing, governing, and delivering major transformation programs. These ranged from finance operations to technology enablement and full operating model redesigns. In these roles, I personally owned the transformation roadmap, was responsible for making sure the intended benefits were actually realized and oversaw the execution governance to make sure our big-picture strategy turned into results that mattered day-to-day.

At the same time, I also took on program-level leadership roles in transformation—for example, leading P2P, O2C, and R2R streams. In these positions, I wasn’t just giving advice; I was on the hook for the risks involved in execution. The types of decisions I had to make included things like:

Making tough calls on how and when to sequence and scope different waves of global transformation, knowing that a wrong move here could have disrupted business continuity or delayed the value we were aiming for.

Deciding on the target operating model and process design—fully aware that if I got it wrong, it could lead to deep-rooted inefficiencies, weakened controls, or a decline in service quality.

Making judgement calls on whether we were truly ready to go live, how we’d stabilize post-launch, and how to handle escalations during critical times like period close, migration, or major transitions—knowing that a mistake would lead to real operational breakdowns, stakeholder issues, or financial risks.

In my role as a governance and portfolio lead, I was also directly responsible for setting priorities, deciding where to focus investments, and handling risk across several initiatives at once. I knew every decision could have real consequences—like cost overruns, missed productivity goals, or losing stakeholder trust if I didn’t keep a tight grip on things.

In all these roles, I wasn’t there just to give recommendations—I was expected to own the outcomes, manage the downside risks, and step in to fix things when execution went off track. Often, this meant working under real pressure, where any failure would be immediately obvious to senior leaders and the teams on the ground. That kind of accountability has shaped how I approach transformation work to this day.

Q2. In large transformation programs, what types of initiatives look compelling during design but most often fail to deliver once rolled out at scale and why?

From what I've seen in large transformation programs, the initiatives that tend to fall apart at scale are always the ones that look beautiful on paper but aren't built for the messiness of day-to-day operations. I’ve personally watched over-engineered global models and flashy tech-driven automations fall flat when they're launched before processes and data are truly ready. It’s tempting to believe that once you go live, people will just adapt and everything will click into place, but that’s rarely the case. These solutions work in pilot phases, but when you hit real-world volumes, local variations, and more exceptions than you ever imagined, things start to unravel. Every time I’ve investigated why these failures happen, it comes back to the same issue: teams didn’t focus enough on making the design robust for scale, didn’t plan for real ownership after go-live, and didn’t bake in the reality that things will go wrong and need to be managed accordingly.

Q3. Which transformation decisions are hardest to reverse once implementation begins, and at what point do teams usually realize it too late that those choices have locked in friction?

In my experience, the toughest decisions to walk back are always around who owns the target operating model, the core choices about technology and data architecture, and those early calls about standardization versus local flexibility. Once you set those in motion, you’re pretty much committed—they shape every handoff, slow down decision-making, and make exceptions much more expensive. I’ve seen teams only realize they’re stuck about two or three months after go-live—when, despite everyone’s best efforts, the friction just won’t go away and it hits you: this isn’t a teething problem, it’s baked into the structure now.

Q4. Where have AI and automation materially simplified operations or decision-making, and where have they failed to change outcomes despite strong expectations?

From my own hands-on work, I’ve seen AI and automation really shine when it comes to taking the pain out of repetitive tasks—like transaction processing, reconciliations, exception triage, or giving teams better visibility for decision support thanks to smarter pattern recognition. But I’ve also witnessed situations where the hype outpaced reality, usually when people expected AI to replace human judgment or take over in messy, ambiguous situations or broken processes. My rule of thumb is this: AI can supercharge discipline and insight, but it’s never a cure-all. If you haven’t sorted out ownership, data quality, or the fundamental operating model, even the best AI will only take you so far.

Q5. In your experience, why do simplification efforts sometimes increase complexity instead of reducing it, especially across global or cross-functional environments?

From what I’ve observed, simplification efforts can actually backfire and make things more complicated—especially in global or cross-functional environments—when the focus is only on fixing one part of the puzzle. I’ve seen teams streamline a process, tool, or function in isolation, without thinking about the bigger picture: how ownership, data, and incentives connect across the whole system. That’s when you get hidden handoffs, more exceptions, and extra layers of governance. It might look neater in a slide deck, but on the ground, it becomes much harder to operate at scale because you’ve just moved the complexity around instead of actually removing it.

Q6. Which governance mechanisms genuinely sustain transformation outcomes, and which ones add structure without preventing regression?

In my experience, the biggest traps in transformation governance are when teams confuse reporting with real accountability or keep adding layers of meetings and forums without giving anyone the authority to actually make decisions. I’ve also seen too much focus on tracking milestones instead of whether we’re actually delivering outcomes. Another red flag for me is when ownership is spread so thin that benefits are ‘owned’ by the program instead of by specific operators. It all looks good on paper—lots of structure and rigor—but I’ve learned that unless real accountability and ownership are in place, these mechanisms don’t stop things from slipping back once the initial pressure wears off.

Q7. If you were advising senior leaders responsible for large-scale transformation today, what uncomfortable question about execution risk or change sustainability do they rarely ask early enough and what kind of answer should immediately trigger a rethink?

From my own experience, transformation communication tends to fall short when it focuses on telling people what’s happening, but not why it actually matters to them. I’ve seen plenty of cases where messages get muddled across teams, or where leaders rely on one-way broadcasts instead of building genuine two-way dialogue. The outcome? People know about the change, but they don’t feel like they own it—so what looks like alignment on the surface never really sticks.