How To Succeed in M&A Integration and Measure Success

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.

Welcome to M and A Science Live, where leading M and A practitioners share lessons learned from their experience. If you're interested in keeping up with the latest from M and a science, visit mascience.com and subscribe to our free newsletter. Every Monday we share highlights from our interviews and publications so you can continuously improve your M and A skills for free. Again, that's mascience.com today I'm here with Jim Buckley, Vice President, Mergers acquisitions integration at VMware. Those of you not familiar with VMware, it's a NASDAQ traded company with a 60 billion market cap that specializes in cloud computing and virtualization technology. Today we're going to talk about how to succeed in M and A integration and measure that success. How are you doing today Jim?

Good. How you doing Keeson?

Pretty good. Honored and happy to be here with you. Maybe we can kick things off with a little bit about your background.

Yeah, sure. And thanks for inviting me. This is a great opportunity. I appreciate it. And I'm not used to doing this. I'm the guy that likes to go in and hide and do work.

Don't thank me too much. I'm going to give you a hard time on this interview so when we're done then you can decide.

So, Background My first real job was Sun Microsystems back in the 80s. I was employee number 190 there and I was an ops guy. I ran their stockroom, shipping and receiving. I had a pretty general business degree from Santa Clara University, so I couldn't write code, but I could figure I could manage parts and people that knew how to deal with parts back in the days when we had components and things in the US and built stuff that actually led to a job in cost accounting of all things. And I was a horrible cost accounting student, managerial accounting in school. Somehow the guy said, well, somebody that knows how to handle stuff can apply some Math to it, yeah, that's a good job. That led to an FP and a job. So I was at sun nine years. Bounced around the Valley. Worked at Silicon Graphics. I worked at a company called Radius. All those were finance jobs. Accepted Silicon Graphics. I managed a production control floor. We built the enterprise servers there back when they were trying to figure out how to take video technology and convert it into enterprise data pipes. And then I ended up at a company called Mentor Graphics that recently got acquired by Siemens a couple years ago. And I was the division controller for their PCB design group. We started doing M and A, and the company wasn't big enough to have anybody that really knew much about M and A. No Corp dev team. And so I got voluntold to negotiate a few deals, do the due diligence, and then figure out what to do with it afterwards. My boss at the time had a lot of faith in me, a lot more faith in me than I did. One of my key learnings out of that opportunity was our first deal, and he had to leave to go on another business trip. He said, you need to stay here and run this thing for a while. Be my eyes and ears. I'm a finance guy. I built the valuation model. I don't know what these guys even do, really. Words of wisdom that I still remember this day, and I won't use the word, but he said, just don't F it up, all right? I don't know where that bar is set, but I'll make sure I don't do that. I learned real time. I had no real mentor in M and A. I learned, I'll say is the hard way, but it wasn't really that hard because it's problem solving. That's really what M and A integration is. A lot of it is about. So I was a mentor, got some deals under my belt. Microsoft found me, recruited me up to Redmond. The five years I was there, we did 99. Zero deals. We were busy, very acquisitive. Big deals, little deals, everything in between, and global as well. And from there I got recruited to VMware to set up their M and A integration practice in 2010, did that for five years and got recruited away PayPal to set up their integration practice. Post spend from ebay. And then VMware did two large concurrent public deals a couple years ago. And they called me up and said, please come back. And so I came back and ran those, and now I run the entire practice again.

A lot of different types of deals, size deals, what's Interesting is your background because you came from this financial analyst, FP&A and you touched some ops, project management, and then get over to integration. In your experience, how does your background help you with your current role?

Well, I think the consistent thread is really everything that I've done has a thread of problem solving in it, whether it's operational, financial or integration. So that's consistent, but that's not terminally unique to just my background. You give a problem to a software developer and say, solve this by typing ones and zeros. It's similar, but it's problem solving. For me specifically, what I learned was what I did in financial planning and analysis really helped me me become doing what I am in M and A integration. And what that really means is there's two functions in a company. Assuming they have an M and A integration function. FP&A consolidates everything that happens across the company, both top line, bottom line. And then the math comes out to a net income number. But it's the one place where you touch every function, you touch every cost center, the top line, the bottom line. And what we do in M and A integration is very similar to that. We touch every function. We figure out, do we integrate it? Do we not integrate it? Does it fit? Does it not fit? If it doesn't fit, do we want it to fit? How do we make it fit? Do we use a hammer? Do we use duct tape? Anything in between? My experience is very biased, but I think that FP and A background really lent itself well to my career, which has been the last 20 plus years. Just in M and A, is it.

Because you understand how the organization's spending money or how these functions are spending money and then be able to kind of roll that up as you look at how you integrate a company?

Yeah, well, you used the operative word, which is how it's important to understand that numbers or the costs, but it's how are they generated? I use that approach a lot with my teams and due diligence. Like you can ask all the due diligence questions. You want my experience what real key questions are about. I understand you responded to the question, but how does that work? You can ask a question, what do you sell? And they'll respond, we sell this and that. How do you sell it? That's where the real magic happens. And that's where you have to listen like, do they really know how they sell? Do they really know how they develop? Do they really know how they manage people? So the how and the why is almost more important than the what makes sense.

Can you walk me through that? And just. I want to understand the lens a little better because I am trying to imagine being that person that understands. It's almost like you're doing it backwards. You sort of understand the financials and then start thinking about the how. Would you correlate, like, bigger line items with bigger things that are happening? I see it. Big line item for ERP software that we're paying for. And then start correlating that with what's going on behind that and start driving towards that how. What does the thinking actually look like?

The how really is the precursor to developing the end state and then working backwards. So again, you're thinking about it the right way, at least. My approach is, where do we want this thing to end up? Are we combining assets? Are we combining some assets? Are we ditching some assets? But what is the end state? Or the North Star is used a lot, but that got kind of old, at least for me, so I started calling it the end state because just to mix things up. Once we understand what the agreed upon end state is, is really driving the value for the deal, then you start working through the gates, coming back to the beginning. In that process, you start to look at things like SaaS. And subscription is a great example of figuring out the how, because everybody does it different. There's no one size fits all VMware. We're on that transformational journey right now from ELA on prem software. Big go out and generate a $10 million license and you're done. Versus sell them a recurring revenue stream based on usage and then grow it over time. So the how starts to come into that dialogue when you're like, so how do you generate revenue? We sell subscription software. How do you set up that subscription can keep double clicking, like on a Google search, until you get to the end or until you get to the level of depth that gives you enough to move forward, to start building your plan. And the thing about SaaS and subscription is it's all about the product. It's all about the sales motion, it's about the support motion, it's about the revenue generation. There's so much encapsulated in that that it becomes better to go slow, make sure you don't miss anything, because it's basically math, right? It builds upon itself. Then you start to say, okay, we've got a model that says, generate this much revenue, how do we get to that number? Show me the math that gets to that number. Then it's, what are the costs associated with getting to that number. Again, back to the FP and a comment decent is that I look at everything through the P and L. Not everybody does that. I just do because I'm an old finance guy that wasn't really good enough at finance to keep doing it for a career, become a cfo. So I became an M and A guy. When I look at things through a P and L, I can start to look at certain cells and Excel spreadsheets. Okay, that revenue number in that quarter is built on and then understand what, what are the major drivers for and how are those driven and then all the cost elements for every function and then headcount. And so it builds upon itself. The big ones are easy, but it's the little ones over time or the one plus one over time that actually is additive and bigger than that big nut like around an SFTC license or something.

The theme of this interview is start with end state, work your way backwards and understand how you're going to achieve it.

Have you heard the analogy of when you're navigating, if you start at a point and if you proceed just one degree off from that point and over time you become further and further away from your desired end state. So if you don't start with the end state and work backwards, your navigation is going to be all wrong. You could be targeting to get in Boston and end up in Des Moines, not your desired end state.

I think there is a variable definition of what end state means to people in the context of M and A, especially because people may talk about an end state and it's just very high level. We want to combine these product lines so we can cross sell. That's kind of where it's left off and hand that down as this is the end state. I wonder if we can talk a little bit about that. Like how much do you actually crystallize it and how do you communicate that across the participants are going to be involved.

It takes some time to develop the confidence to be able to. Because usually that dialogue is with somebody pretty senior like your CFO or the CEO or an SVP of a product line or a business unit and they give you this sort of smarmy kind of like, you know, we just want it to be really successful. We want the customers to be happy and all the employees to be happy. And yeah, we're going to spend $5 billion. So just make that work. Yeah, no, that's not enough to go on. It's some of it. It's a little easier for me because I'VE been doing this for a long time to lean in and go, no, I need more than that. And here's what I mean by more. We're going to acquire these product lines. They currently generate X revenue, they're currently supported by X employees. Basically taking their business model and teasing it apart. And then the execs go like, what do you want to do with these guys? They're at $2 million a year in revenue. Our valuation model says 5 million. So there's got to be some sort of synergy to get you from 2 to 5. What are you thinking about that? Most have an answer but you got to hang in there because they haven't necessarily thought all that through. I don't know what everybody else's experience is with corp dev teams and finance people, but you gotta be able to press them on their assumptions. People love to spend the shareholders money. If it's a public company, it's easy. I have yet to meet an exec that doesn't love to do M and A. They just do. If we're gonna go buy this thing and then bring the little red ribbon wrapped package, put it on my desk and then go do whatever you do, that's not how this works. We're going to unwrap that package and we're going to figure out what we really got and then we're going to go hit your numbers. Whatever the synergies are. I'm not a big fan of the word synergies because I think it's one of those overused terms. It's like what are the goals? What are we really looking to get? How do you get from 2 million to 5 million? I'll help you get there, but you got to pave some of the road here. I'm not doing all this.

The part that makes sense is validating your assumptions as part of defining that end state. Because you got a financial model behind driving the deal. How we're going to financially do the deal. Within that are a lot of assumptions around synergy. Slash goals and being able to define that, work through that and help that build into the end state as well so that there's more pillars or substance in there.

That's the thing. When people are building models and I've worked with some incredible core dev teams, people that are really willing to partner. Well, that's not always the case. Sometimes, never the twain shall meet. Corp dev builds a model, drives a deal and then throws it over the wall. The integration team catches it. What is this? But I do think working closely with those people that are building the components to build the model. Because frequently what you'll get. I'm sure a lot of people have had this experience where you'll get a revenue number that doesn't have a lot of data behind it, but it supports the valuation. When I'm at a point again where I'll sit in there and put a meeting with very senior. I did this a few times at Microsoft and almost got walked out of the job and the building because I was pushing a little too hard. But I'm like, and that number makes no sense. Well, it supports the valuation. So you're solving for the valuation and I got to solve for the business results. That does not sound right.

Isn't that how it works in a public company? You just round numbers up and hey, being public, economics work in your favor as long as market cap keeps growing.

I don't think that worked very well for Enron. But something along those lines. We'll just keep rounding the numbers up until they're right or not to get the deal done. Figure out that's what it's like. This is what it's going to take to get the deal done. And that's why I think it's really important at least if not the integration lead, maybe like in my role as the leader of the integration practice, get really early purview and insight into that deal because I can ask those questions. What place did you pull that number out of? Because there's nothing of substance here.

Okay, so I want to talk a little bit about when integration should get involved and this has been interesting. I've been doing these podcasts for about five years now. And I remember Early Beginnings was so common to hear that thrown over the wall in this terms of I usually get a two weeks heads up when a deal is coming our way. We've seen a shift primarily in the last two, three years where now there's this clear emphasis on integration, the importance of it. Are we going to make value during integration or destroy value? Let's really think about that ahead of time and plan for it. How have you seen that evolve and how it should ideally play out?

So it has evolved in the last few years and again, I think my start in M and A, I sort of own the whole thing. I was the division controller, I was the numbers guy, I built the model. So I was accountable for my own model. Like, you know, whatever I made up, I paid for downstream. But that doesn't happen nowadays. And that was back in the late 1990s. 1999 actually when I started this journey. But it has evolved. The partnership between core dev and integration, the business units at Microsoft when I worked there, 2005 to 2010, Microsoft was Microsoft back then. It's different than it is today with Satya leading it. It was back when Steve Ballmer was running it and running down the hall and yelling at people, asking us why we F this up and F that up. And we're like, yes sir. And then he would take us to math camp. I'll explain how this model should work. We'd sit in his office, he'd go through the deck to get the deal approved, get his approval before the board and I'll show you how to model this. And you get up on the whiteboard and start scribbling a bunch of stuff. And corp dev guys are just sitting there going, eyes wide open. We're laughing at the corp dev guys, integration guys are. And then we're just looking at Bomber going, I think he's right. We'll come back with a revised model. But the partnership there was really good. That was about where I really started to learn about corp dev's primary goal. In a different world, they should be as responsible for the outcome and the results over time as anybody. The reality is their charter is to acquire value. The integration team's job is to create value. And that's why I look for people on my teams that have really varied backgrounds. Because value can be ascribed a bunch of different ways. It's not just a currency. Are the people happy? Is the technology quality? Did we get a good team writing code? If we're bringing over any of the back office people, like, are they going to be really additive to the business? Are they going to succeed in a bigger company, coming from a smaller company? The hardest part is really the go to market side. Is their field going to be able to do what we do the way we do it? Or heaven forbid we should actually have eyes wide open, Said, maybe they do it better than we do and maybe we should try their way. I think that's where the integration team, again having this broadcast matrix view of how the company works, is really how you create value. My experience, anyways, it's as much about turning the big dials as it is about turning the little dials. As we were talking about earlier, is it the big thing you're looking for, the little thing you're looking for? The answer is yes, because there's a lot more of the little things that add up over time, become a big thing in aggregate.

So we got a couple things we got having a good partnership with Corp Dev. I want to get back to the. When you find mentioned finding opportunities, when you need to stop and say we need to change ourselves and actually learn from them. But the other one you mentioned was essentially understanding the company. The more you understand the company, the better you're going to be able to integrate it.

The comment there is bigger than that. And I've actually asked this question my team in the last couple of weeks, I said who does due diligence on the acquirer? Does the team doing the work actually understand how our company works? VMware is a very complicated company. It's very, very, very cross major. It's the technologies complicated, the selling motion is complicated. We've got business units du jour kind of thing. One day there's 15, the next day there's 23 and then it's back to 10. And that's every big enterprise software company. But before you start poking at the target, make sure you understand how we do things because your job is to fit tab A into slot B. If you don't understand our side of it, then how do you know how to integrate them? How do you know where to plug their stuff into our stuff?

How do you approach that? That's a good thought. It hasn't come up where they need to have diligence on your organization. The target should and that would probably help them open up things, expectations, understanding of how things are going to go down.

A lot of it is having them. Like yesterday there was a big presentation by one of our VPs of it that's actually been at BMW a long time. And he actually presented the product portfolio from an IT perspective and I had all my team sit through it. It was dry, it was boring, it was dull, but it was informative. That's why nobody wants to do it because they're like, that's boring. I like the M and A part. The real sexy part, that's the fun part. Like you will massively screw it up if you don't know what you're plugging them into. There's a lot of learnings, opportunities, classes that can be taken around product and overall company. But I also think some of it just comes with time. You incur enough scars in certain areas and you learn. I do need to understand how this works. Another example Kiesen is Microsoft. When I was there for as big as it was and with 90,000 employees and some, I don't know, 30, 40,000 contractors, they had business units bigger than most Fortune 100 companies, but it was not hard to work at. It was really pretty easy to understand how Microsoft worked. And I think that was driven out of the gate early on from Bill and Steve because look, we're going to be big, so let's not make it hard, hard enough. There's a certain challenge to just the depth and the breadth, but it was one of the easiest companies ever worked at because it was just big building blocks. It was big Lego pieces that all operated very similarly. So when we'd go from business unit deal to business unit deal, you didn't have to do a lot, a lot more homework to understand how they work. You'd have to do technology homework. You didn't have to do a lot to drill into how they work.

Can you walk me through an example of you can make up a deal right when you're acquiring a company. It actually be interesting to even think about the beginning of where you get involved and start understanding it from the integration perspective. But then that point example or concept of that company being able to do diligence on your organization to understand it. I'd like to get an example of that just to crystallize a little bit because I think it's something unique that I don't hear anybody else talk about it.

I'll be self indicting with this comment, but I think it takes a certain type of personality to be brave enough to insert themselves as far left in the process as possible. I did it at Microsoft as a director level, which is wasn't vp, but it wasn't software developer one. But in the middle, from a hierarchical perspective, I was just annoying. I'd find out about meetings that I wasn't invited to and just show up and say, you know what, kick me out, disinvite me, I don't care. I think that's one thing that happens over time is you care less about what people think about why you're there. Kick me out. If you want me to leave, I'll leave. I'm not going to sit here and throw my pencil against the whiteboard and throw a fit. But I think I need to be here and here's why. And the why is the conversation early on is really important. It's not about things that go in the deck. It's about the dialogue around the things that are going in the deck and the things that go in the deck really early on, around the pre loi kind of phase before you get the letter of intent drafted and sent over. Okay, why are these guys really important? What Problem does this companies solve for us? It's back to yeah, the what's important. But okay, how do they do all those what's. What's their secret sauce? Okay. They really get a branding a big pile of code that isn't really worth much. We're just going to put it all in goodwill anyway. So it doesn't really matter if you can get involved early on in the process. And it doesn't mean you got to be there with the initial conversations. But pretty close to those initial conversations. This is really helpful earlier the better. Absolutely, yeah. I mean it's just that simple. Again, I'm not going to tell people. Don't worry about being invited. Just show up. At a certain point in my career, I was much more comfortable like, here I am, deal with. Also helps if you have a really long white old beard.

I was going to say the beard just allows you to do that.

People don't want to throw Gandalf out of the meeting.

Beers don't give a shit what you think they're going to do there. And you need to hear them out.

But you just sit there and like, you have a question. Are you trying to make a point? Really? No. Come on, let's have this conversation. But deals evolve over time. There's this initial opportunity to solve a problem, which is what most acquisitions are. So we want more revenue, we want more product, we want awesome code writers. They got a great architect, they got a lot great customer base. They sell into customers we don't sell. Whatever all those little dials are that build the model and build the solution. That is when you start to really synthesize what that early integration view is going to be like. How am I going to create value out of this thing? They're talking all these different play DOH and LEGO pieces. How am I, the integration lead and team going to take that? Okay, I understand what your vision is. Now I'm going to. It's probably not dissimilar to an architect drafting a blueprint that a GC and a bunch of subcontractors have to say, what was that guy thinking? That's not going to work. But this is a better view of it. Honestly, it's not that dissimilar than building a house or a commercial building. You sit there and some architects and they're going, okay, I'm going to buy. I'm going to build an 85 story building in the middle of Chicago. There's a big lot we can go dig a big deep hole in. And then you've got 85 stories that are all kind of rinse and repeat all the way up, but it's not always rinse and repeat. And you got an elevator here and you got wiring up the wazoo and you got pipes and conduit. And this view is great. That view stinks. And that's the dialogue that's really interesting and important I think for integration teams to hear is that doesn't go in the deck for approval for an LOI would you've heard it, you know now of back into what that conversation was based on what's in the deck and that's what you can carry forward.

How the contractor look at the blueprint before you sign. I like it.

We were talking about houses and things before and you look at those as a home buyer. You have new developments and you look at the different elevations they show you. Like this house has a pitch roof. This one has three gables. This one has two fireplaces. And you look at that. Like that looks awesome, but that's like some. It's like an artist rendering. Like it's so far probably from reality. What's behind the watercolor or the ink. And that's where if you keep double clicking on it and then make it real, then it's tangible, then you can do things with it. Well, what if you took this room and moved it here and I don't want the sliding door there. I went French doors. I want. I want it to be all hardwood, not carpet. And then you start double clicking it and it's not again dissimilar to integration. It's like, I know you want to do that, but it doesn't add any value. Why would we do that? There's a cost with it.

So. And that's benefit of getting involved early is putting those kind of considerations up front, having that time to look at those different scenarios and options and make those decisions.

Yep.

Can we get to that part about the target company when they start doing diligence on your organization? When it fits in. We're in the timeline. And are you sitting in that room on the left side to hear how you engage it?

It is interesting because not everybody does it. It's a large business, a large public company acquiring a small startup, depending on what value the startup is bringing to the large company. And I've been in those conversations. Do you guys have any concerns? Like Microsoft again is a great example. Microsoft was the Borg that was just going to consume everybody. And that's what all these companies thought. I'm going to lose my brand. I'm going to lose our mojo. But my bank account and E trade account is going to look really good. So, like, what do I want to do here? How hard do I want to press on this stuff? And there was one company we looked at as a deal that I worked on in Madison, Wisconsin, and the CEO was convinced that he should report to Steve Ballmer. And these are really early in the conversations. We were going back and we hadn't even entered. There's still preliminary due diligence, so that I was able to get in that early. Not pre confirmatory due diligence, pre loi. This guy's like, yeah, you know, I think this will be a really good match. I think we'll bring a lot of value to Microsoft. He goes, but I'm a little concerned about how we're going to fit in as an organization. He goes, I think I should report to Steve Ballmer and we should be like this little incubator for him. And the inside voice is like, don't make a face. Don't make a face. Don't roll your eyes. Don't make a face. And so we just let it hang out there. It was just a corp dev guy and I, and then we laughed and then we had dinner and we were talking about, what'd you think about that comment? We're both like, nfw. No. Like, you might be five levels down, six levels, maybe seven. I don't know, dude, you're just not that important. But you can't say that because it's all about relationships, right? That's really a key cornerstone for M and A is those relationships. So over time, once the deal got real, and at Microsoft, the integration team led confirmatory due diligence, which is a little unique. Usually it's corp dev that leads it. Microsoft, the integration lead would lead the confirmatory. And so I got to build a relationship with this guy. And he goes, you guys have never answered my question about reporting structure. I just looked at him, I said, you're right. And just to be really clear, it's never been up for debate. You're not going to report to Steve Ballmer. Did you ask Steve? No, I didn't, but I know the answer. You're not going to report to Steve Ballmer. I don't know if I want to do this deal. Then I'm like, okay, let's have the parent child relationship kind of discussion here, dude. You're going to make some pretty good coin out of this deal. And you're going to work for two years you'll vest all your stock and then you're going to go. You're a serial entrepreneur. I know how you guys think, right? You think you're going to hang longer in two years? Probably not. You think you're going to make a lot of money out of this deal? Probably. Does it really matter if you report to Steve Ballmer or not? But it would look so good on my cv. It's not going to happen. So if that's going to blow up the deal, that's going to blow up the deal. Good luck explaining that to your investors. You got to play that card at the right time because you don't want to break the relationship. But it's also, I think, another thing that's coming out of this, Kiesen, is really the integration leads need to be trusted advisors on both sides of the equation. I work really hard to get the target company to trust me. You guys have to trust me. I can help you make this deal really good for you. But I'm also Switzerland. I'm not here to cram a bunch of Kool Aid down your throat from corporate. That's not what I do. My job is very pure and simple. Do the right thing, make the right thing happen. That's it. And sometimes, yeah, corporate's not going to like what I say, but they can't argue it because it is the right thing. So I take the Switzerland role right down the middle. My E Trade account doesn't change whether we do the deal or not. I've had that discussion too. It's like, dude, you're going to make $50 million out of this deal. And I might get another thousand dollars, my bonus. I'm just here to do the right thing. I'm here to do the right deal. You get 50, I get a thousand. Everybody's happy. I could be happier. But that's a different discussion.

I want another example. This reverse diligence idea I'm still stuck on because I'm imagining our marketing team listening to this, that we could write a play. Cause we have this whole public library of plays on mascience.com plays. The idea is open source M and A as much as possible by creating these short form. It's actually modeled off of Atlassian does Atlassian has team plays. So it's all these project management techniques and it's all step by step how to do it. So if you run out of ideas or just frustrated with people not getting shit done, you can reach in a bucket of plays and try things or just build your approach around it and saying, hey, instead of following checklists, we have these plays we follow. So that was the whole idea. But this would be an interesting one. We did an interview earlier in the year with Jerry Will about how they use red team exercises to knock off the biases on deals. But I like the idea of doing this reverse diligence. I want to get a little bit into like what would be the step by step to explain to somebody, how do you do that? How do you prep the team? Who, who would be involved? You set up a formal meeting and explicitly trying to convey what the company like you mentioned with the Microsoft example, this is what our org structure looks like. What are the key things that they would want to learn or how would you deliver that to get that kind of effect? And I guess what are the results out of it? Are they coming in with a better attitude? Are you more synced up? Is there less resistance?

And I have not gotten to the point with a target where I said, you know what, you really need to ask questions of us as well. I've never been that proactive. It's up to them. But I will suggest around the fringes, like, look, this goes a lot better the more you know about us as well. Got it? If I was sitting in your seat, it might not be one to one. We ask a question, you ask the same question kind of thing, but there's at least 10 questions you want to ask us. I actually, I have had that dialogue and I got a pretty bird kind of look like, what's he talking about? Don't you want to know? Like, how is your technology going to be used? I don't think it's a surprise. But the dollar sign is floating around every conversation. This is a $5 million deal, it's a hundred million dollar deal, it's a billion dollar deal. And people are getting compensated for their hard work to build a business that gets acquired. But it can be a bad deal or the target just as much as it can be a bad deal. The acquirer, where it's just not a match. Like you're going to destroy everything you built. There's no incentive on the acquiring side for that to happen. So I'm actually more prone to be really hyped on a deal when their CEO, their president, their senior execs are like, how is this going to work? How are we going to fit into your business? Or even the dumb question that is absolutely not dumb is like why do you want to buy us? Like that's a really hard question to Answer. And it goes back to earlier in the conversation, Keystone, where it's like the integration lead talking to the acquiring exec. Okay, so you got all the fluffy purple, green, pink stuff out there, but what does that mean? What are you really looking to get from this target? That conversation should be bilateral, both directions.

You got a little book to write out of this, like integration prep right here or handbook. There's a lot to go into that part of the process nobody talks about. I don't hear anybody talk about it in a lot of these interviews. It seems like that would be the enablement. We talk about post TMI success and how do we make these deals actually work.

If you think about a sales exec, it's in the conversation earlier. It's like, how are you guys going to sell my stuff? There's a $10 million revenue associated with it, so we'll figure it out. No, that doesn't work. How are you going to sell my stuff? Are my guys going to sell my stuff with your team? Are my account execs going to partner with your account? How does that work? What can I tell my team? You should be excited. You're going to be exposed to really smart people, whatever that dialogue might be. Actually, me using a sales example is really bad because I struggle with salespeople in general. And that's publicly disclosed. Like, that's the hardest part for me. The execs that ask those kind of questions are the ones like, this deal is going to work because they're really invested not only in what the payout is, but how is it going to work? Like, how is the company going to succeed as part of the bigger company?

I really like that. The part I want to jump over to was integration. Success as an integration leader, how do you measure success and integration?

Well, the easy answer is, so if you think about the process early on, it should be written in really dry concrete is you have strategic rationale, you have deal value drivers, then you have success metrics that are driven off the deal value drivers. That's pretty straightforward. That's just one on one kind of stuff. Making the assumption that the integration team is tasked to drive to the success metrics and measure the success metrics and ensuring that the metrics are measurable. One of the things that really bothers me is when you sit in these meetings like, well, are you red, yellow or green? It's like, well, we're green. Okay, based on what things have been going really well and people smile in the meetings and blah, blah, blah. And no, what metric Are you using to measure against what is the number? So it has to be quantitative, not qualitative. But it's really hard to do that because people, I'm sure a lot of people in this are sitting in these meetings and people are like, we're green today or we're red, but we're going to get to green really well. And here I'm sure this never happened to anybody. How are you going to get to green from yellow or red? Well, we moved the date out. No, that's not how that works. You're just red into perpetuity. You don't get to just change the date so that you can hit the new date or the second new date and then call yourself green. That's not how that works. But I've been in meetings where that's actually happened and I'm just like sitting there going, how did you get hired? That's ridiculous. But so back to the question. I digress. It's really understanding what the success metrics are and being able to drive to them based on the integration plan. Assuming the strategy stays consistent. Sometimes the strategy will change post close for different reasons. I was at Microsoft in 2008 and the economy was in the tank then. Businesses were struggling everywhere. It was really hard to measure success because people were missing the numbers. There was rifts going on, people were losing their jobs. And we're sitting there talking about success on the last M and A deal and it's like we didn't fire as many people as we thought we had. So it's like, no, that's, that's not a metric. There's things that can influence the strategy post close. But we took a hard line says strategy changes post close, materially changes. The deal is right out of the gate because the initial validation and reason that you went to the board to ask permission to spend a bunch of money is fundamentally changed. So this is a new deal basically, like we used to. Not that we had the power to do this. We would jokingly threaten like, you're going to have to go back to the board and get approval again. We already closed the deal. This is a new deal. You need to go get approval. What? But if you think about the way the process works, it is a new deal. It's effectively a new deal. It's a new project at a minimum. You know, I think success is, it's nuanced on a good day. There are principles that you have to run to as an integration team. Do you commit to running full integration or the definition of Fully integrated to a specific timeframe, nine to 12 months. Not over 12 months. Are you, as the integration team, as responsible for the sales team hitting the revenue numbers as the sales team Is this guy from Sandy Blythe, Great M and a integration guy who's been able to retire. He was very adamant about if the fuel model's red, we're red as an integration team. Doesn't matter, means we haven't done our job. Like, he was really dogmatic about that. And the rest of us were like, that's kind of harsh because there's so many things not under our control. He goes, yeah, but we're accountable. We're part of that team. You're either part of the team or you're not. I took a lot of learning out of that. I wasn't quite as black and white as he was. But again, if you sit there and go, we should be able to have a meeting with the sales exec, both acquired and the parent, say, here are the numbers. It's like an operational review, but it's more acquired, business focused and have that discussion like, why are we missing our numbers? There's a conflict in that. This territory between the two account managers or whatever, that's integration related. Okay. We need to figure out how do we solve for that. The easy answer is like, every sales will just triple comp everybody and then everybody's happy, it's okay. But that kind of destroys your cost model. Again, back to the P and L thing. Like when you have that discussion, okay, so you hit your top line number and you absolutely decrement everything in the cost line. You just destroy it. But the revenue is good. No business in the world should run like that. So we need to have a different discussion. And it wasn't the guy that wanted to report to Steve Ballmer, by the way. So I think there's principles that indicate success that you drive on every deal. There are constants and then there are the deal value drivers and the success metrics. If you achieve those, say you use 90% or better achievement against target metric as green. It's actually what I use a lot of. Cause it gives some flexibility versus it's a hundred percent or better. I haven't hit one of my race times in the last 10 years. It doesn't mean I'm a horrible runner. It just means I'm just very aggressive in my goal. That's how I measure success.

We got listeners that are new to integration. They're learning. Do you have examples of success metrics.

Principles, deal value drivers, the deal value drivers are usually. You could even put them in an Excel spreadsheet. They're rinse and repeat. On many deals, revenue is one employee attrition is one key employee versus employee base. Chef targets for that product milestone releases, the whole employee health kind of thing. Every company does it differently whether they do a survey and M and A. Do you do a survey pre close and then measure against 60, 90, 120, 180 days later. How's the employee health? Yeah, that's blocking and tackling in terms of what the value drivers are the deal success metrics are then revenue is an easy one. Did you hit your first quarter number? Your second quarter number? Kind of basic math. The important part of that is when you have success metrics I think there's an opportunity to create investor relations uses a slot MDA management discussion and analysis. It's sort of their place to round the rough corners that maybe didn't look so good. It's basically their opportunity to write their excuses. You don't call them excuse. It's more elegant. It's MD and A. It's where they can whine and whimper about wasn't able to invest in the headcount. We had a chance trouble hiring certain key roles or whatever it might be. So revenue is kind of easy. The MDA section though because most acquired businesses come out of the gate a little slow in terms of hitting their numbers. One, they usually don't have input into what those numbers are. And then when you show them the numbers they're like, you gotta be kidding me. Who came up with these numbers? And then back to the other comment. Keeson was like, well, it supports the valuation. Yeah, thank you for the valuation. But these are like real numbers. I love watching that conversation. I don't like being too close to it because it gets close to fist fights sometimes. But the MDA would be then like, okay, we're going to be slow in the first half and here's how we're going to make it up in the second half. So we hold for the year. That's a really mature response by an acquired exact. Especially on the sales side. It says, look, here's what happened. Everybody was sort of trying to figure things out for 30 or 60 days. They really weren't focused on the business. They just got acquired. They're trying to figure out what their benefits are and where the bathroom is and do they like the coffee at the parent and blah, blah, blah. Okay, now we got some traction. Now we understand how you guys work. We're Working better with the territory folks or the geo folks or the regional folks. Yeah. And here's how we're going to make it up in the second half. So we're all good. That's a really rational, reasonable discussion to have. It doesn't happen all the time because people get defensive and whine and whimper and do their thing.

Any other success metrics on that?

Attrition is really important. Doing deals in the pandemic, that's a very different discussion because everybody's moving everywhere, everybody's hiring everybody from everybody. But if you sort of remove that lens or that filter of the pandemic and what's going on in attrition right now? Key employees, usually it's no more than 5% of the employee population would be, at least in my opinion, working with really great HR people are the key employees. So if you got a you acquire a company of a hundred people, five of them are your real keys. And you might or might not be the CEO and the president, but cto, yes. No senior engineering or sales talent. What are you doing to retain those people and for how long do you retain them? So most of the retention packages or two or three years. So you want to look at retaining them short term, but then what are you going to do to re retain them when they hit that cliff and they're like I got everything, I'm gone, he's out. That happens a lot and that's hard. But the thing is it's not always about throwing money at them. It's about giving them the opportunity. What opportunity are you going to get working in our company? Here's what you're going to get that you can leverage going forward. I'm okay if you leave in five years. I'm not just going to throw money at you, but I'm going to give you some great work experience and opportunities that you didn't have in your prior company. So key employees retention. Honestly that should be 100%. Maybe you lose one person or one percentage point of the keys. But then the employee base in general you should be able to retain 80, 85 as long as that's what again the model dictates. Sometimes you want them to self trip. Sounds harsh, but sometimes you're just like we're okay if they acquired business, it trips down to this level by then the knowledge transfers happen. We're able to do things that we need to do. In some cases the way they did it. It helps again drive the top line number and the OPEX numbers. That's another example Product milestones is another one. And again, if you're a key engineer lead. So this is where it does create this matrix view. Let's say your CTO is a key and you've got two key developers, an architect and a developer. They're just absolutely core to the technology. And you've identified them early on and you've thrown a bunch of stock at them, you've thrown a bunch of money at them, higher on bonus if they leave. And one of the key deliverables is a certain product release, which then drives an uptick in revenue after the release. But if those 1, 2, 3 of those people leave, you're going to miss that product deliverable as well. So you have to look at how the math works. Those two events are inextricably tied. You can say it was an attrition issue, or you can say it's a product issue, but the answer is yes, it's both.

Yeah, no, that's a really good example. So we got revenues, attrition, key people, product roadmap milestones.

Those would be consistent across almost every deal. Unless it's just purely an acqui hire kind of deal where you're just throwing a bunch of money, bringing 10 people over.

What about integration principles, when you mentioned that?

So the integration principles are one trusted advisor, especially the integration lead has to be a trusted advisor on both sides of the equation, both targets. Otherwise you have too many inbounds, it can come in from too many directions. It kind of eviscerates the team. Right. Because you just got all these inbounds. My experience, maybe not a universal experience, when things go south on a deal, it's usually the integration lead that gets shot. It's like the CFO in many companies, when you miss the business results, just go back and look at the Wall Street Journal. Company X missed their number. CFO is left for personal reasons. The integration lead always gets blamed for everything. So the next one would be integrity. One of the key principles in integration is driving integrity. Like, again, because people are going to want to cut corners. They don't want to hear the truth. Back to that Jack Nicholson movie. You can't handle the truth. It takes a little time. But I tell my team, like, as long as you have your facts straight, timing is everything. But as long as you have your facts and the timing is right, you need to tell people what the facts are. And you can say truth, but truth can be better defined a bunch of different ways. My truth could be different than your truth kind of thing. So there's that. So that's why I said, stick to the facts. The facts are indisputable. Truth can be bunged, so to speak. So integrity is another big one. Trusted advisor. One of the other key principles is to stick to the plan. Except when it doesn't work. It's like, well, this is our plan. This is just what we got to do. I'm like, yeah, but what if it's leading you down a dark alley that doesn't work. I use the term intelligently flexible, and I've used it since I was at Sun. Actually, the guy that hired me into the cost accounting job was. That was his word. He goes, you need to be intelligently flexible. I'm like, it's cost accounting. There's X and a cost. Like, you just do the math. He goes, not always. There's over under spend. You know, all that procurement stuff that I forgot a long time ago. There's cost overhead. There's all kinds of manufacturing throughput. Maybe I remember more of this than I thought. Having that ability to be intelligently flexible is another key principle. You're not just blindly following the plan. Like, you listen. You pay attention in the meetings. You listen for when things are about to go sideways and try to anticipate how do I course correct in advance of that happening. Do I really need to spend this next quarter's contractor dollars on this? Everything else is slipping around. And why would I spend that? Because it's in the plan. Then your plan's wrong again. Back to finance. FP&A people do annual budgets, which are completely irrelevant the day after the start of the new fiscal year because they were developed three months before the fiscal year started. And then they do actuals to budget. And then you build a forecast based on the actuals, and then you analyze actuals to forecast to budget. And it's that same sort of mindset where you're looking at what do I spend and when do I spend it and is this the right time to spend it, or do I reforecast? That is for integration replan. Most costs should be directly related to a line item in the integration plan. So if the work changes, the dollars change, not about the dollars changing and work changes. Unless you're just told, stop spending, we're putting everything on pause. That's a different discussion. That's not an M and A thing. That's at the enterprise level. There's another challenge going on that needs to be addressed.

Wow. I like your principles. I like you having them so clearly defined.

Yeah, me too.

I mean, it Makes sense. Just like having a company, you got core values. Why not have integration principles? Because we're about to go through the largest magnitude of change management your organization's ever dealt with.

I say this tongue in cheek, but I don't really. I learned a long time ago I am never going to be the smartest person in the room. I don't want to be the smartest person in the room. That's a huge responsibility. I try to keep things really simple. I know from experience if you don't start out simple, you're screwed. Just black and white. If you don't start out simple because things self complicate. They just complicate. They have to. So if you start complicated, then I don't know what the tenth derivative of complication is, 12 spheres removed, or whatever the math would be. You'll never get there. You don't have to have a bunch of PhDs in the room then, and they don't exist. Keep it simple as long as possible. It is going to complicate by definition.

I definitely got to do my central close question, but I'm at this awkward point. I've only gotten halfway through the topics that we're supposed to cover. I honored to have the second half of this interview at some point.

I'd love to. I'm having fun. The thing is, it's easy to talk about things that you're passionate about. And maybe I'm a complete whack job, but I'm really passionate about M and A. It's who I am.

Somebody asked me the other day how come I don't do the panels and stuff. And I was like, you know, I hate panels because when you go to them at conferences, they're these short little monologues that are pretty well scripted. And then it is just a little series of monologue responses to questions. And they sound really can. But listening to you, I get this idea it'd be fun to have someone like you, a couple others, somebody like Todd, have a debate like, and really have a robust conversation that challenges some different views on things.

As long as Todd and I don't have to play one on one, I'm in.

I think we get a couple. You need three to four. But something debatable that would make it interesting. Even when we do our own events, we rarely do a panel. Rarely. And that's the thing. They're so boring. I'd rather spend an hour with you and get into this level of depth and get all these cool stories. Here's the principles we Learned from Jim Buckley.

1. I'm happy to do another second half of this one, and I think the panel idea would be great. I'm like you at the conferences and I've spoken at conferences and I just itch to have the dialogue. I just. I don't want to stand in front of a bunch of people and spew my truth to them. This is meaningless and sounds overly scripted and blah, blah, blah. Because I hate CAD responses. Because then it's kind of like the checklist thing, like following a checklist.

That's the second half of the interview. Yeah, we're going to talk about checklists. We didn't even get to the meat of what this interview is supposed to been. So that's a good plug. That's like the TikTok video, like to be videoed. If you want to see the rest of this interview, you're going to have to pick up the next one and listen to it.

We'll just riff right off of that, right into the second one. Let's do that.

I got to get to the last question before we sign off and close. What's the craziest thing you've seen in M and A?

This can only go. There's only so much I can tell about this one without probably crossing some either moral or ethical or I can.

Drop the livestream, maybe.

No, no. But we did a deal. I won't name the company. We did a deal in the Nordic. I'll just say the Nord. We did the employee announce. A bunch of us stood up from both companies and said, we're telling all you. We've sold ourselves to these guys and they're here to tell you what a great journey it's going to be and why it's such a great thing. I had my beard. I've only worn Levi's or denim and maybe a flannel shirt or shirt like this to work for a long time. So I wore a suit to this. I had a white starched collar shirt, very dark suit. I'm standing next to the CEO and we're talking to the employees and the HR person. My HR person was telling the employees some things about benefits. And without even looking, this guy leans over to me. He says, you know what? You look like a hitman. I listened. I kept looking at the employees while she was talking and delivering the benefit stuff. And I said, I am. You should be in fear for your career. And I was trying to make him laugh, but afterwards he was like, okay, so were you serious about that? Do I not have a job going forward. This was the CEO of not a big company, but it was a couple hundred employees and fifty million in revenue kind of thing. It was like, dude, I was just kidding. You started it. You said I look like a hitman. So it was pretty funny last time I wore the suit, actually.

That's pretty crazy.

Yeah. If we can't have fun doing what we do, then we shouldn't do it.

I like that principle.

Yeah, I love what I do. It took me a long time to get to it, but I guess never say never.

This has been a blast. Thank you so much. Thank you for the extra time.

Yeah, thanks for inviting me. Yeah, I'm going to be happy to. Whatever following you're up for, I'm up for it.

We'll follow up.

Awesome. Sounds good.

Thank you so much for your time today. And here's to the deal. Thank you for taking the time to explore the world of M and A with our podcast. Please subscribe for more content and conversations with industry leaders. If you like our podcast, please support us by leaving a five star review and sharing 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 Dealroom, a project management solution for mergers and acquisitions. Additional educational content is available on Deal Room's blog@dealroom.net blog. 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.