Yasin: Welcome to Ctrl Alt Deliver. I'm your host, Yasin, and today we're tackling a big one: managing the tech landscape during PE-led or M&A scenarios. These are the moments that test technology leaders like nothing else: due diligence, investor pressures, team churn, and the dreaded system integrations. It's like being asked to rebuild a plane midflight while the passengers are still ordering their drinks. To unpack this with me is someone who's been there, done that, and probably written the post-merger integration playbook by hand, Yann Clutchy.
Yann is the CTO at Corsearch and has led tech organisations of over 150 people across the US, UK, Europe, and Asia, and all under private equity ownership. Before that, he was group CTO at Norstellar, where he brought together 4 different pharma data businesses all under one roof in a $2 billion PE-backed premiership. And then at evaluate he steered the tech transformation through not one but two PE transitions and multiple acquisitions. If you're facing an M&A, there's a good chance Yann's already survived a version of it, and he still has the energy to run marathons and raise two kids on the side. Yann, welcome to Ctrl Alt Deliver.
Yann: Thank you very much. Thank you for having me.
Yasin: So, before we start, it would be great if you can tell us about yourself, a brief background on what you've been up to. I know you've been in the industry for the last 20-25 years. If you can summarise your glorious two decades of experience in a minute, I would appreciate it.
Yann: Sure, happy to do that. My name's Yann Cluchey. I'm currently the Chief Technology Officer at Corsearch. But I actually started my career writing code. As a software engineer, I specialised in web technologies, and I very quickly developed a passion for data, databases, distributed processing systems, stuff like that. I very much like solving gnarly challenges with AI and algorithms at scale. And so that's one of the things that's been consistent throughout my career, an opportunity to get value from data. And started off working in very small businesses. I've been a CTO in a small company of 20 people, small startup style mentality, all the way through to much larger organisations, about 2000 people with global footprint, and so on. So yeah, quite a varied career, and I think I've spent the last 6 years of my time in the world of private equity, actually. And as part of that, I think I've probably done about 10 or 12, acquisitions, as well. So quite an interesting landscape, and I've been on both sides of the journey, both buy side and sell side as well. So yeah, quite a fun time, but ultimately I'm an engineer, I like building stuff and getting stuff done.
Yasin: Good. And this is the reason why we're speaking with you, Yann, today. I think we'll benefit a lot from your experience working in private equity backed firms, acquisitions, getting a lot of different companies, a lot of systems together, and working through the messy tech realities that all of these acquisitions bring. So looking forward to that discussion.
But before we get into the heavy stuff, you know, let's start light. Basically with all the PE deals and mergers you have been through, Yann, can you tell me honestly what's harder, integrating, you know, multiple different tech stacks or explaining to your family over Christmas what you actually do for a living, because I still haven't been able to do that.
Yann: Sadly, I've been in roles where it's very difficult to explain what I do for a living for quite some time, you know, it's never a one liner, I can tell someone at the pub. So, yeah, that's invariably I work in IT it's the answer I normally give. I think that's easily the hardest of the two.
Yasin: Yeah, I know, and I've resorted to the same Yann that, you know, I'm in IT. Once they hear that I'm saying IT, they don't want to know more after that anyway. So, yeah, that's it. Excel and PowerPoint, is my trade.
So let's start our conversation today around the topic and, we'll start off with discussing technical due diligence on both sides, the buy side and the sell side. In your experience, what's often underestimated in tech due diligence, and what are the red flags and green flags you've learned to spot early?
Yann: Yeah, it's a great question. I think when you're going through the diligence process, let's kind of put yourself in the frame of buy side. It's very easy to focus on the assets, right, so what's the tech stack, what are the applications, the databases, how much does it cost? I think one of the things that's quite easy to overlook is actually what's the engine room? You know, ultimately it's about the people, it's about the talent in the technology team, so how good is that talent, how well plugged in is it to the customer, to the organisation, how mature are the processes, the software development life cycle, and how, does the business have a good track record of getting new features released quickly, and how is that stuff measured, so they're kind of softer concerns, but that's a really important part. It's the lifeblood that then produces the technology assets that you're invariably looking at buying. So I think getting a good sense of that is difficult during a diligence process, but the more you can interrogate that, you'll be a lot better off.
The other facet, which is quite prominent in my current role, is around scalability. Invariably, when you're looking to buy something, you have ambitions to grow it, to scale customers, scale outcomes and so looking at a technology stack and trying to assess how well does it scale, how do we actually know whether it scales or not, invariably, of course it scales, but what are actually the limitations, it will always get to a point where things break, so how you know, what are they, how surmountable are they?
And then also what's the cost of scale as well, you know, something that can grow larger and take 10x the number of customers or data, great, but if it's going to cost you 50x to run, then that perhaps changes your ROI perspective. So looking at those facets, I think is key.
And then the other thing that's really important is in the category of stuff that keeps me up at night, is around infosec, right? I've seen countless times a lovely page of logos and so having lots of security tools, that alone doesn't mean actually you have a secure organisation. You need to look out for how are these things tested and how are they being externally validated, that's the kind of stuff that really makes a difference because it can just completely blow up your company if you don't get those things right.
Yasin: Follow-on question, Yann, on the buy side, when you're evaluating acquisitions, a lot of times the acquisitions could be around the product that they actually have. Most of the time, investors, management, they're very eager to go in and get the transaction done because there are a lot of business objectives in play as well.
Do you feel that you're usually rushed into doing that due diligence and there's no quick and easy way of doing it either because your due diligence on a large scale software solution can take time. It's not easy because a lot of times, it's religious choices, you know, I would have done it that way. It doesn't mean that the other way was wrong. How do you see that balancing that act, with business objectives and having not enough time to do your due diligence?
Yann: That's a great question. There's never enough time for diligence, so these things will typically always take you by surprise. An opportunity arises, and you need to jump on it, whether it's buy side or sell side. The timing is never usually planned well in advance, and invariably, you don't have a great deal of time to conduct the diligence, so you have to do the best with what sometimes can be a few weeks' worth of time.
So, I think it's important to, when you're trying to assess the technology, the state of a potential acquisition is to look at what are the key questions you need to ask, what are the things that would need to be true for that organisation to really fit with yours or to go and deliver on your investment thesis. And I think the more you can focus on those key questions, the better use of the time that you have with the target to work through those topics.
But, invariably, you will only ever have a limited glimpse of what's there, and it's only as good as the material that can be shared with you, and, you know, usually you'll ask for 100 things and bits of material, and you only get 20 back. So you have to make some key assumptions. I think the key thing is to call out where you have confidence, where you see risk, where there's uncertainty, what are some assumptions you're making and then that could then be factored into the larger landscape of consideration as to, hey, should we go forward and place an offer.
Yasin: Any cases, in your experience, Yann, where you know the due diligence actually uncovered a hidden gem or hidden nightmares usually?
Yann: Oh yeah, good question. Nothing quite so extreme, I'd say, I mean, invariably there's always skeletons, and the key thing is to try and gauge just how scary those skeletons are, and how big they are. I've been in a position where we've walked away from an opportunity, perhaps where what we assessed actually didn't really have the, the value proposition that we thought it did. The technology, the AI, sounds really good on the surface, but when you peel back the layers, you realise actually, it's not quite as exciting as it might seem. So nothing quite so extreme, but trying to sift between the marketing pitch and some of the reality. Those things tend to happen quite a lot.
Yasin: So now we'll move on to the people side of things, and you've already alluded to this: M&A and transitions are as much about people as they are about platforms. How do you keep your best engineers engaged when ownership changes and everyone's nervous about the future, because it's a time of uncertainty. You have an engineering team in-house already, and you're acquiring another team or getting acquired. There's always this uncertainty amongst the engineers about what's going to happen. How do you keep engaged with the new team coming in? How do you assimilate or make sure that they all work together in harmony?
Yann: I think one of the things that's really important to do when you're joining a new business, for example, particularly as a CTO is to very rapidly make an assessment of the talent that you have at your disposal, who's awesome, or who are the subject matter experts or key knowledge holders, and invariably when there's been a recent acquisition or a change of ownership, there's change of foot, the business direction may change slightly or we want to accelerate plans or accelerate the future. And so, trying to get a handle on who within the current group you would consider agents of change. Who's capable or willing to actually help build the future? You have some people in that camp, and then you might have some other folks who are in the category of maintaining the status quo or proliferating the present. If you can get a quick handle on where people sit in that landscape, it becomes easy then to see who are the people that are gonna help you move things forward and who are the people that you need to work with, but they're very much around the present day and perhaps you need to consult, but aren't the ones necessarily who are going to deliver the future. Getting that assessment is definitely key.
Meeting everybody is super important, building credibility and actually getting to know folks, and in the world of private equity, usually there's a big motivation around growth and driving strategic change for the business, and that invariably means either keep doing what you're doing, but let's go a lot faster, or maybe let's do things differently. I think the more you can engage the teams on what the goals are and what we're trying to achieve, the better. You'll have more people who are along with you for the ride, rather than, we've got new owners and we're doing something different, we don't quite understand it, you know, you kind of need to bring people into that discussion.
Yasin: Yeah, that's all right, and with acquisition and private equity investors coming in, it's always about how can we grow from here, what are the synergies that we see. And I'm sure that you have to make these hard calls all the time when you're evaluating, legacy versus modernisation. Do we stabilise what we have got, or do we bite the bullet and rebuild? How do you personally decide when to modernise, when to extend and when to make those tough build partner bipods?
Yann: I wish there was a rulebook that explained how to make those decisions easily. The first thing to do is challenge yourself when you're looking at this is what is legacy, right? And in technology, it's super easy to point to an existing system and find fault with it, you know, nothing's ever perfect. I'm guilty. I've written some code back when I was writing code, and then, you know, a week later, which idiot wrote that? So it’s very easy to find fault with stuff that's there and branded as legacy, and then immediately write it off.
If you try and take a more objective view, technology platforms which are older or maybe on outdated tech, that doesn't mean they're bad, or need to be replaced. And equally, I've been bitten by this before, platforms which are on the modern tech or newer aren't necessarily better. They aren't necessarily better built, and I've fallen victim of making that assumption before and then realising actually, there's a lot more work that needs to be done here because, yes, it ticks a lot of the boxes, but really isn't a scalable or future-proof kind of system. So, maintaining objectivity is important and just looking at what are you trying to solve for.
In the world of technology, you're surrounded by things that you could do, and the question is, where do you pick your battles? It's very easy to come in and say, right, we're gonna build a new platform. That's a super easy decision to make. It's mega hard to deliver, and it's usually very expensive, and it takes a lot of time, and usually 2 or 3 times more than you think it will, so it's something that you really shouldn't decide very lightly and be very considerate.
I tend to try and take a longer-term view of things, the landscape of technology you inherit when you join a business, is this the platform or could it be the platform for the future? The next 5, 10 years, does it enable the kind of growth, the flexibility, the innovation, does it enable AI? Does it meet all the criteria that the platform can work for us? And even if it has some fairly structural limitations, at the outset, are they surmountable, with a bit of investment, could you get past it?
And if you make the determination that certain systems are not, and you do need to go down the track of rebuilding or replatforming. Then I think you need to look for the stuff that's, you know, the legacy platforms, stabilisation, try and take as much cost out as you possibly can. And then for the future, try and focus as much time and energy on building stuff that's really unique and value creating for you. So I prefer to try and buy as much as I can, and particularly the foundational elements. If you need a data warehouse, pick one; they exist, there's many good options, it's finding the right tools out there and spend your team's time on building the bits on top of that. That really matters, you know, avoid doing the commodity stuff yourself. But it's a very difficult thing to get right. And of course, you know, time is never a readily available commodity, either.
Yasin: I think you said it very right that the easiest thing to say is, oh, let's just start from scratch and build it again. But one has to keep in mind that technical debt is built over time, and a lot of time, there are very good reasons behind it as well, because the business is innovating, the user requirements are changing. So when you actually first started building the product, and you fast-forward 1 year, you probably never thought that the market would need these new features as well, but the product was never built with that in mind. You keep on doing that, you know, after 5 years, 7 years, you know, there is a lot of technical debt that has been accumulated, but if the decision is to go back and do everything from scratch. Like you said, time is not on our side. It's going to take a long time. So you start building today, and you have the first version after 10 months, 12 months, you might already be behind from what the market actually already needs. The way things are moving now, the requirements are changing so often that there's never a right time.
We've been building products and software solutions for the last 20 years and evaluated many existing bespoke systems as well, and the majority of the time, like more than 90% of the time, the system is always salvageable, you can work on it in a very surgical manner, try and figure out what are the portions that are really causing problems in terms of scaling or latency, whatever that is and fix those surgically, and a lot of times it's those small things that if you can find them, if you're smart enough to narrow it down to those, you actually have a system which would have a longer life than you had anticipated. So I totally agree with you. A lot of times, refactoring, doing surgical fixes on the existing software goes a very long way. It's easier said than done, you know, let's start from scratch, but it usually doesn't work that way.
Yann: Yeah, you make an interesting point, actually, because I think that there's always been a temptation as technologists to go and use the latest technology and use the latest design patterns and architecture, and invariably, that comes with a lot of complexity. And in the CTO chair, I have to think about that. I also have to think about maintainability, simplicity, availability of talent, so there's a lot to be said for a simple solution that might be using slightly older technology, but it's commodity stuff. I could easily find skills on the market that can develop and maintain it. There's fewer moving parts, so there's a lot to be said for something that's just simple, fairly basic, but actually just works and is quite malleable, as opposed to a super duper new architecture that only 5 humans today can work on it.
Yasin: I remember, it reminds me of this time where a potential customer came to us. Their founder knew how to code in Ruby on Rails, build the system on Ruby on Rails, and he was having the hardest time finding Rails developers in the market, and he's like, oh, can you help us?
These are the type of decisions, you know, if you think that you cannot support it in the long run, if it's not that mainstream, then those are the decisions that actually call for hard decisions as to what you want to do for the long run if it's resources that you cannot find readily. It might be a good case that you start investing in something a lot more mainstream than going something very niche.
Yasin: The very interesting part about your role being in companies which have been investor backed and with mergers and acquisitions happening, you've overseen mergers where multiple businesses and their systems had to come together. What are some of the practical and cultural challenges of consolidating software estates across acquisitions?
A very tricky part, and I can't even imagine being in your shoes, Yann, like, it's hard enough managing different engineers on one team within one company, let alone doing that across teams, you know, new teams, new software systems. How do you evaluate? What are some of the learnings that you've had with time?
Yann: The first thing is, it doesn't make practical sense to chase standardisation for the sake of standardisation. Wouldn't it be lovely if everybody used the same programming languages and tools and databases across the org? And, perhaps I could get there with my current team, but then tomorrow we'll buy another business that uses something completely different. You'll find yourself perpetually trying to chase that outcome that doesn't create value. I think it's important to try to keep the stack as simple as possible. And have fewer tools rather than so many, and try to standardise because it promotes fungibility of resources and talent, and more people can work across the organisation. So that's kind of a good goal, but trying to standardise when you've got a company that's built from acquisitions, that's distributed, you have a lot of variation there, and you kind of have to work with it and try and raise the bar rather than trying to smoosh it together.
But when it comes to systems, this is super challenging, you might have acquired, one or more companies that have, either systems that need to be integrated, somehow, or maybe even duplicative functionality, you might have two different regional players that have very similar systems, they're not quite the same, and you get a tonne of efficiency just by having a singular one. It's a challenge of trade-offs. When you consolidate or integrate, you have the opportunity to simplify, to rethink some of your workflows. But the new kind of combined system, the new thing you build, or maybe you pick one and use that and adapt it, or maybe you build something brand new, but invariably it isn't gonna be all things to all people and it's gonna work differently, and chances are the MVP's gonna suck as well, so, it's a voyage of trying to figure out the right outcomes and actually saying no to a lot of things.
And when it comes to the underlying tech stack and tech teams, that can be super challenging, you might have a number of different platforms, and you might have to pick one or perhaps decide which are the best elements of each and somehow bring them together. There's a technical assessment aspect of that, and then you've also got people and emotions and possessiveness. I've been in the camp where I was the creator of one of those systems, and it was my baby, and I'd been building it for many years, and then, oh, hold on, it's at risk now because some other system, it kind of needs to get consolidated with. That can be very challenging to navigate the shields that come up in the teams, and you get fairly irrational behaviour and very emotive behaviour. I think the way to, to get through that is trying to maintain as much objectivity as possible, and to try and bring everybody on board, all the stakeholders from the different systems or platforms you're consolidating, bring them together, and have them be part of the decision-making. They might not all agree on the outcome, but at least they're part of that discussion.
That's a very different scenario compared to someone else has made an assessment and people are just being told what to do, and half the group are disappointed, you know, if everybody at least has got a seat at the table, they can understand what are we trying to solve for, what are the data points we're using to make these decisions, and I think they have a lot easier time, in doing so.
Yasin: Moving on to maybe a very difficult part of your job: balancing investor goals with tech realities. We all know PE owners; they want speed, they want scale, and they want the returns ASAP. Engineers, on the other hand, like us, they all want resilience, scalability, and to do things right and properly. You've often been the translator, and you've been stuck in the middle. How do you balance investor goals with tech realities?
Yann: That's one of the things I really love about my role, and in the world of PE, it's definitely a lot of pressure, but also it really focuses the mind. You're very clear on your goals and the time frame you've got to get there. So there's no room for any deviation from that North Star, if you will. I really enjoy that challenge. It's certainly not easy and invariably, you need to try and solve the day to day challenges of, I've got a bunch of legacy systems, I've got tech debt, I've got some fires to put out, and meanwhile I need to deliver the future, I need to innovate, you know, there's a lot of stuff and in the world of private equity, you can't do that sequentially, you kind of have to tackle these all at the same time.
For me, what really helps is to kind of call out that North Star. So, what are we trying to work towards, you know, in 3 or 5 years' time, what does the technology landscape need to look like in the company? What platforms should we have, should we not have, what does it need to be able to do? And if you can be really clear about that and what your goals are, that helps you in your day-to-day or kind of quarter-to-quarter decision making. It's a ton of really difficult calls because the stuff that's super important, but actually, unless it's progressing you towards those goals. It kind of has to take second place but being really clear about where you need to get to helps you on those decisions, and invariably it's death by 1000 cuts, everyone's always clear the big mission statement, but you can so easily lose time on, oh yes, but I had to spend 6 months kind of dealing with this thing over here. So, having that clarity at the outset is, I think, really important.
One of the things I like to do, and how I measure, is classifying dollars spent. How many engineering dollars are spent on just maintaining the present, right? So maintenance-type stuff. How much time and energy and dollars is spent on the past, i.e. systems which are legacy, we know they don't have a future. So how much are we actually spending on those, and that's all. Obviously, the line that you wanna bring down as much as you possibly can. And then finally, how much are you spending time and dollars on the future and on innovation and on AI and all the kind of good stuff that's gonna create value for the business. So if you can, if you can look at how you spend your time, your investments, your team's time, based on that, it's kind of quite helpful to go, right, these are the things that I need to be, you know, this is how you rebalance the energy of the team.
But the day-to-day practicalities are challenging. Every week, there are fires that come up, and you have to deal with them. One of the things that I find quite useful, even outside the context of PE, but just in general, the balance of the business needs new features and enhancements, and meanwhile, you have to pay attention to the technical debt and the non-functional requirements. I'm quite fond of carving out time for engineering-led work, so stuff that isn't directly new features or visible to the user, perhaps, but stuff that the engineers decide, yes, this is important, maintenance, scalability, optimisation, we need to upgrade this database to the next version and so on. You'll rarely get the opportunity to say to the leadership of the board, do you mind if we stop building features for 6 months while we go and do some tech debt remediation, the answer is invariably, no thank you. So you have to find a way to break it down and then kind of chip away at it as part of BAU. So if you reserve capacity, that becomes easier because at least then the roadmap decision making can happen with carved out capacity, and it becomes a bit easier.
Yasin: I really like your thought process around looking at how much you're spending on legacy. How much on business as usual, and then on the future stuff, that would actually help you make your decisions a lot easier to make. Finally, if you're talking to a first-time CTO who's about to go through an acquisition, what's the one piece of advice you would give to them? Like something you wish you had known the first time you were going through it?
Yann: I'd say to be prepared. When an opportunity comes up, or maybe a buyer's showing interest in your company, you typically get very little warning for that. So there's usually a fire drill. We need to get ready. And asking about the opportunity for time in the diligence process, invariably, there's very little time. The prospective buyer is going to want as much information as possible, and so on a number of occasions, that's translated on the sell side to a big fire drill. OK, we've got a load of material to write about, we have to produce a ton of documentation, and so on, the buyer's gonna want to know about the technology stack, the roadmap, costs, KPIs, all that kind of stuff. Probably in the category of things you should have had prepared before, but invariably, you kind of need to collect them all and probably write a bunch of stuff, as well. So, to maximise your time and opportunity to impress your prospective buyer, I'd say start working on that way in advance.
One of the things I quite like to do when I'm joining a new company as a CTO is I like to actually make a start and write diligence just for my own sake. As if I were a buyer, how would I objectively assess a company? If you can get into the habit of what are the things I'm gonna need to prepare and start thinking about those ahead of time, then it becomes a lot easier, and you can run through the diligence process a lot more smoothly. And given, I've been on many diligence calls, they often turn into Spanish Inquisition, so having the information ready, available, having a grasp on your data, on your systems, on your platform, and making sure you've got all the right people in the room, I think is super, important, because the buyer will not just be assessing the technology, they'll be assessing you, as well as a leader and looking to understand are you the right fit for the future.
Yasin: Right, now let's end with some quickfire round, very short answers from you. You know, I love this part of the podcast. So be ready. What do you think is the most overused buzzword in M&A?
Yann: Oh, that's got to be synergies.
Yasin: And I heard you say it earlier.
Yann: Yeah, often the reason you go to buy, and often the thing that gets forgotten.
Yasin: What's one system you would never want to inherit again? You don't have to name it, but give us an idea.
Yann: I definitely won't name drop, but there's a system that springs to mind that on the outset looked very modern, everybody loved it, but under the hood, the foundations were not stable, were not right, just mountains of technical debt, as well. So, that's something that's caused me a lot of sleepless nights and has taken a lot of work to fix. So, I won't name names, but, yeah, there's a few that's up there for me.
Yasin: Last question, if you weren't a CTO, what job would you secretly love to do?
Yann: Should my wife hear this, she'll probably laugh out loud. I think I'd probably quite like to be a gardener. I spend far too much of my life in front of a screen and locked in a room. I'd love to spend a lot more time outdoors and in nature. I think that's very appealing to me. And the reason my wife would laugh is because I don't do any gardening at all, and I tend to kill plants if they're left in my custom.
Yasin: You know what I was thinking when I was writing down this question, like how would I answer it? And Yann, you won't believe it. That was going to be my answer as well, gardening. I do love gardening. I spent quite a bit of time in my garden, both my front yard and my backyard, and even right after our call, I have to make some purchases online for some bugs for the spring, coming up.
Well, Yann, thank you so much for your time joining us. I think our listeners and viewers will definitely learn a lot from you because the type of job that you have as a CTO is very different from the majority of the CTOs out there. Most of us, we have to deal with one system at a time, one team at a time, but managing multiple acquisitions within an organisation, buy or sell side, working with different systems that you've not seen before that have been developed over time by different teams, getting them all together and making sense out of it and making it a success story is a very challenging task. I'm sure there are other CTOs out there who could learn from you because they might be going through this now or in the future. So hats off to you. You've been able to do it very successfully over time. And we appreciate you sharing all your thoughts and wisdom with us, and hopefully we'll have you soon on our show again.
Yann: Well, thank you, it's been my pleasure. I think it's important to share experiences. I've been fortunate to have a number of successes in my career. Each year, I fail all the time, as well, so I consider it a journey. We're always learning, and I think the more that we can learn from each other, that just helps. I've enjoyed the discussion today, and pleasure speaking with you.
