Why You Should Update Your M&A Management Approach

Hello M and A friends. This podcast is brought to you by dealview. M&A is coming back. Would you like to avoid wasting hundreds of hours managing Excel Trackers and building PowerPoint reports? Do you want to make your process more efficient? Well, I have great news for you. Deal Room is MNA management software to save you time, headaches and improves collaboration so you realize value faster. Learn more@dealroom.net here's to the deal.

I'm Kisam 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 MA deals.

Foreign.

CEO, founder of M&A Science joining me today is Jim Buckley, Vice President of Mergers and acquisitions integration at VMware. This is actually a continuation of our conversation about M and A integration. If you didn't catch the first interview, I recommend you catch up on that. Today we're going to continue that discussion and talk about the integration management approach. Jim, can we kick things off since we may have some new listeners with an abbreviated version of your background?

I've been doing M and a for about 25 years, backed into it, being a finance and Ops guy, as TJ and Keeson stated. I'm currently at VMware. It's my second trip through VMware. I'm a boomerang, but I've done M and A at Microsoft, Mentor Graphics, PayPal. I've been around the block a few times. I earned all these white hairs. Hopefully we'll get to some of that in the conversation today.

I like the earning the white hairs now. I'm looking forward to mine.

That's not always a universal truth for everybody.

Well, let's kick things off. How do you make integration simple?

You start simple. My experience, including my own personal experience and the teams that I've built and practices I've built around integration, I think our comfort zone is in the details. We get very tactical very quickly. I've learned the hard way and over many years, many transactions. You gotta keep people at the big picture for as long as possible to make sure everybody gets it and can move forward in the unit. It sounds simple and it's not like many things. Keeping things simple is actually really hard to do. I think it's harder to do than let it just morph into complicated whatever out of the gate. But that tends to be a lot of what we do for a living and our passion. We love complicated, gnarly things and the sooner we're there, the better off we are.

I want to unpack this because this is where we left our last interview. We talked about human's nature to complicate things, and that's one of the keys you mentioned, Integration was trying to keep things as simple as you can, since people are naturally going to complicate it.

I've used the analogy. I honestly can't attribute this to the person that I heard it from because I'm pretty confident I didn't come up with this. But I like the view of the Boulder rock pebble with the boulder being the strategy, the big problem you're trying to solve. The rocks being when you start to unpack or break down the strategy into deliverables. The work, integration budgets, timelines, projects, micromanaged, micro projects within projects. And eventually you get to the Pebbles. The people that love to live in the pebbles are the ones that scare me the most because they're like looking at everything through such a finite lens. I endeavor in my work and in talks like this, keep things at the boulder level for as long as possible to make sure people get it. Because if you don't start out aligned, stuff breaks really quickly and in some cases very expensively.

How do you keep the alignment? Because you got a good point here. Here's strategy, this big picture, and then more times than not we hear about it, it fizzles and then people are looking at this little pebble.

Yeah. Again, it is amazing. I think anybody on this podcast can relate. You sort of really start to realize like, oh God, yeah, even I do that. I didn't really realize I did that. That's what I've been doing. Oh, no. I love to talk, literally, but I don't love to write. I'm a horrible writer. Let me unpack this for a minute. When I started at Microsoft, two weeks after I started, our new CFO started a guy named Chris Liddell who was an international paper. He was from New Zealand, an amazing cfo. Global, but not outta high tech. Right. International papers, clearly a different space. He was from New Zealand. He was the head of the New Zealand Rugby Union. So I was always afraid if we kind of messed things up, he was gonna call like the All Blacks and have them come assault us. It's just a task. You guys want to go play rugby just for fun? No. That could hurt. But Chris's view of how he liked to be communicated to, and this is really the thread threat, is how do you keep things simple? It's like you communicate, talk to people. No, no, no, you're getting too detailed Go back up. So Chris's approach was he never wanted to see a deck presented to him around a deal. It was more than five slides, more than five bullets per slide and or more than five words per bullet. So five by five. And I have obnoxiously tried to adhere to that while I was at Microsoft and since I've worked at Microsoft, literally we would go in to review deals and integration plans with Chris. In some cases very large transactions, you'd sit down with them and he would make his point. You hand him the slide because this was before we used to look at everything through a 65 inch projector on a wall. He'd literally make a point of counting the slides, counting the bullets on the slide. Like he'd move his finger down the slide like, you guys understand what I'm doing. And I was in meetings where somebody would bring in more than five slides, have more than five bullets, words, et cetera, and he'd hand it back politely and say, please reschedule another time and come back with in the required format. He was really rigorous about this. So we would all like double check ourselves. Like, nobody slip a sixth slide in there. That's not going to work. We're going to get the boot. And so I think it's all about communication and it needs to be communicated simply. What's the strategy? How does your work hang off the strategy? No, I don't want to know about the integration budget or all these milestones. How does your work hang off this strategy?

Simply stated, what's the biggest challenge when you're trying to communicate the strategy?

Making sure people understand it. My experience with well drafted strategies is that they too are simple. Again, strategies are basically, in my experience, problem solving. What problem are we trying to solve with this strategy? I think it's that simple. There are, I'll be very generic here for obvious reasons, but there are firms out there that feel like they're paid by the slide and that they're paid to make the thing so freaking complicated that nobody gets it. I was the only integration person that was part of the team that was looking to acquire Yahoo while we were at Microsoft. That was the most junior person, doesn't mean I was the youngest, but I was the most junior person in the room. And we had presentations from several of the large consulting firms and most of them came in with something under 50 slides because we requested under 50 slides. When one firm came in, they literally had a hand truck with boxes of presentations, paper presentations to hand out to us because they were too thick Too heavy to carry in by hand.

We're going back to the human nature part because we overcomplicate things. First thing, kicking off integration is to build a massive plan. It's just the nature of it. We get asked all the time, I need a template. Where's your integration template playbooks? How do you counter that? I feel like that's just the first formality that comes up. It's let's create this checklist, a giant playbook on what the integration plan is going to look like and shape as we go.

I did that early in my career when we were making presentations and building plans. It's like more was better. I was a former finance guy, wasn't very good at it. I used to think if it's in Excel, it's got to be right. I don't think I'm the only one that thinks that. Even though I've learned that's no longer the truth. People think, okay, I need more milestones to hang the next step in each one of the work streams off of. Well, no, but that's not true. So I think the way I've learned and I drive my teams to effectively manage the build out of an integration plan is start at the end, what does done look like? When we're going to go around and say we finished, we completed the integration plan, what does that look like? And continue to explain it. And then you work your way. What I call to the left in the process, go to then the milestone just prior to that end state, the done state, and then you move another step up, then another step left. The reason this is important is because nobody early in the deal is going to have a thousand line checklist to define done. Because you're asking what does done look like? What does the finished product look like? And nobody's going to have a thousand lines. They're going to have a big idea in their mind that they need to communicate, which by definition should be really simple. And then as you back up through the process, you can start to go from 1 to 5 to 10 to 30 to 100 to 500, to however many rows people need. But I don't ever want to see that body of work. Tell me what your milestones are, which is the macro level of all those sub checklists and is it in the right order? Have you identified the interdependencies? Have you identified the resources needed to accomplish it? And is it bought off on by the business that's responsible for the acquisition? Simple, simple, simple. You got to keep it simple for as long as possible. Because otherwise people go, yeah, but on Thursday, 23rd November at 5pm, we're going to do. And I'm like, I don't care about that. I do not care. That's irrelevant to me. What is the milestone that's driving you to do that work? What are the interdependencies of that milestone with the other milestones?

And that's what you actually do. You'll have your integration leads, talk through the end state, and then work backwards and talk through the milestones they're going to go through to achieve that end state.

Yeah, and the really telling point, Kiesen, is when somebody actually is rigorously gut level honest and they go, I don't know what done looks like for my work. I need help. It's the people that pretend to know what it looks like, because most people actually don't know what done looks like. They can sit there and say, all the employees are onboarded. They all have payroll, they all have computers. There's six different IP or product milestones. Okay, Independently, all that makes sense. How does it all work together? Do we have all the right developers to achieve those milestones, which is both a people work stream and a product work stream? Have those two work streams talk to each other? Well, no, but I just know that's what needs to happen. Really, you do? Well, why aren't you the CEO of some big company somewhere? Because clearly you're a lot smarter than the rest of us. I understand you want to be right, but let's go slow. Double click back up. And really, how does your work hang off the strategy? How does this support the strategic rationale as you identify what your work looks like at the end state and what done looks like? Can you go from strategic rationale to done and back again? And that's when their eyes start rolling back in their head and they're like, oh, hold my bluff. Yep, you know what? I don't know. I need help.

That makes a lot of sense. Are there any other exercises you do to keep that alignment to the big picture and what the drivers of the deal are?

Yeah, there's some simple things, actually, that we do. One, I try to stay out of the way. I have a tendency, like, I'll weigh in. So I don't want to be in the mix of the work. I trust my team to do the right thing the right way, but then review with them every week, like, where are you at in your process? Where you at in your process? You said you were going to be done by this date. Let's look at it before you're done to make sure you're going down the right path. So there's that. And then I think the other thing, too, is ensuring that they're talking. I don't want to be in the meetings, but are you talking to all the functions and team members that you have interdependencies with? Because the interdependencies are what will break things. If everything just goes down a skinny little bowling alley, but doesn't connect to the other bowling alleys, and you just end up with pins at the end of your work stream knocked over, but you don't know that they fell in the right order. Did you need to knock all of them down? Did you need to knock any of them down? Because you might come back and say, I actually don't need to do anything. I don't need to be part of this. That's the brilliant insight. When that happens and people go, you know what? You guys actually don't need me. We thought we did. Why don't we need you? Because this body of work, whatever it is, it's not part of what done looks like. I don't need to be involved. It doesn't happen often, but there's a recognition there of somebody that really knows what the work is.

One of the things we talked about was frameworks, and we contrasted between playbooks. Essentially inevitable they're going to be created, but having frameworks. We have some thoughts around that.

I am not a fan of playbooks. I played a little bit, and when I say that very little. Division 3 football. When I was in college at a little Jesuit school in California. If I stood up, most people were, how did you not die playing football? Because I'm like 158lbs dripping wet. I wasn't much bigger when I played. There's a playbook for sports, right? And then those are needed. There's a playbook for M and A. It's clearly needed. And the reason it's needed is it exhibits someone's understanding what the work is. And the way they can exhibit that is by writing it down. In the old days, it was a white binder with several, you know, with a number of pages, slides. Now it exhibit the work that needs to be done, but that really loosely translates into a checklist and what I learned a long time ago. One, I'm horrible with checklists. I don't want to be told what to do, and I certainly don't want to be told what order to do it in. But that's what a checklist is. You do one, then you do two, then you do three, and on and on and on. It's boring, it's redundant, it's repetitive. It assumed that the approach and the solution is the same for every MA transaction, which, as we all know, is the farthest thing from the truth. So what I became a very large fan of was frameworks, which is basically a playbook blown apart with all the components of it. And say, can you problem solve your way through this process knowing that if you need to refer to the playbook, go do it, that's fine. But really what I need is problem solvers, critical thinking skills from a body of integration experts. They can problem solve their way through the process. But there's a framework which is a little bit like, for those of you that have kids, don't draw outside the lines kind of thing. Although I'm a huge fan of drawing outside the lines, I like that kind of thinking. Like pressure tests, like, why won't this work? I think this will work. I want the opportunity to go make this work. Well, it's outside the lines. Okay, but I think it'll work. Maybe we need to expand the framework. I love people that come back and pressure test me and say, maybe the framework needs to be expanded and updated. Wow. Okay. I hadn't thought about that. Maybe. Yeah, let's go do this. Let's try it. As long as we don't break anything material, we'll figure it out if it works. But frameworks are a way to get people to problem solve their way through an integration process versus just following a checklist, which just suggests I do one, then I do two, and then I do three in the counter when people come back with that. But I'm more comfortable in the checklist process. Like what happens? Explain to me what happens when you don't have to do number five. And the silence is definite. Do I just go to six? What if you don't have to do six after you figure out you don't have to do five, do I go to seven? You know, it's. It's really kind of an interesting discussion.

I like where we're going with this. Cause we're starting off really simple. We're letting things naturally progress and the plans shape and form as they're needed. We're checking and getting the alignment, making sure the end state's in mind and clarity on the milestones. What types of frameworks? What does this look like? Are there a bunch of scattered frameworks for a bunch of situations or are there just a couple of core things?

So what it's distilled down to for me and my team, actually it's interesting. I incorporated this when I started VMware in 2010 and it's something that a number of us that did integration work at Microsoft came up with in my time at Microsoft prior to VMware the first time. And I found that when I came back in 2019 it was still in existence, which suggested to me that it worked. What it is is this four box scenario. It's the integration plan of record, but it's based on the business plan of record. So we asked the business to fill this as well early in the process. And it is what are you going to do with the people? What are you going to do with go to market, what are you going to do with infrastructure? And then literally the last one is what are you going to do with anything else that's left over? The other one is G and A basically is what's left over. Right back office stuff. And the business plan of record is we want all the people, we don't want all the people, we just want the engineers or whatever the business thinks they need. So same with go to market. If there's revenue generating employees, which is both people and go to market, how are you going to sell? Where are you going to sell, what are you going to sell? Then the R and D bucket is the product part, the IP part and then G and A is basically how you're going to support the other three. So the business needs to tell us. What's interesting is if I don't give them the sneak peek, the business meaning the deal exact or their proxy, it's literally tell me what you're going to do in these four areas and it's got to hang off the strategic rationale. So go back to the simple statement that's says this is why we're doing this deal and this is what it solves for us as the acquirer. And then they fill in these four boxes and it has to hang off the strategic rationale. It's really easy to see when it doesn't. They just give you the same boilerplate kind of BS answer every single time. You're like that's different than what the strategic rationale suggests is the problem we're trying to solve. So then we take the business, the bpor, the business plan of record and then we build our integration plan strategy starting from that. Again, it's simple, it's four boxes because again I was A former finance guy, and I'll remind everybody, I wasn't a very good one, but I joke about finance font. Finance people love to cram as many numbers and words into a slide as they can, and they'll use the smallest possible font they can. I'm like, you know What? I'm not 30 anymore. I can't read that. Even with my glasses, I can't read that. Point being, it should be maybe three to five bullets per each one of those boxes. Again, back to the five bullet thing or less. Just tell me very simply, what do you want to do with the people? What do you want to do in go to market? What do you want to do in R and D and what do you want to do with the back office?

That makes it easy to understand. And it sounds like this is something that just evolves within each organization. There's no standardization on this stuff. You can borrow some ideas, but even these frameworks as they are, the goal is to keep them simple. But they shape and evolve with your company's experience.

They do. And I think the other thing that's important to recognize here is that I'm sure most people listening, participating today had the experience where small deals don't equal easy. I use the really, it's probably not a very good analogy, but acquiring a business that's headquartered in des moines with 500 people and they're all in Des Moines, that's not a small deal. And again, I don't ascribe complexities of deals to valuation. An evaluation is something corp dev and finance worry about. And somebody eventually writes a check. I don't care. I care as a shareholder how many digits there are to the left of the decimal point. But it's more of a PR thing to me. We just want to say we spent 2.7 billion on this. I worry more about what's the revenue, where's the revenue generated, how many employees, what's their IP? Are there any complexities around the IP, et cetera? 500 people in Des Moines can be pretty straightforward. 50 people with a headquarters in Johannesburg, with developers in Kathmandu. Oh, and they're all contractors. That's going to be far harder, most likely, than those 500 people you're trying to sort through the integration of acquiring that business in Des Moines. So that's where you start to like, one size does not fit all. And that's why nimble agile framework helps to address the complexity of any and all deals. It scales up and it scales down. You don't overkill the work. You don't underkill the work.

You're right. Sizing along the way exactly when you're integrating, it can take some time and people can get burnt out and lost along the way. How do you maintain accountability and the cadence of progress of integration?

The simple answer is I think it's all baselined on communication. Tell me what you're doing, when you're doing it and if you need help. Every team is different. Some teams and projects require weekly check ins. Sometimes it's bi weekly, rarely is it monthly. I just think that's too much time to go by without understanding where people are. I've done deals at VMware in all transparency where we're still trying to close out the integration. More than a year later, I put a stake in the ground where we complete all our integrations in under a year. After that it becomes business as usual and it's none of my business. I'm done. There's a handoff. It's easy to get a little complacent because of burnout. Like, it's just, this isn't easy work. If you ask people to spend all their synapses on complicated problem solving, that's not easy work. If they're doing it right, problem solving should be a challenge. If it was easy, I wouldn't call it problem solving. I went to some textbook and got the answer. That's how I did it. Okay, that's actually, that's pretty good problem solving if the answer was already written somewhere. I think copy paste is not overrated. There's a lot to be said for people that have gone down this path before. If the success factor already exists, use it. You don't have to come up with something new. But I do think checking in with people not only to see where they are in the process, but also listening to how they communicate their work, I think it becomes pretty obvious for a good manager to recognize they burned all the matches in their matchbook, they're a little bit baked and now do I keep pushing them or do I say let's take our foot off the gas for a little bit? And I've done that in the past. You know what? I'm going to the exacts. We're taking a week away from this project. Everybody step away completely. Not telling you to take vacation, but no work is going to happen on this project. And it's, that's not an easy discussion to have because they're like, we spent a hundred million dollars and we need to get going. We're not going to get Any realization out of the synergies, top line or bottom line, if the team just burns out and leaves. So this is the right thing to do. So I'm doing it.

Oh, big on communication and keep it balanced, keep it reasonable.

My job as running an M and A integration practice in a company is to not get into the weeds with the team. If I get sucked into the weeds, I get them. I give them permission to get sucked into the weeds. My job is to watch and observe and understand what's going on with the team. When I say the team, it includes the team that's doing the work on the acquired business side. Because there is a mirror image that I think frequently gets forgotten or ignored, that there are other people on the other side the integration people are working with. And we don't always give them credit for the amount of stress in their life. They're either just about to get acquired or have been acquired. They have no idea what's going on. And most of them were not asked for a vote. Do you want to do this deal? Most of them are just sucked along in the process. They didn't necessarily always want to work for a bigger company, but that's where I think. My job is to check in with people, see how they're doing, understand the work. But sometimes a lot of the teams are surprised, like, I don't want to talk about the work. How are you doing? What's going on? What's going on at home? Anything? How you doing? How are you doing in the pandemic? Do you have everything you need? You want to know about the integration update? No, not really.

Yeah, let's get into that. You got this evolving project plan that's the staple of integration, but what else is owned by integration lead for me.

And this is just me. I'm not suggesting this should be in the job description of integration lead or head of any integration practice. I own everything. And the reason I say that, there's a phrase I use which is called trusted advisor. When we do a deal, I'll just say a material deal. The CEO, the cfo, the coo, the head of sales, they're all looking to me. I don't like the term one throat to choke, although I use it a lot. There's a visual there that sort of probably isn't really appropriate. I think trusted advisors like, do you trust me to drive the right outcome? Yes or no? If no, what do I need to do to gain your trust? And again, that trusted advisor role plays on both sides of the equation. I also need the to be acquired company's executive team and employee base to trust that I'm driving the best possible outcome for them as well. Trusted advisors really would live in Switzerland. Their job is to just be semi agnostic. Yes, I get paid by VMware. That's my responsibility is to support the deal rationale, the executive team, the shareholders from VMware. But my job really is to make sure the right outcome is driven and achieved. And sometimes that means going back to the exact dmw. Like you know what, we were wrong. That initial assumption was wrong. We should not do that. And sometimes that also comes from the to be acquired execs are like, you know what, you guys didn't ask all the right questions in due diligence. Did you know that? We. And then whatever follows after that that helps inform the process and that can change the integration planning approach on the acquirers side. And then people are like but that, where did that come from? That wasn't the initial assumption. It's no, but it's new information and it's right. So again the job is to be a trusted advisor and drive the right outcome.

I like that view a lot. What about this thing called change management?

I know that there's a lot of companies that have change management as a function and either at the corporate or enterprise level or in certain functions. I have drank that Kool Aid in the past over the last, I'd say probably 10 years. My view is that change management is part of everybody's job. If I have to pull in another team to drive change management, I'm just adding more people and more risk to the process quite honestly is my view. And if there's change management folks hearing this, it's just my experience is all I'm explaining. But I think my integration leads. My PMs, my SMEs and the people on the extended teams, they're all responsible for change management. I need my go to market lead to be able to explain to the to be acquired field how their job is changing. How do they get things into our opportunity tracking system? How do they do the actual transaction? How do they follow up on it? Where does that information lie? Because it's going to be different than what they did in the past. I think it's everybody's job.

This is the interesting one because this is where I often hear folks struggle with. It comes back that this is the hard part. Guys glaze over when they come to the conversation around change management. What went wrong points of change management. So it can be real challenging how do you get your team aligned on approaching this the right way?

This is going to sound simpler than it is because change management is not simple. But if I have the right people driving the project and the right aspects of the project, so at the integration lead level, it's a little bit more generic, but not that much more generic. And so I think where change management really happens is I'll use whoever's driving the finance is, which work both for due diligence and integration planning. They should be able to and be comfortable with understanding how to do that other job. They're an accountant, typically, sometimes an FPA person. They should be able to sit down with the CFO's team. The CFO's direct reports say, this is how this new view of your work is going to be incorporated as part of VMware as an example. This is how we do accounts receivable. This is the system we use. This is how we do accounts payable. This is how we do budget builds. This is how we do actuals to forecast the budget. That person should have the experience and should be able to explain at a reasonable level of detail what that change means to that team as they come over. If they can't, then I don't know. We're bringing in a change management member from some corporate change management team and say, you tell the finance people how their job changes. I'm not a finance person. I can't do that. It's incumbent on the functional leads to really be able to drive that discussion, be comfortable driving that and confident in driving that discussion. I rarely have I seen people that aren't. They're usually out of that capability. They have a background. Like, I can still tell an FPA person even though I haven't done FP and A for 20 years. This is what budgeting looks like in our company. This is what forecasting looks like. These are the tools we use. This is the rhythm. We do it typically from this date to that date, every quarter at this time in the fiscal year, for the following fiscal year. It's not, you know, it's not rocket science if I can explain it anybody, there's a lot of people that can do it much better than I can. It's part of what you do, so you should be able to explain it.

So is there a framework driving change management approach within your teams?

I tend to bristle, actually when people bring change management up. I'm like, it's just part of your job. You don't need to identify it as change management. It's part of your job. Just make sure they know what to do, how to do it. Don't call it change management. People react viscerally to the term. If you don't want people to get wrapped around the axle, don't suggest that. It's this big other thing they got to worry about. We're just going to tell you how to do your job in our environment based on how you did your job in your former environment. That's really what changed management is. And yeah, I understand there's bigger, more ethereal thoughts around it, but in M and A integration that's we're blocking and tackling at a base level. It's like accountant to accountant, finance to finance, customer support to customer support, developer to developer. It doesn't need to be any more complicated than that.

I remember we talked before about what breaks and you had an interesting view about looking at that. I don't know if you can rehash that again.

I think there's a couple of views on that. I actually test people on when they're struggling. Kind of back to I don't know what done looks like. A way to react to that is to say envision the following. If you were to do this, would it break what we're trying to accomplish in terms of what done looks like? And it's actually a really simple way to think about it. If one chooses to look at it too detailed, they'll never get to the answer because again, they'll be in the middle of the problem, not at the beginning of the problem. But I ask people all the time what breaks if you do that? Because it's a really simple question that typically has a very simple answer. And sometimes the answer is I don't know yet. I don't know what breaks. If we do this, and the breaking is things like if we go down this integration plan or this specific work stream, does anything break in terms of the asset in the company that we acquired? Culture is a really good example of something that can break from one company to another. Microsoft was everybody just assumed they were being acquired by the Borg. Go back to the old Star wars analogy is thou shalt just you're going to drink all this Kool Aid and if you don't like it, that's your problem. It wasn't a very elegant discussion. Typically it was abrasive and abusive. But that was Microsoft 15, 20 years ago. It's not Microsoft today with Satya running it, which is complete breath of fresh air. I don't exactly miss the days of being in deal meetings with Mr. Ballmer spitting all over all of us as he gets all wound up over what we're breaking in the process. But I think you can go down any work stream and say, does anything break if I do this? Next thing, it's pretty simple. Yes or no. It's binary. There's no sort of breaks. What does that mean? When you break a bone, you either break it or you don't break it. So I think it's a really easy way to test people and not in a way to show them as being. Not exposing them, but saying, look, let's think about this simply. Let's go back. Our approach is simple until it's not because it's self complicated. So let's limit the self complication for as long as possible. What breaks if we do this, what breaks if we close down these two facilities and move all those employees to our facility, what breaks? I've been doing it for a while, so it's not a complicated discussion for me. But if people tend to not think of it that way, it could be a little bit like, I don't really get that. What do you mean breaks doesn't work?

I think it clarifies preserving value. Ultimately, when you start looking at that, I think about the importance of it as well. The two things that we talked about previously that were critical to getting integration right was around employee experience and customer experience. Can we expand on that a little bit?

Yeah, we can. And by expanding it actually means not expanding. Quick story. So when I was at Microsoft, I actually challenged the execs Corp dev execs CFO at the time, which is post Chris Liddell and his five by five. I went to them and said, you know what? I would appreciate the opportunity to run a deal with no more than 10 people all up at Microsoft. The integration lead ran confirmatory due diligence which is largely contrary to most M and A practices, usually corp dev that runs it and or legal. I said, I want to run a deal. It doesn't have to be huge, but it can. I don't want to do some little aqua hire deal, no more than 10 people all up. I want to run due diligence with no more than two pages of due diligence questions. I said, and I can guarantee you that I'll be able to get that over the line. They didn't believe me. Maybe it was a little brash. I was confident I could do it. I knew who my nine colleagues needed to be to get it over the line. I think the days of due diligence checklists with 300, 400, 500, 600 questions. You're starting to get into spaces where you might think you need that information, but rarely do you ever go back and look at it again, which is the litmus test. It's like, why did I need that answer? And the reason, I think from a due diligence perspective, and this does feed into the two chevrons, if you will. First visual around employees and go to market or customer experience. Most due diligence is about the follow up discussion around the how to, the answer they provided. When you ask a question and get an answer, it's binary, right? Ask a question, get an answer. In many cases, the way to really unpack that answer is how do you ask somebody in the field, and maybe it's the head of sales, how do you sell? And that was actually one of the questions I put on it. How do you sell? What do you mean how do I sell? How do you sell? No more words. How do you sell? Four words, very question mark. Once you kind of got over that hurdle, man, you got the equivalent of 500 questions answered. Because they're like, oh, we start with the leads and then we follow up with the leads and then we contact the customer and then we go talk to them. This is what our technology does, this is what our product does and then this, okay, so you take the lead and then you get to an opportunity. So how do you unpack the opportunity? What is the opportunity? You get all the ANSWERS In a 30 minute answer and you don't have to sit there and put 500 questions in front of somebody. So the way that reverts back to your question is there are two things you have to get right in integration. And it doesn't mean you don't have to get the rest of them. But if you get these two wrong, the rest of it does not matter. You need to drive the right customer experience. Customers equal revenue. At the end of the day, that's that you put the equal sign in between customer and revenue. So what do you do to drive revenue while you engage customers? How do you engage customers? But that has to happen after. How do you drive a successful employee experience? Salespeople are employees. If they don't like the process, they don't like their commissions, they don't like their quota, they don't like the technology or products they're selling. Your revenue gets impacted because they're going to leave, they're not going to want to stay. So the employee experience is really and I'm not just talking about hr. And when I say employee experiences, do they like their new job? Do they know how to be successful in their new job? Didn't say change management, but that's what change management is. This is how you're successful in your new job. You don't call it change management, you call it success. Like, people get into that. Like, change management sounds like something out of a. An HBR article. And you're like, oh, God, I didn't read that one, damn it. Sorry. What does success look like? Everybody can talk about success. You don't have to go reading a bunch of online stuff. What does success look like for you in this job? As part of this company? You can double click your way from the employee experience pretty quickly, pretty deeply. But again, you got to start simple. This goes back to my. I'm just such a huge fan of start simple, stay simple as long as possible employee experience. You get that, you're golden. Because then everything else follows. And if it's a value driven, revenue driven deal, meaning you got a top line that comes with it, it includes customers, it includes field people. So there's a lot in that. But if you drive a successful customer experience, I think you get those two things right. You've got 75 to 80% of what you need to drive a successful integration.

What you're describing, this whole interview is around your approach with the people, the relationships you're forging, being able to connect with them. Set the example of, forget about the list, let me understand what's going on in your world. It seems like that's ultimately one of the bigger underpinning lessons from all this whole interview.

It's people, yes, but it's more specifically Kiesen. It's the relationships with those people. We did the Bizetle deal at PayPal. That was the biggest deal I drove when I was there with my team. And it was awesome. It was in the Nordics. I love Sweden. People were really nice. They were about to go public. We were able to do a deal, sign the deal 10 minutes before they're about to do their float. It was an awesome experience. And by the way, we drove that deal with five people because it had to be kept really quiet because they were going to float and go public. So it had to be kept. So super double secret handshake, quiet. But the relationship, me presenting to their executives like, this is what we're going to do to you once we close this teal. I. E. Integrate. They just looked at me. They're stoic surprising, nodded their heads a few times. And this was with the CEO, the president, head of sales, their key executives. And I said, do you guys have any questions? It was about an hour long presentation. It was really high level because we had spent so much time getting the deal part done that we hadn't really figured out the integration part. And it was really quiet. It was uncomfortably quiet. And so then I went and talked to one of our legal folks in country legal, external counsel, quite honestly, who was Swedish. I said, that was weird. Why was that so quiet? I said, they're thinking about what you said. I go, but why didn't they ask any questions? Because they're thinking about what you said. They're not reactive by culturally or otherwise. Okay, so when do I get to find out what they actually think? He goes, you know what? Now I'm going to forget what it's called. Having coffee in Sweden is called something. It's like a coffee break. There's a specific term for it, and I apologize for not remembering it. And he said, go do this. Invite them to a coffee. Have a coffee with you. Don't invite them out to dinner, don't invite them out for a beer, Go have coffee with them. So I did that with each one of them. All of a sudden I got all the questions and why? Because I was building the relationship when they sat down and realized I wasn't just this guy that was just there to ramrod their company into our company. And they got to know me as a person and that I was their trusted advisor. If you guys have questions about things, don't go to the execs, come to me, use me as the first filter. And I'll tell you what, at least I think would happen if you ask that question, what the answer might be, and maybe you don't have to go ask the question. And so once they got comfortable with it and they asked me the questions literally to a person, and I had coffee with every single one of them individually from that meeting. Like, we'd been buddies for forever. And I was like, okay, maybe I should have done a little more cultural homework before I went over there. But again, it's the people. Yes, but it's the relationships with people. I'll be really honest. I know this is hard to believe, but not everybody likes me. When you make that effort, people are like, you're here to help me. Is that what I understand? I am. I'm here to help you, to help me drive a successful integration. I can't do it without you guys. If you're not on board, you're going to pocket veto. What I do, what I say, what I suggest, and I'm not going to get anywhere. And then I suffer. I'm not doing my job. That's why I talk about the relationships so much.

I can see how the relationships lend to change management success. I'm going to try to get a couple of questions in one here. Scott, would you differentiate the benefits of playbooks of templates and a consistent approach to the M and a process that can live beyond any individual team members who may leave a company? How do you think about continuous improvement of the process and capturing those learnings?

Really good question. So templates are typically part of a playbook. This is how you drive your integration plan. You know, everybody uses a different M and A platform. One time I was at one of the big conference board meetings and they asked my boss what integration planning platform we used and he said PowerPoint. That's what we used. But I think the real answer to the question is you take those learnings via post mortem. What worked, what didn't work? I think it's that simple. And you feed that back into the knowledge base. But it doesn't have to be back into the playbook. Like we have a SharePoint site where we have all our postmortems from all our deals, where we've done postmortems and we don't do them on every deal and they're there for people to go look at. And you sit there and the deal I'm working on today looks like that deal from a size and complexity perspective. So you go back and read the post mortem, it's this summary view of really what worked, what didn't work, and hopefully with suggestions of what would be done differently the next time.

I like it. I got one question here that we sort of touched on in various ways, but Hannah's asking, what does a successful integration look like from your perspective? Maybe you can even open this up for just general advice to other integration practitioners.

So I think a successful integration is when you have an agreed upon vision of what done looks like. And the reason it's got to be an agreed upon vision and the resulting plan is that things like legal entity consolidation are never done in a year. Like sometimes those things take two, three, four, five years because of regulatory issues, tax issues, whatever. If you incorporate that as part of your definition of done, you're going to be working on that deal that entire time, which to me seems ridiculous. There's other people that can Take that once the handshake happens as the acknowledgment agreement of done. So again, defining what done looks like, and then having that final meeting with the business and all the key leadership that's been involved and say, this is what we said we would do. We've done it all. Do you have any questions? And then you have virtual handshake or physical handshake. That's what a successful integration looks like. The difference is what was NAS is successful integration does not necessarily suggest successful deal, which is a whole different ball of wax that we won't get into here. But I just want to make sure it's a great way to ask the question.

Save that for another interview.

And that's not me in that interview, by the way.

Jim, what's the craziest thing you've seen in M and A?

Probably the craziest thing. When I was in Microsoft, we bought a photogrammetric business in Boulder, Colorado, and if you can phonetically sound out photogrammetric, you can go look it up. For me to explain it would be an abuse of the technology, but basically it's tiles. You see, like when you look at Google Maps or Bing Maps or some mapping technology and sometimes your Internet connection is slow and you see the tiles that build up photogrammetric technology is the ability for an algorithm to stitch together the data that's building those tiles. Don't confuse me with somebody that actually understands that, because I just read that somewhere and can say it. So we did a deal. There wasn't a huge deal. We were going through due diligence and there was a few last remaining items that they had been holding back, and they were significant in terms of materiality in getting the responses to these questions. I had to go to the CEO and said, look, we're about to close this deal. These three questions are still outstanding. We're not doing this deal if you don't give me the answers to those tonight. Give us time to look at this and still hit our close deadline. And he goes, we're close enough. We just need to be done. And this was not. This is like a $50 million deal. It wasn't huge. It was important, but it wasn't huge valuation wise. He goes, well, I'm not going to give you those answers. I said, well, then we're not going to do the deal. He goes, you have the power to make that decision. I said, I have the power to inform the executives that can make the decision of what my input is. And my input would be that we not do this deal for the following reasons. And this guy was a double PhD from JPL. The rocket scientist thing is real. And this is where I learned it. This guy ended up being a great guy. And we still stay in contact to this day. So he said, look, I'm going to talk to my cfo. I'll have an answer for you tomorrow. So I come back the next day. And he was like, we just want the deal to close. We'll figure this out later. I said, no. The crazy part of this was I said, so I was coming from sea level. This was in Boulder, Colorado, at altitude. I said, let's go outside and let's go on a walk. Let's talk this through. I don't want to be in the office. It's your domain. You're sitting in the power seat right now. Let's go out on a walk and create a common ground. We went out and walked for three hours. I was dying. I was like, literally. And I'm a runner, but running at altitude is different. And we walked for three hours on the bike paths of Boulder, Colorado. And I don't know who wore whom down, but I eventually got the answer from him, literally, because we went on that walk. So again, kind of definition of crazy. It was crazy in the fact that it came down to that late in the process. And the two guys had to go on a long walk on a bike path to get the answers that were needed at the end of it. He said, we have the answers. They'll be in your inbox by the time we get back. And he called the CFO and says, send them the gym. Give him the answers again, relationship building. Figure out that common ground. There's a lot of crazy stuff that can happen in M and A and sometimes you just gotta make it up as you go along.

Yeah, the variables and what it takes to get a deal done.

Exactly. Go on a walk.

I enjoy the conversation. Thanks for the time today.

Yeah, thank you. Thanks, Keith. I always love talking with you and love the riffing back and forth and hopefully the folks online got something out of this.

My pleasure. And here's to the deal. Thank you for taking the time to explore the world of MA with our podcast. Please subscribe for more content and conversations with industry leaders. If you like our podcast, please support us by leaving a 5 star review and sharing it.

It.

I enjoy hearing feedback and connecting with our listeners. You can reach me by my email. It's Kisan K I s o n ealroom.net M&A science is sponsored by Deal Room a project management solution for Mergers and acquisitions. Additional educational content is available on Deal Room's blog@dealroom.net thank you again for listening to M and A Science. See you next time. 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.