How to Create an Executable Integration Plan During Due Diligence

This episode is brought to you by Firmroom. Searching for a data room that offers simplicity without compromise? Elevate your data room experience with Firm Room, the world's most intuitive virtual data room. Try it free for 14 days, no strings attached. And when you're ready to power up, sign up for unlimited users and 10 gigs of storage at a flat rate of 4, 495 bucks a month. Boost your team with Firm Room, a tool built by dealmakers for deal makers. Check it out firmroom.com Again, that's firmroom.com.

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. If you're interested in learning more about how to optimize your M and A practice, or want to get involved with the community of forward thinking M and a practitioners, visit mascience.com and subscribe to our free weekly newsletter. If you want to keep up with us on the go, head over to LinkedIn and follow M and A Science. I'm your host, Kisan Patel, CEO and founder of M and A Science. Joining me today is Jim Buckley, Vice President, Mergers and acquisitions integration at VMware, which now is part of Broadcom and his titles changed to Head of Strategic Planning and operations. I'll let him tell more about that. Those of you not familiar with Broadcom, they design, develop, supply a broad range of semiconductor enterprise software and security solutions, trade on NASDAQ under avgo. Today we're going to talk about how to create an executable integration plan during diligence. Jim, how are you doing today?

I'm good, I'm good. Thanks Kisung.

So we're here live at. This is a former headquarters of VMware. Are we in a Broadcom building?

This is all. This entire campus is owned by Broadcom.

It was not their main campus.

The leadership team has moved up here from Ritter park in San Jose.

Thanks for making time to do this. Can we kick things off with your background?

I started Sun Microsystems back in the 80s and I was an ops stockroom guy. And then I got into finance, cost accounting, fpa, and then I ran with that finance career for several years, more than several years. And I think as some of our colleagues that have been in FP&A typically there's an opportunity out of FP&A to become an M and A person. And you can either go on the finance side, the quick dev side, or you can go to the integration side. And the reason that makes sense is because everything intersects in a company through FP&A. Everything. Top line, bottom line, output, EBITDA, et cetera. So it's a great set of experience out of FP&A to become an M and A integration expert, because you're used to having everything go through you. Sometimes literally, sometimes figuratively. I did finance for a long time, and then in the late 90s, I backed into, or was backed into an M and A integration role. Unbeknownst to me, one day I woke up doing a deal model. The next day I woke up leading the integration of a company we had acquired. Still amazes me how that happened, but it was a great move for me. So I did M and A integration at a company called Metagraphics, which was acquired by Siemens a few years ago. I was then at Microsoft for six years where I really learned deep M and A integration, both good and bad. We churned and burned a lot of things quickly because we were very acquisitive. And then in 2010, VMware at the time poached me from Microsoft to set up their M and A integration practice. It was a little loose at that time and they were getting more acquisitive. So I did that for six years. And then PayPal came and found me shortly after their spin out from ebay to do the same thing. I was there for four years, and then VMware asked me to come back and lead their two large public acquisitions transactions, Carbon Black and Pivotal. In 2019, they were concurrent, several thousand employees, big revenue stream, a lot of value, 4.8 billion between the two in the transaction value. And so that's what I did up until two years ago, actually, when Broadcom reached an agreement to acquire VMware for $61 billion. So for the first time in my career, I am on the receiving end of everything I did to a huge number of employees over my career.

We had a whole interview just out of this intro right here. So phenomenal background because you got this operational exposure, the FP and A and then integration with Microsoft's buying spree. And then you went and built the integration function of VMware. Then you went, built it, ebay, then went back to VMware to work on some massive public company deals. And then, and now being on the other side, what were the lessons Learned being flipped around on the receiving end.

The first lesson is I owe probably somewhere in the neighborhood of 40 or 50,000 employees an apology note. I'm working on that. It's really different. One, I in my current role have very little control over what happens. I want to add value. My experience is. And I've been in this chair, like I appreciate your input. I don't really want it and that's hard for me. I have control issues like a lot of M and A people and it's hard to sit there and not go, but you should have you. What about. And I have to just sit there and go, what else can I do for you? It's humbling, quite honestly, to go from the control position to not passive because I'm really busy, but I don't have control over the outcome. The outcome is being dictated known by the parent, in this case Broadcom. And I am responsible for helping them to execute their integration plan of VMware. Now, to be clear, I am now part of an asset that's being carved out of VMware now Broadcom and has just recently been signed to be acquired by kkr. I've gone from being acquired to helping them integrate. Oh, but wait, now you're going to spin out this other asset? It's. So I've been acquired basically twice in six months in a single deal. Yeah, that makes my head spin.

Yeah, that wasn't a deal they planned from the get go of, hey, we're going to buy this and we're going to carve this out.

Yeah. No, they knew that they were going to spin out the end user computing division.

Got it. So that was already in the plan. Were they communicating that pretty early saying, hey Jim, this is where we're at?

It was more of a whisper, quite honestly. I think they wanted, they didn't want to overly disrupt the customer base, partner ecosystem and the employee base, quite honestly, because they didn't know they didn't have a buyer at the time. And it's as you can imagine, 95% of the work is integrating the primary assets out of VMware and this other asset. So then to use a computing division business unit is not insignificant. It's like 1.5 billion in revenue, 4,000 employees. So not insignificant. But that's a lot of moving parts. Big, heavy moving parts.

Was it fun?

On a good day? I convinced myself that it's intellectually interesting. I run a lot, so I think that's what keeps me sane. I've been doing this a long time and this is the hardest I've ever worked. Every day is different, Every problem is different, every input is different, every reaction is different. The level of scrutiny on some things is overwhelming.

It's interesting because on the front end, you kind of marvel the financial engineering of these deals and how they think that through in terms of, here's the value within these business units so we can take it back to market, get cash out of it and do that. But then the actual execution, which you get to see, is a whole different animal.

And there's a bunch of yachts right now. The KKR deal has not closed. It was signed several weeks ago. And so we still have a lot of learnings that will be coming our way and a lot of requests. Right now we're in that phase with regulatory, etc. Where there's only so much you can do. It can only be planning. As everybody knows, it does this for a living. You don't want to trip any regulatory issues.

Okay, I'm done pressing on anything related to Bronco before. Both of us have friends there and either of us don't want to get troubled by them. So integration planning. We know the integration plan must be aligned with the strategy. How do you ensure the integration leader and their team understands the North Star?

I learned this at Microsoft, which is not an easy environment to work in or wasn't back then, and I would imagine it hasn't changed a lot. It's, in my experience, imperative that a member of the integration team, and typically one of the more senior members, if not the lead or the head of M and A integration, needs to be involved as far left and as early in the process as possible. And that gets a little uncomfortable at times because deals are confidential till they're not. Just adding people to those meetings sometimes is uncomfortable, both for the target company or companies in the process, as well as for the core BF team and the senior execs. I was able to charm my way into a lot of very early discussions with companies because at the end of the day, the integration team is the one that has to create the value from the deal. The Corp dev team acquires value. The integration team generates value, creates value. And so it makes a lot of sense to have somebody from the integration team listening to those early conversations even before you pick the target and sign the deal. They're the voice of reason, says that's going to be really hard to integrate. I have no idea how to integrate that. That'll be easy. And it's going to cost this much in an integration budget. Those inputs early on are key to deal success.

Would you say that integration lead, Ideally they would be pretty passive, just listening and gathering information, wrapping their head around the deal or there's expectation for them to be more proactive, really efficient for specific information to know what's going to go good and what to be mindful of in integration.

So the answer is it depends. It depends on the deal and the personalities of the deal. There's been many conversations where I've been very active to the point where being asked questions about how would you operationalize this? And that assumes a pretty open, comfortable rapport with the target in some cases. I'll give you an example that was public knowledge back at Microsoft. I was tasked with leading the due diligence and integration planning for Yahoo. The Yahoo deal that ended up not consummating. And it was made very clear to me because most senior execs were like, just to be clear, we're doing all the talking in this meeting. We don't want one hiccup in this meeting. 100% respected at the time, it was a 30 plus billion dollar potential valuation that ended up going higher over time and then ended up not closing or even being signed. A lot of it is just what's the working relationship with the deal lead, the business lead, the corp dev lead, et cetera. And do they TR you not, you know, because you say the wrong thing in one of those meetings, you can destroy the deal pretty quickly. So it's not something that you would want to have really junior people in great experience if they could just be a fly on the wall. But the role is passive, listen, observe or actively lean in and engage.

Would you also say that representing the functions that are going to be involved with integrating the company, is that part of it and is that part of like how you're thinking of your involvement?

Totally. For me, I have a background in finance, so finance is comfortable with me being part of the meetings. Not representing finance, but representing finance. Many senior HR execs might get a little nervous with me representing hr, but they want to know what I think, like how are the execs behaving? The one exec from the other side is like looking on his phone all day long, just not engaged. And others are leaning in and very engaged and others are just staring out the window, whatever. There's a lot of value in the body language and I've learned over time how to form opinions and they're nothing more than opinions because I don't know what they're thinking. I can Represent a lot of functions. I've never written a line of code in my life, so I'm not going to be the right person for R&D, IT and Operations all day long. I can do that. But not everybody's been doing this for 40 years, so I'm probably not the prototypical M and A lead that somebody would drag into one of these meetings.

And I'm just trying to wrap my head around mindset. A lot of times everybody thinks they can do everything, and it's like, well, what is these things that are unique in terms of how you're acting in and who you're representing, what information you're gathering.

What's important is the relationship from the acquirer, like how core dev and the integration teams align. They're not the same team and they have very different goals. They have the same goal, create value. But corp dev ink on paper. As soon as it's dry, they're largely, mostly gone. The integration team takes it over. You got to have a really solid, exact level set of relationships. The business units, the acquired, the deal exec. It comes down to two things. Relationships and then communication. If you have that early in the process, and trust, it's a pretty solid approach and platform to work from.

This is a little more than just throwing a project manager at it.

Yeah, it's a lot of that. That's where a lot of people start in their M and A integration career. And that's 100% fine and great. Not everybody was thrown into the deep end of the pool like I was, where I just had to figure it out. My first integration, I was a finance guy. It's like, what do I do? I don't. My boss at the time, the executive of the division said, just don't mess it up. It's like, all right, that's helpful.

How do you start building an integration plan?

The easy answer is you start with the strategy, the strategic rationale to ensure that there are value drivers. Support the strategic rationale. And the integration plan is aligned with the value drivers. So that's the easy answer. And you can start doing that really early in the process. Like it's one sheet of paper with really big font on it. Strategic rationale. What are the deal value drivers? Revenue. Yes. No. Geographic presence? Yes. No. Employee retention? Yes. No. R and D milestones. Product. Yes. No.

This is step one. Step one is focus on strategy. Understand the strategic rationale, the real value drivers behind this deal, and then you start outlining a plan that aligns with those value drivers.

Yeah, this will make your head spin. You only have to get two things right in M and A integration. One is customer satisfaction. The other one is employee satisfaction. And if you think about that and most people will go okay, but you're missing about 800 other things. And here's where you get to the other 798. When you double click on customer satisfaction, you start to understand, do I have the right field exacts? Do I have the right field and territory alignment? Do I have the right commission structure to support this new business? How do we inform and engage the partners and incent them to sell this new product or technology if that's one of the value drivers. And so you double click on customer satisfaction and you get pretty deep, pretty quick employee satisfaction. If you acquire a company and the employees are just not happy, nothing else matters. You'll lose people left and right. You incent the top 10 or 20% with something special, but they're not doing all the work. They might be leaders that the rest of the team will follow. And that's awesome. It's not always the case though. But it's like, well, how come that guy got $5 million worth of RSU and I got $100 bonus? It dilutes very, very quickly. So if you don't have employee satisfaction, you kind of don't have much of an opportunity for success. Again, depending on the deal value drivers. And if you think about an acqui hire, that's all about the employees. It's only about the employees. Again, value drivers retain employees, figure out what it's going to take to retain them. It's binary.

Okay. We got two big fundamental drivers. Tell me more about the planning. This might be easier to wrap my head around. If we made up a deal, we won't use Broadcom as an example. We'll use deal room dealroom buys like the data company. So we look at the deal and I'm pretty early and I know like hey, I want to make sure I don't screw up integration. I'm going to call my good buddy Jim. You come in and you're like, what are we doing with some value drivers? They are a pretty early stage company, but they have all this data I think would be a product that we can cross sell into our network. It'll add some additional capability to our product that we would then create an add on and upsell and anticipate on making 1 million revenue, whatever, 5 million in the next three years. So that's our investment thesis. That clear? Clear enough.

Yeah. Your value driver is largely Revenue driven. You want to drive more revenue.

Good old revenue synergies.

I always smirk when I say this, but it's because it's so simple. Smart people want to complicate things. You got to keep it simple for as long as possible. Simple is hard. I think I've said this before in other podcasts. Simple is hard. You got to keep it simple knowing that it will self complicate over time.

This is the takeaway and if anybody follows the series, this is the fourth time Jim's been on the podcast. So this is the theme of all of them.

Simple, simple, simple. And it will self complicate. So in your deal, you want to drive top line. So you've got a set of numbers to support the valuation that you're going to pay for the company. Top line. There's costs associated with it. You want to make sure you're profile of P and L is going to support it. Your integration plan is do I integrate the employees and what does that look like and do I integrate the technology or do I leave it all standalone? The infamous Yogi Berra line. The baseball player from way back when. When you come to a fork in the road, take it. Because otherwise it's easy to get paralyzed. And like I know this deal is a great deal. I don't know what to do with it. But you do know what to do with it. Sell more and then do you bundle it? Do you not bundle it? You acquire it and don't charge any more for the capability that it brings. Knowing that you're going to combine the technology, you're going to bundle them and then you'll just sell more of everything in general. Then you give that to the finance team and say, okay, model this way, model it this way. Independent, separate SKUs. Bundled SKUs. Not charging more for the functionality, charge more for the functionality, charge more, discount more. You've got dials you can turn. That's what the finance team does in the pro forma deal model.

Okay, so let's role play that out. We go through this deal and we look at those different tech situations and we have it modeled out that seemed the most favorable would be as an add on. We see the marketplace people would sell. We can continue allowing the product to have its own direct go to market and potentially have another stream of leads coming into the deal room. Product and then employees, we found a good culture. They seen a lot of potential to bring the teams together because we'd want to continue supporting development of their product and integrate it. Now that's Going to be really simple to integrate into our platform. There is a goal of keeping the employees. And so we're 50 employees. Let's just say this company is like 20 employees. Pretty good size. Given that, how do I start thinking of integration plan? Because again, it's still pretty early. Are we still pre loi at this phase?

We can do either. Yeah, let's go pre loi.

Let's do prelo and then sign loi. And then maybe give me a sense of like how we would detail things from there.

When it gets overlooked, really. So you look at the. Typically you're not given the names of the employees, you're given the roles.

Correct.

They don't want you to poach their employees or you figure out who their keys are and pull them over. But the roles get really overlooked very quickly. Role definition is different. But a smaller company, sometimes titles are inflated because they're at a smaller company, the company wants to woo them over. And you've got somebody doing general ledger entries that says senior vice president of accounting. I'm kidding. Sometimes it's not titles. You have to get them to describe the roles and like, okay, tell me about this person. Well, they're going to three years college degree, not an advanced degree. Good, steady contributor. Engages. Okay, great, next. And then you just go through that with either the functional lead or whoever's involved at that point. Early pre loi, you've probably got a CFO kind of level. Senior finance person, maybe product person. And then CEO, President might be that. Coo maybe. Yeah. Depends on how they're structured. In a lot of startups nowadays, nobody has those titles anymore. They're all head of this and head of that and head of everything.

So my first and foremost is just getting a sense of the people and what's that going to look like in terms of who we're bringing over.

The other thing too, I think in preliminary due diligence, at least my experience in it is asking a CEO, say, there's a CEO. How do you manage your company operationally? How do you manage your company? And I don't mean how do you transact through a system, whether something. Maybe it's small enough, it's just Quickbooks. How do you manage your company? Like, how do you figure out whether I need three of these or four of those? They tend to always be. They're going to go heavy on sales. After teams can be salespeople because they're trying to generate top line. You got a bunch of engineers. So out of 20, you probably got. I don't know seven, eight salespeople. You've got seven, eight R&D people and you got a few administrative people. In some cases, they're wearing multiple hats. The R and D people are doing customer support at night. So the preliminary plan is to then, okay, how am I going to translate what they do and how they do it into my company and not create any friction or create as little friction as possible. There's always going to be friction. The other thing that's overlooked is the acquirer. You have to think you, Keysan will have to look and like, I got two heads of sales. What do I do?

That's true.

What if the to be acquired head of sales is better than your incumbent head of sales? You know what that decision is like and the likely outcome, you're going to lose somebody unless you incent them and say, look, this is a good thing. And here's what this looks like goes back to the employee satisfaction. How am I going to manage this?

I'm thinking of risk pretty early.

It sounds like, yeah, it's all about risk, understanding the risk and their tolerance for risk. I've been in deals where the acquiring team is perfectly comfortable with losing some of their employees because they know who they're going to lose and they might be okay. I don't have to pip them out. Yeah, this is a way to drive a level set across my organization and it's a call to the team. You better wake up and look around, get your head on a swivel because there's some really good talent out there and we're not going to be shy about acquiring them.

That's good to be upfront about it.

I'm a big fan of transparency and most people are adults, maybe 80% of them.

We have an outline. We're kind of early. We're doing the loi, but I brought you in early because I knew nothing just screwed that up. You're creating outline. You understand the rationale. This is why we're buying it. We got some good team members we're bringing over. We've got product that we can add to our portfolio as an add on and upsell. And we got an outline that lays that out.

The thing you're trying to do also in that preliminary phase is, and I do think this is part of the integration lead. Let's just say I'm in there. Part of my role is going to be just find the valuation that you're going to put into the LOI. It's not a $25 million company. It just isn't. You can do all this.

Corp Dev people don't like this. By the way. This is why integration doesn't get allowed early at the table.

It's so funny. I had a great working relationship with most of my brethren at Corp Dev and Microsoft. It wasn't a universal truth, but I was like, it takes you guys like a month to build evaluation. Okay, next deal, I'm going to guess what you guys are going to value. Do not tell me what you're thinking early on. And then you guys build your model and let's see how far off we are. It's really not that hard. The work is hard. I get it. And you got to build the valuation model. I'm not questioning. There's no denying that. Absolutely none. But it's not that hard to figure out what the valuation is going to be. I used to joke this, but upset a lot of them. I say, okay, let's play this out. Here's my negotiation strategy on what we're going to offer for a company buyer. How much do you want? Seller, I want x. Buyer about x minus 5. So we can at least say we negotiated and evaluation discussion. And it's not that easy. I've been known to create some friction with Corp Dev for a lot of things, which is usually top of mind at the moment for me. But again, you got to build the valuation model, you got to present it to the board, you got to present it to whoever needs to approve it in the company. And it is hard work.

Part of this was you actually supporting the valuation or putting an opinion around it.

Yeah. Because again, as the integration, assuming the deal closes, the integration team is the one that has to take those value drivers and create value from that asset. How do I make one plus one equal three? And that's why I deserve an opinion on that. Now, to be fair, I don't really care what the valuation is. It doesn't change anything that I do. It doesn't change how I do it. But this is where what are the valuation drivers? And very clearly it's not what is the valuation. I really don't care. That's a PR headline and a big check to somebody. What I want to know is what are the valuation drivers that support the strategic rationale? It has some implied valuation.

We get an LOI signed and it gets signed. So we somehow concrete in value whether everybody was on board or not.

Not using the integration guy's valuation or his methodology by any stretch.

We took the time to listen to him. At least we get this LOI sign and this is where rubber meets the road. And it sounds like up until this point we basically have an outline of what we think the integration, how it should go down, some key considerations around it which would include the people, the sort of approach around the integration. And I'm thinking like tech stack wise and a little bit about the organization operating, how they do things. So then once LOI gets signed then floodgates open on all the diligence information.

Yeah, I don't know how much of this happens today when I drove a deal and what our approach at Microsoft and I did this at both VMware and PayPal but learned at Microsoft there's preliminary due diligence which is really arm's length. Don't share any trade secrets, really confidential stuff because you basically just are under NDA at that point. When you get to LOI sign and get into that phase between LOI sign and pre close or you're in the pre close phase and then you get to close, there's confirmatory due diligence which is the big rocks that could disrupt the valuation. And we've got toxic exact agreements, contracts or commercial agreements or escrow agreements, big things that could literally change the valuation of the deal. Legal has a lot a big part in that. Then there's operational due diligence and you do those ideally concurrently, but they're not the same thing. The operational due diligence is really understanding how the company you're about to acquire works. How do you develop products, how do you sell, who sells to whom, how do you manage your employee base, how do you compensate your employee base, how does finance work? What are the systems that you run the company on? The really nitty gritty operational components of how the company is run. That's really what you're looking to integrate for the most part. Are we just going to transfer all the data from their systems to our systems and then we'll deprecate all their systems? That's kind of the perfect state and really hard to do mapping data fields and literally I've learned a lot over the last few months about data and the importance of data.

I feel like operations almost today is just a whole series of systems that you're going to end up having different systems of different companies doing fundamentally the same thing.

The good news is it's easier and harder now because most everything's in the cloud so you're not like moving boxes around. I literally have worked on deals where you take a, a terabyte drive, plug it in, download all the data, put it in the back of your car, try not to forget it or have it stolen because it's got about a billion dollars worth of data in it and plug it into your new box and then upload everything. Right now it's all in the cloud and you just very. It's not easy, but you can simply migrate the data. I mean, you got to map fields and do all that stuff that data engineers and data ops people do. But it's a much more efficient process than it was 20 years ago.

We have the operational part, legal part. Is there any other sort of pillars when you start thinking about.

Well, the one that's easy to forget, but probably number one is the employee integration.

We got the people. Now I was going to ask is the customers? Do you think about it the same way? Because you mentioned that earlier, we talk about employee satisfaction and customer satisfaction. So do you look at customer as its own pillar or is that more of a supported pillar?

You do so in due diligence. You'll typically map what is the overlap of the customer base, how many of same customers do we have? And then you might have customers in new regions where you don't have a legal entity, but you're about to acquire that legal entity. There's a lot of mapping that has to go on and a lot of rationalization of do we really want to be in that part of the world? What's the real return on that investment? Setting up a legal entity in country you're not already in has a lot of strings attached to it and that's really hard work as well. The whole legal entity thing, you do have to think about what are we going to do with the customer base, because that's where the revenue comes from. What are those customer contracts or agreements look like? Are they assignable? A really simple question that sometimes has the answer of it depends kind of thing, because there might be some conflict with that customer who has a contract with one of your competitors, who has some first right of refusal over change of, change of control kind of thing. It can get really pretty fuzzy pretty quickly. So that's why you do the due diligence. So you got to look at the customer base, customer agreements, the field, the resources, the people doing the actual selling. Do you need two people from two different companies that will be one company selling to the same customer?

Okay, we have four main pillars, legal ops, people and customer. I want to get practical in terms of how you do this because it's people. Jim asked me for a template to do integration I'm like, not really a template to do it. You extend off your diligence to know how you're going to approach integration. But then when I say that, you start thinking we're just waiting for all this integration information to fall from the sky and you build your integration plan around that. What we've already laid out doesn't quite come that way. You start early and understand where the drivers of the deal and get some at least a thesis of how are you going to approach this integration? Now that we get all this stuff and it sounds like we got these key areas, we got legal diligence going on, operation, we've got our work streams for people and customer. Are we like actually making an integration plan? Are you doing a lot of it? Do you just pulling functional leads in a room and start putting a whiteboard and saying, all right, what do you think we need to do?

Everybody does it different. There are obviously platforms that will guide you down the garden path of integration planning.

This is part of it. And just so you know this like I'm building AI in deal room and part of it is for me to learn this practically so I know how I can get AI to do as much of this as possible.

I think it'd be awesome to be able to with ChatGPT, say $20 million in revenue, global deal value drivers are the following. What's my integration plan?

What I'm learning is this is what's different is you have to provide a comparison the information by your parent company for that to actually work. Well, yeah, and we don't do that today. When you run a deal, you sort of assume you're God and you just go buy a company. And this is what we're going to do, this and that. It's just like a domain knowledge versus when you start leveraging it, you need to create a workflow to provide that context.

Workflow is really important and the reason I say that is so my approach historically has always been start with a framework. Not a checklist, but a framework. What are we integrating? People? Yes. No Ops. It. Yes. No employees. Ops, finance, R and D. You get on to several functions.

I like this because you get ahead of me because one I was going to ask you is how does the deal structure itself impact the integration plan? And we talked a little bit about if you're not keeping the text, that's a huge suction. You just blackout.

It's knowledge transfer, whatever that means. Knowledge from a document, knowledge from talking to employees that might or might not be around long term. For me, I used to joke, and it wasn't really a joke, but I used to joke that I would find out more about a company pre close from talking to the IT team, the facilities folks, because they know the layout, they get the buzz, they know who's talking about what. They overhear stuff. The IT team knows, oh, these guys are just prima donnas and they always want the latest technology. And who are those prima donnas and why do they think they should have such great technology? Like the non due diligence happens in a hallway and there's a huge amount of value. But you got to build some trust. People are like, why are you asking me these questions? Am I going to be fired? No, I'm just trying to understand how this place works. And I don't mean from an exact lens. How do you do your job? What makes your job easy here? What makes your job hard here? You'll learn more from those hallway conversations than you will from anybody. So back to the framework. So that all informs the framework, having those discussions, taking everything out of preliminary due diligence, confirmatory and operational due diligence. So you build out a framework, it's usually a timeline by quarter, first quarter, post close, second quarter, post close key functions and then start double clicking on those functions. Then where it starts to get really interesting is in, okay, I've got this. Basically a matrix or a framework. What are the interdependencies? How much of the top line is generated from the next new release of product X? What are the new products in the pipeline? When are they going to be generally available and how does that impact the top line? We've all got the horror stories of salespeople suggesting that they couldn't hit their number because they didn't have enough new stuff to sell. And R and D people going, I don't have enough Runway to meet what they're asking me to do for their customer base. I don't have the resources. I can't do it in six days. Whatever. Now you get into SaaS and subscription kind of business models, which most are nowadays. And you're constantly releasing. Every week you've got a new rev of the technology and addressed six new bugs. Like, look, your iPhone's a great example. Every time you do an update, they're largely bug fixes. It's not feature enhancements, it's bug fixes. Yeah, because customers want stable technology to run whatever they're running on it. As you build that and go from framework to double clicking, building the timeline, tying the interdependencies together, then you know what to do next. It all starts with what's my end state? How do I identify what my end state is? And that's, you know, your executive team's like, we want to spend $50 million on this business. You want to spend $20 million on your new toy. What do you want it to look like two years out, smooth. You never even reference the old company. It's all blended, it's all integrated. You've lost all the branding. There's no residual anything hanging out there. All the employees are like, this is pretty cool. I like working with these guys. That's the end state. Then you build this model, this integration plan to support that. So it's literally start whatever you determine. I'm looking for a successful outcome two years out, three years out, five years out, whatever it is, one year out. And then you start working backwards. You want a framework at the start, but you want it to be populated based on what you know to be the outcome you're trying to drive for.

Then as you go through the diligence exercise, you get a bunch of information and you just keep evolving that plan that works you towards that end state.

I think a lot of people do this end state view, but they don't know they're actually doing it. And I've always just been a big bang, the hammer on the anvil. Like end state, end state, end state. Every deal with the deal exact. What do you want the end state to look like? What do you mean by end state? Okay, what do you want this thing to look like some number of years.

Out, Then this tells you how much to integrate. I think that's a funny thing where you get flipped around. How much does company do integrate, do partial back end, fully integrate, do not integrate. But in your view, correct me if I'm wrong, is if you're really focused on the end state, that'll give you.

That decisions, those decisions are an outcome of that definition of the end state versus the other simple way to think about it is if what I do tomorrow, which I believe is going to be the right thing, whatever it is, is not aligned to the end state. I use that analogy. You start in San Francisco and you're just traveling east, but you want to get to New York, but you're three degrees off and you end up in Wilmington, North Carolina. You're like, but it was only three degrees off. But yeah, it self perpetuates. Like each day you're a little farther off and a little farther off and there's like this geometric progression. And all of a sudden you're like, where am I? And that happens in M and A. You all of a sudden wake up one day and go, I don't think this is what we meant to do. Oops.

Yeah. Pretty common theme. We are building an integration plan. We have a framework to follow that helps us build our thinking from the end state and gives us these decisions to make of putting data together, how we're going to approach the systems. I guess this is where we start building timelines in terms of workshopping is the right word, but collaborating with the team members, what does that look like in terms of getting that, like, as their approach to doing it?

So when I was at Microsoft, I started out, I knew what to do. Just leave me alone and let me do it. That doesn't scale. I think what you're referring to is the concept of what we call whiteboarding. And what you do is you bring everybody in, all the functional leads, key contributors, ideally from both sides. Everybody. The FP and a lead FP and a lead head of hr, payroll to payroll, and you literally, in the old days, before whiteboards, we used to put a bunch of butcher paper up around a big conference room, and we would write whatever the timeline was by month, by quarter, however you wanted to measure it. And then you would put the rows of the work streams. So people is a work stream. It is a work stream. Customer success, global service, whatever you want to call it, is a work stream, et cetera. And you start to build out what has to happen in each of those months. But if we go back to what I was just referring to, you start at the right end of the whiteboard and work backwards. Your natural inclination is to go left to right. We learn to write that way. It's different around the world, and I understand that, but the concept is the same. But again, it's write the story from the finish to the left, and then you figure out what are the key milestones. Where are my interdependencies? Where are things going to break? Or is something likely going to break, trip us up. We didn't account for that. The integration budget's off. We didn't include the target sales force in our sales kickoff. There's a $5 million miss out of the gate. Things like that just become very apparent when you have them up in front of everybody and you can get the holistic view and synthesize. I'm pretty sure most people don't think like I do, and that's probably for the betterment. Of the world. But I am very aware of looking at a lot of things up on a wall and synthesizing it. It just sort of happens naturally for me. It's not about reading it. It's about just observing what's up there and looking around and that's where the train wreck's gonna happen. We need to go. We need to go there again. I think it's because I've been doing this a long time, but there are people that have that sort of capability early on in this sort of thing. And it's not just M and A. It's a lot of different functions. But again, start at the right, work to the left. We call it walk the wall because people use post IT notes. You know, write down GL close. What do they do it on? What do we do it on? Theirs is better, we're keeping theirs, that sort of thing. So you put a post it note that says acquired business, GL close process. But it's the kind of stuff we're thinking about now. Are the fiscal periods the same? 13 weeks, 12 weeks Calendar, fiscal, that sort of thing. And then you've got all kinds of accounting issues about how you're going to align your fiscal periods. Are you going to do it out of the gate? You're going to wait a little while. When are you going to do it? Who's going to do it?

What do you expect in the integration plan? And like, to the level of detail.

I'm a big fan of big order bets. Boulder Rock, pebble kind of approach that's easier to do with a seasoned or experienced set of functional M and A leads. An M and A lead from finance. It's been doing this for a while, five years or whatever. It's got a number of deals under their belt, people leads, HR stuff. I let them do the double click. You know what, you just have to align to this, how you want to get there and leave it up to you. Which is back to the framework approach. I struggle with people that have to follow a checklist because to me, it doesn't mean they're checklist followers. They're not problem solvers. The best M and A integration people in my experience are problem solvers, critical thinkers. They're not just looking at this as an exercise. Like we did A, then we did 8.1, then we did a dot 2. I'm not sure what B is, so I'll just. But, oh, I got to figure B out before I go any further. It's like, do you really? Do you. Does that mean you've stopped? I've worked with people that have literally told me to my face I'm stuck. Well, why are you stuck? Because I don't know everything I need to know. So you don't need to know everything, you just need to know the next thing. As long as you know the end state, then you have a pretty good idea what the next thing to do is. I get that not a lot of people are wired that way. It's a struggle sometimes.

Well, you had a good point. If you have experienced folks at work.

Users new or enough experienced folks, if you've got a really solid integration lead and maybe a couple reasonably seasoned functional leads, you can do the deal because they can help the other people that are like, I've never done this.

Is there any parts of integration planning that just take a lot of time? And I'm driving back to the AI examples where you have to. The thing I think it's really good at is taking unstructured data and structuring it. So if you got to really organize information through large sums of it, it's really helpful for that. Is there parts of integration planning that comes up? Because it sounds like a lot of this is just very conceptual. You're doing things and learning about the company diligence and then you're just thinking it through with leadership team across the functions and how this is going to go down. But is there more of like really nitty gritty having to shift through documents or is that just part of doing diligence?

A lot of it is doing due diligence and then becomes less about the diligence and more about just going and asking the person at the company having that relationship. Just ask them like, well, I remember reading this and the due diligence response to this question, but how does that actually translate into an activity? Integration planning is at its simplest form a set of activities, one after the other across multiple rows concurrently. Some move faster and sooner. But you got to make sure you leave no activity behind because that's the whoops, you go, oh, we forgot that. It's having that conversation weekly check ins really help. Does anybody have any questions? Have you. Where are you at in your process this week and just having that dialogue and then referring back to the Walk the Wall, which is really the start of the integration plan. Big framework, a lot of information, mostly a lot of data. And then to your point, some of it's structured, most of it's unstructured. It's like robotics if it was all just pre canned, predetermined you just push the button and everything happens. But that's not what it is. M and A integration is like the Wild west if people are really honest about it. A lot of people think they have a really crisp and clean process and they do. There's a whole lot of stuff that happens behind the wizard of Oz curtain where there's just. That's where the flailing happens. The chaos and the ambiguity are just rampant. But in front of us. Yeah, this is pretty easy. No, it's really hard.

When you go through this exercise and you get this plan that's really starting to shape, where do you get feedback from the target company, start syncing with them to get them on board?

The ideal state is that they're as involved as soon as possible as you can get them. I think a lot of companies are different. Been around projects, not companies, but projects where we acquired. You just do what I tell you to do. That kind of doesn't work with a lot of people. Wait, you're trying to integrate me and sell me on why it's a good idea to be here. But that's not what the vibe I'm getting. Like, I'm just here to serve you in your role. Again, it goes back to. I just. I think M and A is largely about relationships. Friction filled relationships out of the gate lead to friction filled outcomes.

It's true. This is a big exercise of leadership, getting aligned with other leaders, collaborating.

I did a deal in Madison, Wisconsin when I was with Microsoft and I remember they were largely being sold by the board. Their board, their executive operational leadership team was not all that enthused about selling. They wanted to keep running their company the way they wanted to run it. It was in the online shopping space. I remember having to have some really hard discussions with the leadership team and they're like, I said, what's this going to look like for you? Like how long we want you to hang around for, However, a year or two years, whatever. Which usually suggests some sort of a hold back. And they're like, I'd really just like to get my money and leave. I understand that, but that's not our intent. And I remember one guy very specifically telling me, he goes, here's where it is, Jim. If I wanted to work for Microsoft, I would have applied for a job at Microsoft. I have no vote in what's happening right now. And you kind of have to help people work through this. Now. I know what that feels like. This is a great deal for a lot of reasons. The current one I'M in. There's nothing but upside. Nobody came and asked me what I thought would you like to go work for a new company?

Right.

I wasn't planning on it.

I'm still stuck on the getting the target company's team involved early because it doesn't happen. I do a lot of these interviews. It doesn't happen.

No, it doesn't.

I ask people why I get the whole world company and just jumping laws but as far as what I can tell you could plan to pretty 10th level of detail. As long as you don't actually do anything to integrate before closing. I don't see where the limitations are on planning and working with the target company's leadership team on what that plan is going to entail.

Well, I think it kind of comes down to a lot of patience and tolerance the to be acquired team at all levels from the highest level on down. I kind of got a day job. I got a big product release coming up. I'm yeah, no, I'm not interested in sitting through your integration planning meeting or process but others are very interested in it. You know this as well as I do. M and A is hard. M and A integration is really hard and most people know that either explicitly or implicitly. So when you ask them you need to be part of this process they're like ooh, no, I really don't want to be. Thanks for asking but yeah, there's a lot of value if you can get the right people from the to be acquired company to engage. I've actually worked with teams in the past where even in the early integration so post loi so then you have a little more access to people have them. I want your DNA in this integration plan. This will go a lot better and your colleagues are going to look to you. If you're invested, they're invested. If you're not invested, they're not invested. This is what it looks like. This is what the work is. Who do I need to talk to to free you up from whatever you're doing but I want you to help us build the integration plan. Some people just light up at the opportunity and others are like yeah, I wasn't really planning on hanging around so thanks.

I actually like that gesture of hey, I want you to help with this integration planning and make sure this deal works for the best, for everybody.

Transparency and collaboration, the two big words, multi syllabic. But I know early on I wanted to be in control and I didn't want anybody else involved and I learned over time that can work kind of sort of. But then you realize one, it doesn't scale and two, it upsets people if they feel like you're there and don't want to listen to what they have to say or contribute or even ask them to do it where they at least have the opportunity to say yes or no. It doesn't scale and it doesn't really work out all that well when, you.

Know, you finished planning.

One of my managers at Microsoft, he was a great M and A leader who didn't come out of M and A, he came out of a function and he would ask me all the time and my colleagues, my peers doing what I did, the integration leads. He would say, what does done look like? It's a really hard question. The easy answer is it's when you hit end state. But you think about when you define end state and say it's let's just easy math. It's two years out. End state is two years out. What does that look like? So they're big buckets of things that you're going to accomplish. It's not overly detailed. Full integration of the employees, retention rates of this one sales force, not an eight legged sales call kind of thus situation. The dev teams are all split out. Whatever it is that defines end state, that's what done looks like. The thing is, end state does change over time. Two years ago, did we know we were going to sit down and have this meeting? No. Is it the right thing to do? Yeah, but it wasn't on our radar screen two years ago. It's the same thing in M and A. Like two years later, the economy's changed, interest rates have changed, it's hard to borrow money. Oh my God, we got to put in a bunch of superchargers because everybody's driving Teslas now. You don't know that two years earlier then you get the two years and the whole world's changed. Literally in many ways, you gotta be agile. Agile, nimble. This is my new kind of catchphrase. It's not a phrase though. And I'm doing that on my current project. Simple, streamlined, nimble, agile, productive, efficient. And I tell everybody I work with and all the work streams I'm leading, everything you do has to hang off of one or more of those six things. Are you being simple? It doesn't look simple. Are you being agile? Still doing the same thing, the same way you did it a month ago. So I'm going to say no. It's really easy to pick at it. But that's my new thing. And the overlay is that it's in an environment typically of chaos and ambiguity. The floor is moving constantly.

Well, it's interesting how we talk through this in terms of integration planning. A lot of it is extending off of what you learn in diligence. Most of the time it's corporate development, a director or somebody of that sort level that quarterbacks the diligence process. Can we talk a little bit? I know we've talked about this before about how does integration ideally work in to get that diligence information so they can properly do the considerations around the planning or you've seen. I think it's an emerging trend where it's very much combined or an integration lead that's driving diligence.

At Microsoft 2005-2010, which is 11 the time I was there, the integration team led confirmatory due diligence. We led technical due diligence. We had an incredible tech TD lead there. I learned more about technology from that process. All kinds of stuff that can create challenges in the overall integration. I was like, I never knew that before. So massively helpful. It just removed one handoff from the process. I don't know a lot about electricity. Some people probably laugh at this, but electricity sort of diminishes over time and length and distance. So it's got to be reboosted or repeated. It's the same thing in due diligence. If you've only got five people doing the due diligence and at some point later there's going to be a handoff. Here's what we found, here's what we learned. It's not going to be 100% of what they experienced in the actual process. And yes, you can give everybody the readouts, the documents, and that's really helpful. But a lot of due diligence is sitting down and looking at something and then having the conversation with the person who was responsible for that at the target company. Usually like a chief legal officer or the head of product. Unless you record those meetings. There's more learned in that dialogue back and forth than anything that can be written down. I don't believe you write down 100% of what is said. Maybe there's a stenographer, transcript person or whatever.

Yeah, transcription tool that's. We'll have to get the integrates and feeds and deal then you got to.

Listen to all of it.

No, you got AI to go.

Yeah, can you just tell me what's the five things I need to learn out of this? Four and a half hours or Days of transcripts.

Favorite thing to do is I take transcript. I take transcript. These podcasts actually Jim. Or definitely the prep calls I do and I feed it into chat, GPT or any tool and ask it with outline questions for this podcast interview. It does pretty good. I think it's similar because I've seen companies do that where they're recording diligence calls and they're using some type of AI tool to transcribe it. But I think that's like the next overlay is like, all right, can you make that part of the unstructured database? And then you're using AI to synthesize.

That'll be interesting to see how that plays out. I think it'll be huge.

We're working on it. I'm using what I'm learning here to keep building it. The planning thing I think is what's interesting. If there's an opportunity to take diligence information and start repopulating some of the integration planning. But I think I like where you're going with it. Put consideration the high level plan first.

You would have to inform the platform of where your target end state. What that looks like.

Yeah.

And then it can filter in. This is what was said, this is what was written, this is what was drafted. And then connect the dots to what the end state looks like. That would take massive cycles out of the process. Even when you do due diligence, there's an HR due diligence module. There's a R and D due diligence module. This is again to my point or comment about I believe really good integration leads. The ones that can synthesize how all that connects. But there's no obvious way to do it. Chat GPT would be a way to do it from an AI perspective. But most people just sit there and go, I'm just the, I'm the HR expert. I'm the R and D expert. I'm the IT expert. Most HR runs on a platform. So if you guys talked, do you know how that works? You know what you found? If you populate a bunch of records out of workday, is that the same set of records that HR has in the payroll file? They should match one to one, make sure everybody gets paid. And it does. I'm not quite. That's a low hanging fruit example. But things like that, that as they get more abstract, somebody's got to be able to say that connects to that. We got to figure that out.

We'll prototype something, play around with it.

It'd be cool.

Yeah, it's it's work in progress. It's cool learning all these different use cases. This one definitely seems very viable. People actually reach out to me on these podcasts and they ask me this, but if they're doing an integration for the first time, they don't have anything. They're really starting with playbook or framework wise. What advice would you have for that situation?

So that comment I made about my boss at the time when I did my first deal ever, said, what do you want me to do? Like, I literally asked him that question. This was as he was literally leaving the building in a snowstorm in Boulder, Colorado and going big game fishing down in Australia. He's like, I'm going to be gone for three weeks. I will not have cell service. Just don't screw it up. You use different language, but it's basically that not helpful. But what I've learned from that in hindsight is ask a lot of questions. Again, I did ask him, what do you want? What are we trying to achieve here? And he told me he didn't call them deal value drivers or end state, but he told me what he wanted it to look like. I constantly was able to refer back to that, okay, is this next thing I'm doing tied to that in some way? I just knew intuitively that's what I was supposed to do. But it comes down to asking a lot of questions. The company we bought was a huge team of math PhDs out of the Russian science institutes. Brilliant. These people were brilliant. So, one, I didn't speak Russian, two, didn't write code, can barely spell PhD, so I felt so useless in the process. But I started to get figure out the questions to ask them, like, how are you going to apply what you're doing to this next release of the technology that I could understand once they'd go deep into the code, and I'm like, that's not my thing. When are you going to be done? Can I tell the field about it? And when can they start selling it? And then you gotta tie it to the QA engineers and the build process and all that stuff. It was kind of intuitive, but it was about asking questions. And sometimes they feel like the dumbest questions in the world, and they're not. So for somebody that's really new to this, it's problem solving and critical thinking. Sometimes you got to go slow to go fast and ask people, like, what does that mean? I don't know what you just said. I don't know what that means, whatever that is. Especially talking to engineers where you're like, unless you're an engineer yourself, you're like, you do what? When? On what kind of thing? Ops and finance. I was fine with that. HR people is hard, but it's pretty straightforward. What are we doing with the employee base? Literally, I asked my. Are we keeping everybody? We're not keeping everybody because. No, we're going to keep everybody. That was easy until you got retention issues. And it's not easy, like, why are you leaving? It's cold here. I got to want to go somewhere warm, that kind of thing. But it's literally being humble and asking questions.

That's the key. The key overall in M and A.

It really is at all levels. Senior execs down to probably the most junior person. It should be the same approach. The questions are just different.

What's the craziest thing you've seen in M and A?

I think it changes. I've had a lot of those experiences. I will say right now, a carve out concurrent with a large integration process is crazy. In a good way. Like, again, I had a really bad day. I think it's just intellectually interesting. But these are really hard problems to solve because you got a lot of moving parts on top of moving parts. It's that whole fly the airplane and build it at the same time. I've always used that analogy from an M and A. That's how I describe M and A integration sometimes. This is sort of the PhD level of that because you're trying to carve out an asset that then you're trying to stand up as an independent, fully functioning company. It was literally engineers and product management people, some marketing people. Now you got to build out IT infrastructure. You got to build out partner and channels. You got to bring salespeople in because they were a centralized resource. It's really hard. It's really hard. I want to joke that my beard was dark when I started this, but I think most people know now. My beard's been white for a while.

Yeah, I mean, just divestitures. Carve outs in general are complicated. So doing integration at a large scale.

Well, that's the other thing. Like, I actually had to inform some people the other day. I said, this is a carve out. It's different than a divestiture. Divestiture is an intact asset that can stand on its own, largely. Carve out is a bunch of functions that are part of an asset. It's like a jellyfish. Things are moving. You don't really have a stable foundation. And what's your new ERP platform. Okay, we figured that out. What are you going to connect to the front end of that from an opportunity perspective? You're going to keep the one that comes with it with the erp. Are you going to go somewhere else? And then what about the lead system? And simple is better, but simple is hard. I've learned a lot in this process about how simple is better is everybody wants to customize everything and that's when you end up having to extract yourself from that. Like we absolutely shot ourselves in the both feet and both temples, highly customizing everything because that's what they wanted, whoever they was on any given day. It's like simple, simple, simple. Do not customize. It's really straightforward and really hard to do.

This has been a great conversation.

Thank you.

Thanks for taking the time to host. I learned a lot. You've helped me become a better M and a scientist. Those of you still listening, thank you. Always love feedback. Hit me up at LinkedIn. Let me know what you think. This interview put a lot of effort to do these in person, so whatever my tne that I get questioned about these days from Leadership Team, until next time, here's to the deal. Foreign.

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 Podcast. 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 M and A 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.