This Could Happen to Us: Julian Keil on Leading Customer Success in Disruption
Julian Keil, who leads customer success globally at iluminr, on a faster-moving risk landscape, why testing matters more than documentation, and reading whether a customer wants a vendor or a partner.
In brief
Julian Keil leads customer success globally at iluminr. Over the last five years he has watched the customer base shift from mid-tier organizations to large global enterprises, and the conversation move from documentation toward testing and evidence. In this interview he discusses the gap between how the market talks about resilience and how firms operationalize it, what separates the customers who get value from microsimulations, and the executive-peering approach that brought a major account back from the brink.
The road in
How did you end up at iluminr?
Julian: It's twofold. I knew Josh from the RiskLogic days, which is a function of having worked in the industry at other organizations, so I had awareness of CQ Command back then and the space they occupied. The more recent engagement came through an introduction from Romley Blackburn, co-founder of Whisper, who I worked with for a long time. He was doing some work into iluminr, and I met Marcus through that. We started talking more broadly about where the business was going and where there might be opportunities to help. So it was long-term awareness, and then an introduction that brought it together.
How has the platform and customer base evolved over your five years?
Julian: The biggest shift I've seen is from mid-tier organizations to large global giants. That's the biggest change in who we serve. We've also been on a journey in what we serve them with. We've moved from more critical event management style propositions to the broader microsimulation narrative. Stepping out of a mid-tier organization with a nominated champion running a program, into a team of people serving an organization that spans the globe, is a very different engagement model. Very different asks, a different level of tooling, and a different set of expectations around it.
A faster-moving landscape
What do you understand about resilience now that you didn't when you started?
Julian: The thing I've been following is how interconnected organizations' technology footprints are, and how fast that world is evolving, especially with AI. The regulatory side is running alongside it, trying to play catch-up on what guardrails are required now and into the future. It feels as though the world is moving faster than it ever has, and the technology risk curve with it. One of the challenges is that many business owners still operate with the same worldview. From a resilience perspective, part of the work is evolving the function so it keeps up with what the risks actually are today.
Is there a gap between how the market talks about resilience and how mature buyers actually operationalize it?
Julian: The gap is around actual testing. Think about CPS 230 here in Australia. That felt very much like an exercise in documentation and process mapping, a consultant's field day. You end up with an intricate map of how systems, processes, and technologies pull together. That's useful, but not many people have taken it further to pressure-test it or show evidence of it.
Take the third-party exit plans some teams have been working on in the UK. They documented 50 plans with a lot of team members involved, all at a point in time, a consulting-led activity that generates a lot of material. People wrote the plans, some signed off that the plans existed, and then everyone put them in the drawer. We've met the compliance requirement.
But have we built real awareness around it, let alone tested what it could look like or considered the tolerances? It's a point-in-time activity done because regulation pushed for it, without much thought about testing and validation. That's still a problem to be solved, and one of the exciting things we get to bring to it.
Helping customers see progress
How do you help a customer see progress when the work is about things that haven't happened yet?
Julian: One thing that's had appeal for a lot of customers is that we've curated a library of scenarios reflecting new and emerging threats, things they may not have thought much about. There's not enough looking outward at what's going to hit you in three, six, or nine months. The work we did early on around deepfakes was prescient. Look at what's happening now, it's gone mainstream across so many platforms. Bringing that to people gives them those wide-eyed moments of, this could happen to us, how do I bring that back into my organization for awareness?
At the same time, helping them with the basics is incredibly valuable. Plan validation, testing roles and responsibilities. It's amazing how many people are still focused on getting the basics right. So the answer is twofold: new, emerging, insightful scenarios that build awareness, and the building blocks they need to do well and do more efficiently.
Is there a customer that shaped how you think about resilience?
Julian: I don't think there's any one customer, and that's the beauty of the role. I get to see into many organizations and look at what they do well and where there's room to improve. It's a spectrum of maturity across reporting, tooling, exercising, you name it. We have clients who do emergency management really well because it's their day to day. Others who do excellent work on exercising. Others who are great at self-assessing the maturity of their leadership and working out how to bring their broader stakeholder community up. Others who've been impressive in how they've grown their program across a large part of their team. Others who lead on documentation, planning, and playbooks.
Maybe it's about taking the best of those and sharing the insights with clients who haven't gone as broad, or focused as much on process, or considered maturity models.
What separates customers who succeed with microsimulations from those who don't?
Julian: It's the clients who are happy to roll up their sleeves and accept it may not be perfect. Perfect can be an impediment to progress. Moving ahead with momentum builds more momentum, more participation, more goodwill, more adoption. The alternative is refine, refine, refine, because you're hesitant about putting an experience in front of your organization in case it reflects on you. The ones who are brave enough to say, I'm running a strong program, this is a good way to evolve it, let's get on with it, tend to do well. They realize that 98 percent is still a really good result.
I'd put people in two camps: fast movers who are confident and happy to give it a go, and others who'd rather perfect the second paragraph of a playbook than actually test it.
Leadership and judgment
What's a piece of conventional CS leadership advice you think is wrong?
Julian: I think there's historically been too much focus on NPS. The question I'm more interested in is, on a scale of 1 to 10, do you see us as a vendor or as a partner? If a client sees you as a vendor, then maybe we service them as a vendor. If they expect a partnership, that's a very different model and service approach. That's a better thing to understand than an NPS score, which I've seen gamed and manipulated in all sorts of ways.
Tell us about a time where you lived resilience with a customer.
Julian: We've had an ongoing relationship with a team, through different stakeholders moving in and out. We started with a low footprint and grew it right up, and we've been through about half a dozen flare-ups, some of which were not great. The big takeaway for me was executive peering: establishing relationships at different levels of the organization, exec to exec and operations to operations, so we have influence and understanding at each level. We did a good job identifying product requirements, understanding different business owners and their needs, turning that into a delivery schedule, and reporting and managing it. Practically, that meant more eyes on it, a higher cadence, more executive buy-in on our side, and an accountability profile where we showed up every month to a steering committee, demonstrated progress, and held ourselves accountable for what we said we'd deliver. And when things didn't function as well as we'd have liked, we scrambled to fix them quickly.
What have you changed your mind about in the last year?
Julian: Where I've evolved my thinking is around our capacity to serve multiple masters, multiple use cases, multiple scenarios. I've come to see that as problematic. For a while I felt we could straddle a few different market and product opportunities. As soon as you take your foot off the gas in one area, others move to fill the slack, a cheaper and shinier option comes along, or business-as-usual tools slide in over the top. So it's a heightened awareness of that.
The other thing is the kind of person who'll be successful in this industry. It's more consultative, more strategic, leading rather than following.
Leading globally
What's the hardest part of leading a global CS team that nobody warned you about?
Julian: The obvious joke is sleep. Beyond things happening around the world at all hours, it's the subtleties, not just of the regulatory environment, but of country characteristics, and even differences within a country. Given we operate across so many regions, having a heightened awareness of the geographic subtleties of dealing with people in Germany versus the UK versus Singapore versus different pockets of the US makes a real difference.
There's a lot of variability there, and it's something we could all understand better. And it applies inside the business too.




