New technology executives often discover the skills that made them successful early in their careers can be the very things that limit their success as a CIO, particularly as the scope, complexity, and expectations of the role expand. Few leaders understand that evolution better than AlTi Global CTO Phil Dundas, my recent guest on the Tech Whisperers podcast.
Leading technology inside some of the world’s most complex financial organizations, Dundas has repeatedly had to rethink what his job requires of him. That has meant learning when to get into the details and when to stay out, replacing control with context, creating genuine accountability and empowerment without leaving people unsupported, and measuring his success less by the problems he solves personally than by the capability of the organization he builds around him.
Those lessons are particularly relevant as CIOs take on broader mandates and lead organizations that operate with increasing speed. Navigating this environment requires a leadership system that enables good decisions, accountability, innovation, and execution to happen at scale. That starts with trust, which Dundas sees as the foundation for client relationships and innovation. Here, Dundas shares some of the hard-earned shifts that helped him make that transition, as well as the leadership practices he believes separate true enterprise leaders from strong technology executives.
Dan Roberts: Trust is a thread through everything you do. How does it shape the way you approach innovation, especially with AI?
Phil Dundas: Wealth management is a trust business. I love the line that trust arrives on a bicycle and leaves in a sports car. It takes years to earn and moments to lose. The relationship between a client and their advisor sits at the center of that trust, and it is underpinned by the data and information the client sees. So client trust depends on data trust, and data trust depends on the people and the discipline behind it.
I’m impatient to innovate, and that’s exactly why I’m so obsessed with foundations. I love to build, to engineer, to develop from the ground up, and to see concepts go from business ideation to business-impacting reality. I want to architect, design, and deliver AI solutions on the most exciting contemporary platforms. But reconciled, clean data and clean identities are what let you ship AI tools that don’t embarrass you a few weeks after the demo. Getting the foundations right isn’t the cautious choice. It’s what enables you to go fast.
The same is true of guardrails. Clear data ownership, sound governance, and clarity on where AI should and shouldn’t be used aren’t there to slow people down. They’re there to speed them up. When people know where the edges are, they can then move faster inside them.
Foundations work is often invisible to the business, though. Nobody sees the data pipelines. So alongside it, you need visible wins, a dashboard or a tool demonstrating forward movement, showing data more timely and accurately than before, so stakeholders can see the progress and keep backing your efforts on the less glamorous work underneath.
As you climb the ladder, some strengths that once made you invaluable can limit your effectiveness as an enterprise leader. How have you had to pivot as your leadership responsibilities became bigger and more complex?
The biggest thing I had to unlearn was the need to be the person with the answer. When you come from a deep, analytical, technical background, your instinct is to step into the “how.” As the role grows, your job shifts to the destination and the outcomes, and to letting your team own more of the route.
That means accepting they may not do it the way you would. Often you’re pleasantly surprised and the result is better than you expected. Sometimes they stumble, and that’s how they learn. Both are hard when you’re up against a deadline with tough stakeholders, and both matter.
The other shift is holding the destination firmly while staying flexible on the route. Conviction holds the destination. Stubbornness refuses to change the route.
I learned that in a previous role on a divestiture, where we were extracting a business from one parent and integrating it into another. I was on the infrastructure and business enablement side, and we came up with some incredibly elegant technical solutions leveraging virtual desktops. We thought, “The business is going to love this.” However, when we sat down to show them, it was technically perfect — and completely unusable. It was cumbersome and hard to navigate for a non-technical end-user. We hadn’t done the design thinking or sat with the business to ask whether it worked for them.
We had to make a tough call and go back to a less sophisticated solution that was what the business needed to get through the migration, as we were up against a transition services agreement deadline and the clock was ticking. It stung, given the time and money we’d invested. But as a leader, you have to acknowledge that, take accountability, and pivot.
You’ve told me about receiving 360 feedback earlier in your leadership career that essentially said you were getting too much into the details. You then discovered you could overcorrect in the other direction. What did those experiences teach you about the difference between empowering people and abandoning them?
That feedback stung, and not just because I’d expected a more flattering read. Earlier in my career I’d worked for leaders who held on too tightly, and I knew how much it drained a team. Hearing I’d started doing the same thing was hard. So I took it to heart, too much so.
At a previous firm, I stepped well back. I wanted people to feel they had real autonomy, so I stopped asking enough questions and trusted that things were in hand. For the most part, this worked well and people felt empowered. On one program, however, my distance became a problem. The project team wasn’t operating at the right level, and the work started veering off course, down a technical route built on solutions that weren’t industry standard. By the time I realized the impact, those choices were hard to correct, and it was a tough price to pay.
What I learned is that accountability doesn’t delegate. You can make someone accountable for an outcome, but you still own it. Your most senior stakeholder isn’t going to say, “I know you empowered that person.” They’re going to say, “You’re the person we’re looking to.”
The fix wasn’t distance; it was a system: regular touchpoints, the right questions, and a sense check with stakeholders so I can stay out of the detail and still know we’re heading in the right direction. From a distance, empowering someone and abdicating responsibility can look the same. The key is whether you’ve built a way to know the difference.
How do you determine what to delegate, what to inspect, and what requires you to get personally involved?
It comes down to the significance of the decision, how reversible it is, and the cost of getting it wrong. Core architecture that will shape how the organization uses technology for years, complex multi-year contracts, and sizable spend are the decisions I stay close to, because ultimately, I’ll be held accountable. Everything else belongs to the team, including many of the strategic calls in their own areas, because they’re closest to the work and best placed to make them. That’s the scale I use to measure my involvement.
I think of it as changing altitude. On day-to-day delivery, I’m often at thirty thousand feet. On architecture, new platform decisions, and any technical designs that are high-stakes or hard to undo, I come right down to three hundred. The skill is knowing which altitude a decision needs, and explaining to the team why you’ve come down so it doesn’t read as a lack of trust.
The same logic applies to buy versus build. Buying a commodity is often a reversible bet, or at least a more modular one — move fast, and if it’s the wrong direction, you can change. Building is where you pour your scarce specialist talent into what differentiates you, and those decisions are typically more costly, warrant more time, and are much harder to undo, so that’s where your conviction needs to be. Ultimately, it’s knowing which decisions you can afford to get wrong and which you must get right.
I won’t pretend I’ve mastered this. Knowing when to come down and when to step back is still a work in progress for me. I notice it sooner now, and I know the best check is to ask my team whether I’ve come down too far or stayed up too long.
What do you do to give people enough context about the business, the customer, the strategy, and the tradeoffs so that they can make good decisions without your involvement?
Instructions tell people what to do in situations I’ve personally anticipated. Context helps them decide well in the ones I haven’t. If people understand the strategy, the customer, and the tradeoffs, they can make good decisions in rooms I’ll never be in.
So every year I reset the team’s strategy against the firm’s and make sure people see it before decisions start landing, not after. People like clarity, and they want to know their work contributes to the broader goals of the company. When someone can say, “What I’m working on today helps the business do this,” they bring more judgment and energy to it. That’s why I see alignment as more of a motivation problem than a governance one.
It has to run in both directions. The business needs a clear line of sight from its goals to the work we’re doing, and the team needs the same line from their daily tasks to those bigger picture goals.
And a lot of transformation isn’t glamorous. Most of it is cornfields, not mountain peaks — day after day of steady progress. Context is what keeps people moving through that stretch, because they know where it leads.
How have you learned to lead successfully by questioning rather than being the one to have all the answers, particularly when you’re surrounded by people who know more about their domains than you do?
It starts with how you ask. Good questions are open, constructive, and get quickly to the decision or information you need. Poor ones leave people feeling judged or undermined.
Many years ago, I was taught to start questions with “how” or “what” rather than “why.” “Why did you do that?” sounds like blame. “What led you there?” or “How are you thinking about the risk?” opens up a coaching conversation. I still catch myself and say, “Hold on, let me ask that a different way.”
Once you accept you’re no longer the smartest person in the room, the questions you ask matter more than the answers you give. But expertise only travels upward if disagreeing with you feels safe. I want my team thinking, “I should make Phil aware of this,” not “I’ve got to tell Phil, and I don’t know how he’s going to react.” If people trust that bad news, or a decision that didn’t work out, will be met with curiosity rather than blame, you hear what you need to know early.
There are still times to make the call yourself — when the stakes are too high, the timeline’s too tight, or the wrong decision would be hard to recover from. Knowing the difference is part of the job.
What have you learned about building a leadership team and operating model that can make great decisions, challenge one another, deliver outcomes, and continue getting better without depending on the CIO?
It starts with who you hire. I’ve long admired Patrick Lencioni’s advice in The Ideal Team Player: Look for people who are humble, hungry, and people-smart. Then invest deliberately in your people’s strengths, even though the instinct is to spend your time on whoever is struggling.
Then it’s trust within the team, enough that people will challenge one another directly. Once, at a leadership offsite, I let my team know I’d noticed decisions coming to me that I’d much rather they took to each other. It’s a very natural and common pattern. It’s easier to rely on the boss to ask the awkward question than to hold a peer accountable, but then the other person wonders why it didn’t come to them directly.
If everyone is all smiles and nodding in team meetings, you probably don’t have the culture for the harder conversations, like “I asked you for this, it didn’t happen, and here’s what that meant.” Those conversations work when everyone understands they’re about behaviors and commitments, not the person. Building that isn’t easy. But once it’s there, leaders ask each other the questions you would have asked, and hold each other to account without you in the room.
Leadership is holding people accountable. It’s also about seeing their potential. A year advisor at my high school identified a capability in me long before I saw it in myself, and it changed my path. That’s what I try to do for my team now — look for the talent someone hasn’t yet recognized in themselves and help shine a light on it. The measure of a leadership team isn’t how it performs when you’re in the room. It’s what happens when you’re not.
For more from Phil Dundas’s leadership playbook, tune in to the Tech Whisperers.
See also:
Read More from This Article: What separates true enterprise leaders from strong tech execs
Source: News
