In Conversation with Simon Taylor, Interim Head of Engineering

Simon Taylor’s original remit as Interim Head of Engineering at a private equity-backed software company didn’t involve AI. But as he tackled legacy systems, cultural inertia, and delivery bottlenecks, the opportunity for something bigger emerged. In this interview, he explains how a practical, developer-first approach to AI helped shift mindsets, unlock value, and quietly kick off a wider transformation. 

What was your remit as Interim Head of Engineering? Where did you start with integrating AI to improve productivity?

The assignment originally had nothing to do with AI. I was brought in as the Interim Head of Engineering to help one of three companies in a private equity-owned group. There were three companies in the portfolio, and one in particular needed support

The company focused on competency management for firefighters. I didn’t know much about the domain at first, but I quickly learned that fires are relatively infrequent events. Firefighters spend most of their time practicing and proving competency in various skills: putting on breathing apparatus, setting up ladders, handling chemical spills, and so on. 

These competencies all expire, so they’re effectively on a hamster wheel, constantly having to demonstrate they can perform a task and then repeating the process once it expires. 

The system managed all that through software. The company had a good problem: more demand than they could service. Customers had often already paid, but due to capacity issues, the product hadn’t been delivered, so the revenue couldn’t be recognised. 

 But they also had a lot of issues: outdated technology, old ways of working, and low trust between the team and the rest of the organisation. 

 After a short period of getting to know the team and the context, I started implementing change. The first change was resetting the narrative around communication between this team and the broader organisation. 

 The challenge was that they were constantly being asked when things would be ready. So they had this giant plan trying to predict 13 months into the future when something would land. My initial step was to shift that focus, to talk less about what would happen in 13 months and more about what we had just delivered. 

Then came modernisation of the platform and other initiatives. It was during that 12-month engagement that I had a realisation: AI could be incredibly useful, not just for this company but for the whole group. And that’s really where the AI journey began. 

How did you introduce AI during your time as Interim Head of Engineering, and what tangible business outcomes did it deliver

I had this bright idea. There was all this support ticket data. The system I was working on had about six years’ worth of historical support tickets. My thesis was that buried in all those tickets were answers that could help deal with the support issue in front of you right now. 

It’s almost beyond human capacity to just know those answers off the top of your head, even if it’s been your day job for years. So the idea was to take all that historical support ticket data, combine it with the product documentation of which there was a lot, and use AI to help answer the customer’s question at the point the support person is dealing with it 

That’s how it all started. We began with an off-the-shelf commercial product, more as a proof of concept. But we quickly realised we didn’t want to give a third party all this sensitive customer information. There are all sorts of GDPR implications when you’re handing that over to a cloud-based AI provider you don’t control.  

That led to the idea of a private, self-hosted AI. I worked closely with the hosting company. This particular application was hosted in a data centre in a town where the office was located. 

I developed a relationship with them and suggested, “Hey, why don’t we try buying a server, installing some AI software on it, and running our own private AI?” And that’s what we did.  

After a lot of trial and error, we got it working. It was a physical server in the data centre, air-walled from the internet. It was loaded with six years’ worth of support tickets and all the product documentation, with a chatbot attached. A support person could paste in a customer query and get an answer based on all that historical data. 

That became the blueprint for a number of other AI proof-of-concept projects I delivered during my time there. 

How do you prove to PE and execs that what you’re doing is driving top-line growth?

I think the fact that they’ve hired an Interim leader in the first place shows there’s already some demand for change. They wouldn’t bring you in if they didn’t believe something needed doing.
 
Beyond that, you need to find ways to demonstrate value. Obviously, and especially with private equity, there’s a strong focus on the bottom line. 

In this context, it was EBITDA growth. That’s the measure of profitability after discounting the cost of borrowing. Ultimately, that’s what these stakeholders care about. The challenge is, it can take a long time to see movement there. You might make changes now, but they won’t reflect on the bottom line until much later, maybe by the end of the financial year, or even beyond.  

So, if you think of EBITDA as a lagging indicator, the key is to identify leading proxy indicators you can influence more frequently. Ideally, that’s daily, if you’re doing regular deployments.

That’s really the challenge: finding measurable indicators that show you’re making progress, even if the main financial metrics won’t move for a while. Typically, those proxies aren’t going to be invoices right away. You have to find other ways to demonstrate you’re delivering value.

This is a common challenge for any interim leader, showing impact early and often, even before it shows up in revenue or profit.

What were the biggest challenges or blockers you faced, and what needed to be in place for the implementation of this AI-driven solution to succeed?

An initial challenge was cultural. The team I was there to help were using what they’d always used because it had worked for them. The problem was, the codebase had become so old that iterating on it was increasingly difficult. The challenge was around doing things differently, experimenting, trying new approaches.  

Another issue was the way they were working. They were tied to a long-range schedule, always focused on delivering something far in the future. So if you wanted to spend even a day researching or testing something new, it was seen as a delay. That culture made people reluctant to try anything that might disrupt the timeline.  

So it was about unpicking that mindset. 

With AI adoption in general, I think people are rightly skeptical because there’s been so much hype. I even felt like I’d missed the boat. Every time I opened LinkedIn or turned on the news, it was just AI everywhere. It started to feel like a bubble.  When you’re trying to introduce AI, the key is to sit down with people, really understand what they do all day, find real use cases where AI can help and then show them. That’s what I did with the developers

I took this old, complex codebase they were working with, loaded it into the AI tools I was using, and said, “Let’s run an experiment. What’s a feature you’ve been thinking about?” They’d say, “Yeah, we were going to build this thing.” So we’d try it out with AI

Within minutes of prompting, the tool had generated some code. It wasn’t perfect, it hallucinated some bits, but it was enough for the developer to look at it and say, “Actually, yeah, this could help.

That’s what makes AI adoption real. It’s not about hype or abstract promises, it’s about showing people how it can help with what they already do. Let me see what you do all day, and I’ll show you how to do it a bit faster and more effectively with AI. That’s absolutely real.  

What practical advice would you give to other engineering leaders trying to do the same thing in a PE-backed business?

My advice would be to be a business person first and an engineer second. You need to speak the language of the business. Private equity particularly just doesn’t care about a lot of the stuff that is your day job, but what they do care about are financials, results, and EBITDA, so learn to talk in those terms.  

Learn to translate the value of what you are doing in all these bizarre three-letter acronyms into things that other people can understand. If you want to be operating at that level, you need to understand the language and understand how to communicate, but you also need to understand how to communicate with the engineers. It is almost like speaking multiple languages. This is how I would describe it. 

Looking to drive transformation without the disruption? Our network of proven interim leaders brings clarity, momentum, and results – fast.

Get in contact with our expert interim team to start the conversation.