Uncovering Technical Debt For Better Technology Integration

Today's episode of the M and A Science Podcast is brought to you by insight. In today's rapidly evolving business world, staying ahead means embracing change and leveraging technology to not just meet but exceed your strategic goals. That's where Insight comes in. Insight is a comprehensive solutions integrator that helps organizations transform technology, operations and service delivery to future proof the business and innovate the client focused approach to delivery. They combine the power of people and technology to turn the biggest challenges into opportunities. Learn more at insight.com leave-legacy that's insight.com leave legacy onto the interview I'm Kisan Patel and you're listening to M and A Science, where we talk with deal professionals and learn valuable lessons from their experience. This podcast focuses on stories, strategies and what actually happened during M and A deals. Hello M and A Scientists. Welcome to the M and A Science Podcast where we learn from the best in M and A to uncover proven techniques for enterprise value creation. And if you're interested in learning more about how to optimize your M and A practice or want to get involved with our community of forward thinking M and a practitioners, visit mascience.com and subscribe to our free weekly newsletter. And if you want to keep up with us on the go, head to LinkedIn and follow M and A Science. I'm your Host, Kisam Patel, CEO and founder of M&A Science. Joining me today is Tom Hearn, VP of Architecture at Insight. Insight Enterprises is a Fortune 500 solutions integrator helping organizations accelerate their digital journey to modernize their business and maximize the value of technology traded on NASDAQ under nsit. Today we're going to talk about uncovering technical debt for better technology integration. Tom, how are you doing today?

Doing good brother. How are you?

Can we kick things off with a little intro about yourself?

Sure. So I lead our architecture teams, so what that means is we work with our customers on a regular basis, living in accounts, making sure we're taking care of their technical strategy, we're understanding challenges they have in their business and how we link that into technical strategy itself. And then that's also into when we're actually doing services. I'm doing work with our customers, making sure my team from a pre sales perspective is spending time with them to make sure what we're discussing is before we actually do any business with the company, how those requirements play to what we actually said we were going to do and what they're looking to get as an outcome for their business. I've got a background in a couple different areas. Software development, security, infrastructure. Later in my career. Cloud is part of that as well. Happy to talk through and have our discussion today. M and A is a huge aspect of many of the challenges that our customers are going through.

Let me make sure I got this right. You run a team of consultants that have a pretty broad background across all these technologies. This practice is focused on helping companies integrate, correct?

That is the name of the game for the entire team. And the technology landscape from Insight is we can pretty much cover anything from copper all the way through to the latest and greatest AI and ML.

Awesome. So hardware and software?

Yes sir.

I'm trying to get as much free information out of you as possible, learn as much as I can.

Happy to give it this the area.

That I haven't spoke a lot about is the tech IT side of doing integration. Maybe we can just kick off with a general how do you approach technical and security integration during an M and A process?

It's interesting because you talk about M and A strategies and the concepts like I've watched a number of your podcasts, Kisan, and it's fascinating to me to hear the different sides of the world. Oftentimes what is forgotten in M and A strategy is the complexity of technology integration. So think about gobbling up companies or merging companies or selling off to another organization, whatever that may be. Very rarely is the technological discussion had early on. Strategically, what are your security postures? Are you a cloud company? Are you a data center company? Most companies are in between somewhere in that space. What are your business line objectives? How is it connected to your business? And how do they drive technological decisions based on revenue growth or cost reduction or any of the other challenges that can be thrown in there as well? When we're talking through this with customers, we're usually pulled in too late. Honestly, we would ideally be in earlier. But the complexity of integrating 30 to 40 different partners and products and platforms across two organizations is extremely complex. Just the basic interactions that are had in identity systems so you know what you use to log into a computer, how those devices actually connect to secured interfaces, secured directory services. That in itself is oftentimes months of effort. If you have two different organization, what's the strategy of actually integrating those? Do we keep them separate and have higher technical costs of maybe 40 different products and platforms? Or do we integrate them and typically pay a little bit more upfront with a broader long term savings overall in the future? That's a really critical decision point for our customers and it's important they acknowledge and understand the cost of that. Early on, when we're getting engaged in an M and A discussion with any of our customers, we really like to talk through what are your actual business goals of doing this and what are your core goals as an overall business once you're integrated? Do you want to kill a brand, do you want to keep the brand together? Are you taking some staff, are you taking an intellectual property, et cetera. So broad overview, that's really how we look at it. We'd be working with them on the front end of those discussions and making sure that as we're going down that path, we're asking those prodding questions of where we see challenges on a regular basis.

There's a lot and I feel like there's like layers of details, lot of layers. So if I want to create just a couple big buckets, I wrote down security. Then you sort of have this infrastructure being cloud or on prem and then apps. Are we on the same page? Is that kind of roughly.

There's a couple other things we see in M and A on a regular basis, particularly in the manufacturing space and retail space OT networks. So like connectivity out to manufacturing machines to point of sale systems, et cetera. Significant complexity there. It's operational technology. So in the world world of manufacturing, very well known nomenclature. Outside of that, not so much. But really looking at the apps component of a business, the security component of a business, the platform on which those apps and security is applied, and then you have the concept too of operationally, how is it used. So your business teams, how are you interacting with the systems that an overall organization is providing technically. And that's very important. Oftentimes overlook the culture of how staff work at companies may be totally different than what an organization acquiring or acquired would operate in that function. So those are the four to me, the app side, the security side, the platform side, and then you have the operational or culture of an organization and how they work.

Got it. Okay. I think we're on the same page now.

Yep.

I was thinking it'd be fun to role play this out. We're going to change the scenario now. You're going to get involved early. In fact, you're going to get involved too early.

Yes, sir.

I'm this CEO that's going to do his first acquisition. So I'm new to all this. You got to imagine I'm pretty green and I'm also super cheap. I don't want to hire anybody. You probably hear that one. We're going to do it all in house. Nobody's got Other things they got to do, but besides that stretch, goal for the quarter. But that's okay. We're going to. We're going to use all those. So I want you to guide and coach me. We're a SaaS company. Our business, we sell deal rooms. Our main business, it's a SaaS product. And maybe we've identified another SaaS company that we're looking to acquire. And let's make it fun. Let's make this overseas. Where do we want to put it in? Let's put it in Denmark. We have a little SaaS company. Want to buy in Denmark. Coach me on this because I'm ready to do the deal where I'm at. Tom, I talked to the founder. We're starting negotiating it. I got an NDA signed. He's sending all these financials over. I got free reign. I could put my initial request and let's say that I'm just preparing that first request and obviously I put three years of financials. How many employees? What does a demographic look like? And some of the information about your key customers. Now I got this like IT tech request section. All right. I'm kind of looking to you with like a deer in headlights. What do I do? What am I asking for?

Why are you acquiring this company?

The new product. I want to bring this product line and add it to our portfolio. So I do want to keep their customers and I do want to keep their employees. And we're going to probably integrate this product into ours. So that way it enhances it as part of our platform play.

Okay, do you have a team, an IT team today that works in integration system services, that is aware of pulling in or acquiring companies? Or is this your first time doing that?

First time doing acquisition, and our team is like the typical scrappy. Got a pretty understaffed engineering team. They're very much focused on our current development, which has all been organic in house. So this is going to be the first time we actually acquire and bring a business in.

Okay, so first time acquisition, no significant IT technology team that's used to doing integrations. The challenges that come with that. If you didn't have any help from anyone, how would you approach this?

Today I would just do the deal until the team figured out. Okay, I'll bring this up. The reason I'm talking to you is because I have concerns. I have concerns that I don't quite understand this term. Our engineers use a lot called technical debt. Maybe we can talk about it because they say it a lot and I'm not Quite sure what they actually mean. And they're always scared about that. Cause they talk, they complain about our technical debt and they actually blame me for it as a founder, which that's a whole other conversation. And then there's like when you talk about doing an acquisition, they talk about like more technical debt and technical debt with that company. So there's that part, then there's the security. Because we've matured to a pretty high security standard in our organization. And if you look at this company, I can only assume, and I know our practice is we're dealing, we have like Fortune 5 companies as customers. We have to adhere to the highest level of security. So it's a concern that immediately do we have some risk to get this company up to our level? I would say that's probably the biggest one. And then there's migration. If we're going to integrate this, we have our hr, some of the sales and customer information. We want to be able to really combine those systems because so much of what we're betting on is cross selling. So I want to make sure teams get access to the information and it's not like a big bottleneck. Sure.

First thing, I always ask our customers if you're familiar with the iron triangle of project management. It's the concept of cost, of scope and of time. There's always those three in any project, in any execution, in any merger and acquisition, etc. And they're always shown in a triangle. And I always ask our customers to think about this as it's on a seesaw now. So take those three balls and put them on a seesaw where it's going back and forth. You can spend more money to have less time or less overall scope. You can increase scope and have less time. You can make all these mixes and matches. The reason I talk about this is the concept of technical debt is it's never a finite math equation. It's a balancing act. So you have to be aware of the strategies and contingency plans around. You said you don't have a lot of money to spend in this. That means your time and your scope is probably going to increase to actually complete execution. Your cost will go down, but you have to balance that seesaw. So really important thought process to think through. There's no right or wrong answer. The answer is balancing effectively. So you said a couple things in our discussion already that to me are critically important that I think you need to be aware of. One is Denmark is a GDPR enforced country. So you have different security requirements. In the EU than you do in the United States or many other countries. And in the case of gdpr, it actually requires some ability from a technical perspective, from a data storage perspective, from a security requirements and compliance perspective, and there are significant fines and issues if you do not enforce those. So data locality from a platforms integration perspective is very important with a GDPR based country. There's many others as well, but the EU was really the first one to establish that. So something you need to be aware of as you're. Let's say you're running on Azure in your environment today and that company that you're going to acquire is all on PREM data centers in Denmark. You now have to make some decisions of how you integrate those. So we talked about identity a little bit up front. I would highly recommend you work through with our team the identity systems. So if they're on, let's say Google Workspace and you're on Azure or active directory, Windows, Office 365 et cetera, there's some challenges of integration in those systems. That's a huge one you need to look at very early on because that's how you share calendars, you share email, you share authentication, you give access to applications before you integrate them across those two companies. Second one, from a security perspective, you need to understand the platforms and connectivity of how those either SaaS based systems or data center systems are working together. So that's a discussion about SD wan, that's a discussion about your firewall platforms, how they communicate, what you allow access to, how you have VPN connectivity in between those two environments. Very critical to understand early on because the licensing costs of purchasing two different solutions is always going to be higher than having a single solution. So back to that seesaw you really need to understand, am I trying to just run two systems that has a complexity of operations to what we were talking through before? Now your security team needs to know two different tool sets, two different platforms, two different user bases. It's okay to run that way, but that's an acknowledged cost that increases your resource management of those environments. And then we need to move on to what is your shared data in those sources. Do y' all have a CRM you use today?

We're using HubSpot.

You're using HubSpot. So do you know the acquiring company in Denmark? Are they Salesforce, are they SAP?

They're using Excel, Tom. Like they're way behind. That's why we're getting a big deal in this company.

So that's a space from an organizational Change management perspective, then this is not just a technology discussion. That's also how are you going to change that organization to work into your environment and your culture? So if they're running in Excel spreadsheets today, we need to do some level of analysis of how effective is that working. Are we spending all of our time trying to do Jiu Jitsu and Excel or should we move those teams and educate them on how to integrate with HubSpot that y' all are using? Big part of the discussion there. From a data view, the next piece of that moving on is we talked about email and identity a little bit. Now we need to understand are you going to merge domain names, are you going to merge email addresses? How are you going to integrate the security context multi factor, making sure your users aren't getting phished, your security tooling From a end user perspective, do you have any view on what they're using versus what y' all are using today?

No.

So definitely need to do some more digging on that one. The other piece too. From a network connectivity perspective, how much data do you have to share between your two organizations?

We want to eventually share the whole customer base is the big thing.

Okay. When you're sharing the customer base across.

Organization'S gotta all come together. It's all going to come together.

The network connectivity there back to the software defined wan. If you have direct circuits in between those environments, if you're using like a cloud brokerage for connectivity in your Azure environment today and then the data platforms of how you move that. So if you're in native Azure storage today, they're in an on prem data center. We'll just say one of the big storage providers, the big four or five. How are we moving that data and synchronizing that data? And long term, do you want to get rid of that data center in Denmark and move that into Azure or another cloud platform? Making sure that we're understanding the protocols that they're using to talk, how we're moving that data and the complexity of accessing that data after it's actually moved. Because one of your big cost factors in a cloud environment to data center environment is the cost of bandwidth and data movement. Very challenging for our customers to navigate that and often very difficult to actually understand what's causing that cost increase. If data is moving back and forth, do you have any AI ML either something like an off the shelf copilot? Do you have any of your own custom machine learning models, customer models, anything like that you're working with today?

We're primarily using GPT4 right now and we build our own model on top of it to dial it in for M and A use cases and. And then we're agnostic on those LLMs because I think they're experimenting with another one for a certain use case.

So a couple things you said there just to call out. One would be anything you're putting into ChatGPT. Still a little bit of lacking clarity on what's being done with that data. So you need to be very careful about disclosing any intellectual property or customer data into those prompts. Number of things we can do in that space. From a data platform perspective, prompt logging for awareness, understanding how you're fine tuning and controlling that model, or in some cases pulling that model into your own. That's not using a publicly available interface or API. The second piece on that is from a GDPR perspective, once again, much more complex. You need to be careful of how you're using that data that's coming from the company in Denmark if you're disclosing that information and can't allow them to remove that information from a regulatory perspective. Something you should absolutely be aware of. But I think we should have a deeper discussion with some of our data science teammates and AI experts to help them understand what you're trying to achieve with that model and how we integrate the data that you're getting in a different format from the company you're acquiring into the data model of what you're using today based out of HubSpot or other data that you all may have in your Azure environment.

You might if we use AI internally. So I gotcha. So that's both we have it internally and then we also have it in the application itself, which probably opens up another can of worms.

Whole different can of worms. As always, it would go something like that. Kisan, from a introductory discussion, things we want them thinking through. We're always highly aware of the number of different platforms a customer has. So like how many data centers does a customer have? How many cloud environments do they have, or more importantly, cloud accounts? Huge percent of our customers today do not just have one cloud provider. Most of them have something in aws, something in gcp, something in Azure or some of the others you add in Oracle, you add in a couple other competitors out there. And then the data center perspective. We're very interested in the complexity of connectivity between those environments because network connectivity between those environments is usually the first thing that is a challenge. That's the first delay that specifically for customers that have physical locations the time to drop in a fiber circuit or get connectivity to a data center can be months in some cases. When you get through a M&A strategy, you're going as fast as you can to get Finance and NDAs and reporting and all these things sorted out. They'll often get through that as fast as they can. And then they go to the IT team and the IT team's like, whoa, man, we need like six months to get these systems talking. If they just would have started earlier, it would have saved them a tremendous amount of time.

You know, it's tricky about this is that I'm trying to get to an LOI signed as quick as possible. I'm going to ask them like a two or three tech questions and that's it. Now, based off of that, if we know how to grab a conversation and really talk through it, just to make sure we don't have any big red flags, because some of these things, you know, incremental. We're talking about, here's a $10 million business I'm going to buy, but we're talking about 50k, 20k here, there, there. And I'm like, all right, we're talking about 50k real, not a big deal. We're talking about a hundred, two, fifty.

They add up quick death by paper cuts.

But now here's the caveat. We don't have time to run through and do super deep diligence. I'm getting the impression that right off the bat I should start mapping this stuff out. Like really understand what servers they're using, if it's on prem, the applications, the key applications using, and then some of the operational software that's expensive. So that way we kind of know like, oh, we got apples and apples here and we got apple orange. So that probably gives you a quick glance at, oh, right away like this. Obviously, major ERP migration is going to be long and expensive.

When you're talking a Fortune 500 company that's talking about moving SAP to Salesforce, for example, those migration projects alone may take two years at a very aggressive pace, may take two years, different scale and scope and challenge. But when you get these systems, oftentimes the bigger the customer, the more integrated the system is to how they actually do business. We talked a little bit about manufacturing, a little bit about retail, et cetera. You cannot touch ERP systems in those environments because they're utilized maybe even by the minute versus hourly, by everyone from the CEO all the way down to someone who may be packing and shipping on a floor at a distribution center or making a engine at a company, or all these scenarios that they're so tightly linked into the business itself. Those are significantly difficult challenges to understand. Not just technically. The technical part is, quote, easy, but the operation side and how they're using systems is very complex. And we oftentimes find the customers we're helping address these issues. They don't even know their business process or it's not documented, or in the case of it is documented, it's 10 years old and it's not accurate for them. So if you make assumptions based on those, your costs can be explosively high and very much so unplanned if you're not starting early in that process of discovery. One other piece we didn't talk about heavily yet. When you have M and A mergers and acquisitions, it is common for IT staff, if you will, to be impacted. One team goes away, you merge teams, maybe they stay the same for a while. We have seen on an increasing basis when acquisitions are announced that those companies become targets of bad actors, if you will, because there is an awareness of some level of chaos and some level of lack of knowledge of those two organizations combining in their IT footprint and stance. So think about a scenario where we both have a company. We're two Fortune 500 companies. You and I have been extremely successful in our careers, and we're now merging those companies. That's a publicly disclosed merger, sometimes because of reporting requirements, sometimes because companies want to get it out that they're acquiring. The strategy of when you release that is very important because if you and I are now running those IT teams and we just hooked up our systems a week ago and we start seeing some weird activity, we may just say, oh, that's normal. That's what Tissan's team is doing. We make an assumption. Assumptions are very dangerous in mergers and acquisitions. If you have an incident in the middle of that and you now have to do a full scale ransomware recovery, for example. Our teams have never worked together. We don't know our systems, they're different platforms. We don't know how to cross each other. There is a significant complexity in awareness very, very early on. I think most companies would probably have a CIO or a CISO involved in acquisition discussions, but rarely do they get to a strategic posture where they're saying, here's something that we actually need to be talking about. What happens if day one, when we plug a network cable into each other's networks, whether that's a cloud or a data center or wherever else, what happens if we have an incident because oftentimes IT organizations, particularly when they start planning later, they won't have an awareness of each other's environments until a year or two after the fact. And a lot of times that's just passover crossover knowledge that they get through discussions. It's not documented. There's not high awareness of challenges, there's not high awareness of maybe where they have weaknesses to a security posture, et cetera. So all of these things very critical for what organizations to be thinking through really as we talk mergers and acquisitions in general, regardless of the size of the company.

You're opening up more cans of worms on me, Tom. This is stuff I don't want to think about so early. You know, we're building out this model of how much to pay and the assumptions, is a good point that we make a lot of assumptions around what's going to be the cost to integrate the businesses, what's going to be cost synergies that we would recommend receive from combining these businesses. And I'm. I'm curious about that in terms of your take. I feel like we just really ballpark things. I'm curious to get your sense of view of you've been involved with that. Do you ever try to dial that stuff in or.

Oh yeah, on a regular basis. And there's two kind of core components that impact the cost specifically from an IT infrastructure integration perspective. So the first one is the industry has drastically changed with the introduction of cloud and the concepts of cloud. So the concepts of throw a credit card at something and it just bills me monthly. Great concept in theory, not so great for a CFO that's trying to understand a budget and maybe the team doesn't understand how they're spending that money, which is a very dangerous thing. We have seen over the years that sine wave effect of we're taking everything cloud, we're going everything we, we would call it repatriation back to the data center. Now we're going cloud again. The answer is really somewhere in between. The reason I bring that up is the complexity of managing a data center in a traditional sense was entirely capex based budgeting. So we would purchase data center infrastructure, office infrastructure, whatever that may be. We get licensing the hardware, the support and renewal and we do that on a three to five year basis. And we did that because we knew in three to five years we'd need to replace that equipment for a variety of reasons and. Or if you don't replace that equipment, that's where you end up with technical debt and Complexity as you're going down that path, that's a very structured three to five year strategy. Now you introduce the concept of cloud that is truly an operational spending capability. You're going month to month versus three to five years at a time. The challenge we see with our customers is when you're trying to merge those two budgets. If you say I want to move everything to the cloud or everything to the data center, you're now essentially double paying for three to five years as those licensing and renewals roll off. Now you have a cost in cloud. How are we going to handle that as a business? The infrastructure, traditional infrastructure industry has responded with as a service consumption models for data center infrastructure. Think of it as I'm buying some compute and storage hours from a traditional data center platform versus buying a three to five year cycle that's allowed us to offset that. But understanding the complexity of those two is very hard, particularly in mergers and acquisitions. So concept of finops or financial operations, hugely important, very important to the overall strategy of an acquisition. So understanding very early on, what is your current spend in CapEx, what is your current spend in OpEx and what is your willingness to vary those as we go through an acquisition, most organizations will have some office equipment and maybe some cloud environments and a little bit of data center. Assuming you're now merging another company in with the same footprint now you've just doubled the amount of complexity of the renewals and the CAPEX and OPEX spend and the operational cost of those. That's the first piece is understanding where your current landscape is. So we would always start and say, let's understand where you're at today. And the level of detail we go to is equatable to the level of accuracy you get. So if you were to call me today and say, tom, help me work through this acquisition of a company in Denmark, I'll give you two hours. I'll probably tell you, I'll give you a gut check. 40 to 50% accurate budget of where I think you are in a couple hours. Maybe that's not even maybe it's a 10% accurate. Then if you say let's actually do a real engagement to work through the nuts and bolts of this, get into details, I can give you probably an 80 to 90% accurate budget, acknowledging that in any merger and acquisition there's always unknowns that are going to come up regardless of how well you plan an insight nomenclature. We would say you assume vuca, which is volatility, uncertainty, complexity and ambiguity. And we would always assume VUCA in any type of M and A to a certain percentage. So that's the first piece. The second piece of that is now you need to understand what their next goal is strategically. So is the strategy of Kisan and this acquisition he's going to do to eventually kill that other company's IT footprint and merge it into ours, or are we going to operationally run the two of those together long term? Data wise? Statistics would show us pretty consistently that if you operate two different tech stacks, we would call those an Azure environment and then a data center. If you're going to maintain those independently in perpetuity, your cost of operations and your cost of licensing will go up over time higher than it would if you're going to merge those two environments. Now, the upfront cost of merging those two environments is going to be higher, no question. So for most companies, that decision is, if I ask any CEO in the world, would your goal be to have a unified, consistent platform that operates efficiently and is cheap, they're going to say yes, no brainer. But the reality is sometimes the cash flow through an acquisition, the ability of a company to move data and get financing during an acquisition is often impacted by the risk of that acquisition. So they may make a strategic decision to say, hey, we're going to take on technical debt of managing two different organizations at higher cost for two years and six months from now, we're going to start the formalized planning to modernize that and centralize that in the future. That is all into what is your budget and what's the team's technical capability to actually do that Migration or transfer as well. So in the case of Insight, we would say we can either do this soup to nuts for you, we can do the whole thing. That's really realistic that a customer would just say, take our destiny and run with it. We don't really want to do that. We want to understand their business and, and we'll offset the lack in skill sets where they don't have it and we'll give guidance and oversight. As we're seeing project risks, we really want to be running that roadmap of what should we be hitting. Maybe not monthly, but every quarter, we need to be at this place. So maybe in three quarters from now, in our new acquisition that we just went through, you want to have an integrated email environment that's running on one platform. That's a quote, easier move than some custom applications, if you will. And then maybe in six quarters you want to have half of your applications out of a data center. And into a cloud environment. Then we can work backwards on the cost and the effort and labor required to do that. Does that help understand the cost thought process?

Yeah, it sounds like there's a whole.

Spectrum from it's tremendously complex.

It just rages, either do nothing or do everything. And doing nothing is a terrible decision.

Think of it that this iron triangle of project management, that seesaw concept, really helps our customers when I use that with them. Like the perfect world doesn't exist. There's always time, there's always effort and there's always cost. It's the optimization of what's working for your organization to get a strategic advantage to be able to earn more margin and be more profitable. It's how you optimize that in the context of the businesses you're acquiring. And it's fascinating to me like we talk through this with our customers. I talk about this all the time in the context of Insight. So I've been at Insight for seven and a half years now. We are constantly merging and acquiring other organizations. And we've tried a different spectrum of integration. We've tried very isolated organizations that run as a business unit for a while to see how profitable that is. But there's downsides to that that you get less integration with your legacy customers. We've also tried, we acquire a company and we throw everyone into the mix immediately. We kill a brand and we integrate all their systems. But then you actually demoralize teammates in some cases. The truth is always in between. But we live this ourselves on a regular basis and we just acknowledge as an organization this is required in today's world and business that you're either acquiring or you're getting acquired. And the thought process of how you work through that technically is tremendously important. For my team, I've got a team of 210 and. And it's really important that they are aware of these challenges for our customers. And we'll even pull teammates from around the country or different regions or teams because they may have more domain specific knowledge in a certain industry. Retail or manufacturing or security and government, et cetera.

I just want to make sure I got this clear. You actually do acquisitions as a company and you're pulling in those learnings from your own acquisitions and transforming it or enhancing your practice with it?

Absolutely. On a regular basis. We've had two decent size acquisitions this year alone.

You know, it's really cool, Tom, because you'd be surprised. I talked to a lot of consulting firms that do acquisitions and learnings do not translate over I'm not kidding, like, it's really rare. I've been a lot of roundtables, done a lot of podcast interviews. I've talked to folks, a lot of these big top 20 and even work with some of them directly. And you'd be so surprised how much of there's a wall between their corp dev versus their own consulting practice.

Myself and my team, we're in an unfair position, if you will, or a really good position, depending on how you look at it. Because we do work with our customers in similar challenges to what we're living through. So particularly in the technology space, we're just in the right place to be able to learn from those lessons learned either good or bad. And we have a very community driven team that we are sharing regularly customer stories of. It's from an excited perspective of oh man, Tson, I just got on with this customer and man, they're a mess. But look at what we can do here. And we recommended they do this and we got this challenge that's a really good place for our team to be. And Insight does a really good job of merging very intentionally our pre sales and sales organization with our internal IT function. So a lot of crossover functions that we work with each other and customers and on internal IT initiatives to make sure that we're sharing that knowledge and utilizing that knowledge. Because if we're not doing that internally, how can we tell a customer to do that? That's a big challenge.

True. Hey, so back to the Denmark deal. Like, I'm pretty interested, you know, a lot of stuff I can tell you'd help me, but in terms of like working with you, was it you said two hours up front is that I don't pay for that. You're going to help me scope this out.

Initially, my team is a true pre sales team. So here's how we've always operated in this. We want to make sure what you're trying to do aligns with we can actually provide you what you're trying to do. So we want to be honest and upfront. If you come to me and say, tom, I need to build a nuclear reactor, I'm probably going to say probably not my best place to help out. But keep the relationship, help you, help you, support you the way you can. But the majority of the time when we're coming in in an IT focused view and mixing in that business side, my team is working on what we would call the pre sale side. So our team is completely free, if you will, to the customer and our job is to make sure we're solutioning and designing and helping you through to build that roadmap. If we do our jobs well enough, we would like you to buy services, product, etc. From Insight, but that's on us. That's on us to do that job successfully enough to show the value. Which is why we share the thought leadership so that our customers will say, hey, that keys on guy seems pretty sharp. I should probably get in a discussion with him and see where it leads. Then we would have services. Once we had scoped that, understood it, knew that the challenges inherent there, we have billable services, et cetera. If you actually wanted us to do the work itself, I mean, this Denmark.

Deal, I'm going to pull the trigger on it. Getting close to loi, I give you a buzz, we have a quick talk. You run through me a bunch of stuff. I'm like, all right, my head's spinning, Tom, you know, I'm going to let somebody look at it. You send someone from your team and they start giving me initial assessment, hey, stuff we just talked about. But what about to that point where it's like, hey, to get towards that 90% accuracy, there's some real work to be done. What does that like, engagement look like?

We would have a scoping discussion as part of that pre sales conversation. We're going back and forth, we're working through, you know, Tom, you seem like, you know one or two things. I'll be careful to say I'm smart, but I'm very, very determined. But you see a couple things. My next step there would usually be, hey, Kisan, where do you live? Let's get face to face on a whiteboard. I want to get on a whiteboard and understand that's free, if you will. I'm not charging you for doing that. I want to get on a whiteboard with you and the teammates that are stakeholders and decisions that have to be made through this process. So let's get on a board, let's draw some designs, let's call out the risks, let's call out the things that we need to dig into more to get further details. And we can use that to. If you say, Tom, great discussions, I like what you're saying. We'd like to actually use you to do these services. We would take that back to a service and scoping team in our service delivery organization. They would help us figure out the cost, the risk, the scope of that engagement. Wherever that technology stack may be, there may be some products or some firewalls or devices, whatever that may be you need to purchase as part of it as well. And then we would come back with that total cost to the organization and something that we also do as an organization. That is why I came to work here. I was actually a customer of insight for 10 years is our pre sales architects. So my team today, my team and many others, but my team just focuses on pre sales architects. My team actually follows through into execution for oversight. So why that's important to you as a customer is you and I will have a lot of discussions upfront on a whiteboard, etc. I'm understanding your context, your business challenges, maybe getting some of those statements from you on the side like hey Tom, and this one we really can't mess up. Super focus here. Very important to have that context of the customer concern and their stress level. I would also be following through to once a delivery team was engaged to do that full set of work to make sure that the team is doing what we said we were going to do and they're getting those pieces of context and oversight. And I'm still working with you as they're doing that as well.

Sounds like you do free diligence.

We understand that the importance of a quality outcome from our customer is getting our long term business and relationship there. And we will invest very unhealthily at times to make sure that our customers are getting the right outcome. Because we're not just trying to come in, do one service and disappear. We want to maintain relationships.

Fair enough. All right, Tom, I'm going to ask you for a favor. Put the consulting firm cap off for a second because I'm just like as a friend, the one of the things like biggest hesitation because I've been burnt on some consulting firms and it sucks when you do. The cost is probably the biggest thing I'm always afraid of. Just like anytime you engage, it just ends up being a lot of money to get into it. How do I manage that? You know what I mean? Like you're been in the industry for a long time. I know I'm asking for a weird thing and obviously you want to do what's best for the company, but truly you actually know better than anyone else by nature, a lot of services firms sell you more services than you actually need. The whole game, everybody's got to increase their numbers every year. Help me out there. Like how do I.

So I'll put on my customer hat of, you know, before this is the first job I was ever in in an organization that we have a consulting group in our organization. But we would call ourselves a solution integrator, not a consulting organization. Just because most consulting organizations don't take product platforms resell into account the way that we do. So we're trying to operate in between a traditional VAR and a GSI in the big players very intentionally. It's a strategy of ours that we want to make sure we're hitting because of our ability to maintain a long term relationship. So once again we're not charging all of that cost up front to a customer for a pre sales engagement because we may offset that with the sale of product or we'll get services as a piece of that. That's okay as long as it's a two way relationship. Which leads me to answering your actual first question. So when I was a customer I would just be very transparent with the account manager that I had and the architect that I had. So in the case of my team, that's the architect. The relationship between the technical teammate and myself was way more important than the selling relationship. I may be a little biased to say that if there's any Insight sellers watching this, don't hate me for saying that it's not that role isn't important. It's that the technical team should be telling a customer what to buy. The seller should be saying how much. And that's really important. My team is not a commission sales team. So we are not there. We are paid well, salaries, et cetera, to make sure that we are taking care of our customers. Because that's our strategy as an organization is to really focus on relationships. So what I say to our customers and the customers that we work best with, it's honestly the customers who are just as transparent with me as I am with them. If I'm going into a situation. I remember when I was a customer of, it was actually a company that Insight acquired, but it was Insight now. We had a very large data center migration project that we were doing. Most of my team's background was security and software development. We had a couple infrastructure people, but I needed them to go. We were taking three managed data centers and a couple cloud environments into two of our own full colo locations. The reason we did that was some regulatory issues at the time that we had to address and work through. And they weren't as comfortable with cloud as they are now. When we went through that process, I went to the team that I worked with and I said, look, we're going through a vetting process. We went with three different partners in this case. We asked them their costs, we Gave them a solution set we wanted them to come back with. We would negotiate back and forth with them. We'd say, hey, if you can knock this off and give more up over here, it'll level us off. It's that transparent relationship between where were we willing to put technical debt risk in a platform versus a service engagement and having that discussion with them. Now, some customers are not comfortable sharing any type of detail around strategy, et cetera. But that to me is actually a good telling sign up front with our customers. If they're being open and honest with me, there's a really good chance that we're going to work really well as a team and be an extension of their team, which is something we want. No customer in the world would come to me and say, hey, Tom, we've got a budget of $45 million. What can you do with that? I also think that would be a really bad strategy from the customer's perspective. But understanding when we're talking through that, how aligned are organizations, how aligned are our cultures? I can tell in a couple minutes with a customer if the culture of how they operate is a culture that will mesh well with my team, that's really important. And then the other side that we do very intentionally, if we do have a discussion with a customer and the customer's like, this architect's being too aggressive on this one piece, or they're not being aggressive enough, we have geographic teams that support regions we'll rotate architects in. And that gives us an ability to pull in A, different personalities and B, pull in different technical backgrounds and skill sets. So some may be in cloud, some may be in network, some may be in storage, et cetera. Very important for us to have diversity of thought process moving in and out of that customer account. So we're addressing those challenges and really giving them thought leadership. So my biggest answer to that, Kisan, is really be honest with us. Let's say you call Tom today. Here's what I want to do. More importantly, here's what I don't want to do. Because I think oftentimes customers tell us what they want to do and we start ideating and whiteboarding and coming up with all these awesome ideas that we've seen successful at other customers. And that's our value, is we do see what works and doesn't work at customers. But if the customer doesn't explicitly say, don't do this and focus here, it's really difficult for them to understand. Why is Tom talking about AI and ML When I asked him about how Do I get a network device in my data center? Very important. That trust is two way and there's open communication there. We're also big proponents. One of the last things for us. We're huge proponents of let us knock one small thing out of the park. I don't need to come in and get a $500 million engagement with a customer. That's not how we look at success as an organization. We look at success as we started really small on one thing. Very explicit, super focused skill sets or expertise in a certain space and we've got a lot of them. And if we're growing and adding value and we knocked it out of the park, that customer is going to know that, hey, Tom said we would do this successfully and we did it successfully. So now I want to work with them more and continue to build that trust.

It's a good point.

Hopefully that helps.

Be honest. I've been honest with you.

I told you I'm cheap, honest and transit. No, you did. You did think the seesaw cheap works. But your implementation time and your complexity goes up.

When I started negotiating the hourly billable.

Rate, it's exactly we do from a costing perspective our organization, we do fixed sows with higher risk and we do variable hourly engagements. We'll do all sorts of stuff. We can be very creative in that space. But ultimately, at the end of the day, if our team is not being dynamic and adding thought leadership and value, truly we don't just get to go in and say we're fancy and I'm smart and I add all these things. We have to go in and roll up our sleeves, get in a ditch with a shovel and earn our right to do more business.

That sounds cool, Tom. I definitely keep you in mind on this Denmark deal. Good part of doing vendor diligence is asking for a reference. Do you have like a little quick story you could tell on just iroi that you've kind of what's the big win that you've been most proud about?

That is a loaded question. So yes, I do. There's a lot of different examples, but one for me, probably the one that I'm most proud of actually was a security incident we helped respond for on a customer. ROI is a little different in a security context and I need to be careful not disclosing information we can't. So you could indirectly correlate who it is. But I will say that from a security perspective, we have done a really good job as an organization adapting to mixing pre sales resources on my team. So from A customer calls and we've got an issue getting immediate teammates involved that are knowledgeable of that account of the relationship of the technologies, very dynamic and where we can go depending on what they have in their environment, cloud or data center, and then the ability to also have an aspect of remediation, virtual ciso engagement and response, forensic teams, et cetera. The ROI on that for our team compared to some of our competitors I will say is extremely impressive. And I don't want to go into further details on any of these examples because I'm worried I'm going to say something I shouldn't. Fair enough, that's one. The other one is just at my personal career since I've been here I've done some projects in a lot of manufacturing. We've had some amazing manufacturing modernizations with our customers that I've personally been a part of and the team has done an amazing job supporting around taking a manufacturing organization that was very far behind as far as IT operations were concerned, literally down to spreadsheets and in some cases printed spreadsheets for manufacturing optimization. I started some of those projects six, seven years ago. Fast forward six seven years. They're some of the most modernized, accurate machine learning driven manufacturing organizations we work with. Won't give ROI numbers in that case, but I know what the ROI is and it is paid for itself probably 50 times in full. What we've received from that A lot of work in the AI ML space recently, specifically around Azure based business, a lot of endpoint based business copilot, et cetera. Multiple awards we've gotten there recently and our data and modernization team continues to do amazing work which is usually the hardest part. Data gravity in the words of our CTO Juan Orlandini. How close an environment is working to the data is so critical and we have an amazing team between more modern data AIML as well as data management platforms that the ROI in those cases has taken 70, 80, 90 sources of data sets from our organizations and turn them into one or two usable sets that we can process for machine learning through ERP systems, etc. So a couple examples there. I didn't go into extreme details just because I want to be careful saying things, but those are three that come to mind immediately.

Very cool. Tom, what's the craziest thing you see in M and A?

I've seen two crazies from an engagement and operational movement perspective. One is the day that a public company announced a integration. There were devices, platforms and new IT staff shipped out to every office of the acquired company. Little aggressive but very fast integration times. And I've also seen organizations that continue to operate in pillars on the opposite side of that spectrum for 10 plus years after an acquisition. And when we do the financial analysis of the cost and the tech debt cost, operational cost, staffing cost, it's literally costing them like six or seven times what it should be. So broad spectrums. No CIO or CEO ever wants to hear we're paying six or seven times as much as we should be right now. Nor does any CEO want to hear no one's working because we ripped our entire network environment out the first day of acquisition. So pretty crazy stories. And then if you want to go into other stories not relevant to this, we can talk some insane stories. I think long term we need to write an anonymized book amongst my team of some of the crazy stuff we've seen between massive issues and fires in data centers, crocodiles and data centers, customer insanity, all sorts of interesting stuff.

Crocodile data center would probably be the right story for this crazy.

That's what happens when you get floods in a data center, particularly in Florida, is you get crocodiles in your data center.

Wow.

I would not want to be the first one going in to pull the plug on the drain.

Tom, this has been great. I learned so much about doing it. Diligence, planning for integration. You've helped me become a better M and A scientist.

I love it. Thanks for having me. Kasana. This is always a blast. Happy to do follow up sessions and really appreciate you taking the time to talk through what we do. What does it nerds get to hide in the corner and not ever have anyone aware of what we're doing. This is really important for acquisition, so thanks again for having me.

Appreciate it. Hey those of you still tuned in, thank you. You are a true M and A scientist. I always appreciate feedback, topic ideas, speakers, things like that. You don't like the podcast, hit me up. I'll give your money back, but let me know how this is. We haven't done a lot of IT topics so I'd be really curious to get a sense. Hopefully there's some IT nerds I'm helping to make happy. Until next time, here's to the deal. Thank you for taking the time to explore the world of M and A with our podcast. We love hearing feedback. Tag us on a LinkedIn post, add a review on Apple Podcasts. We'd love to hear from you. If you need help standing up an M and A function or optimizing one that you already have. We're here to help, and if we can't help you, we probably know someone that can. You can reach out to me by email Kisan K I S o n a science.com or you can text me directly at 312-857-3711. If you just want to keep learning at your own pace, visit mascience.com for a lot more content and resources. That's where you can also subscribe to our newsletter. Again, that's mascience.com here's to the deal. Views and opinions expressed on MNA Science reflect only those individuals and do not reflect the views of any company or entity mentioned or affiliated with any individual. This podcast is purely educational and is not intended to serve as a basis for any investment or financial decisions.