How to Manage Deals From Strategy to Closing in M&A Part 1

We recently launched a new book titled how to Stand up an M and A Function. Even if you're an experienced M and A practitioner, standing up an M and A function is a challenge of its own. That's why my colleague John Moretta and I compiled a series of templates, perspectives and Excerpts from over 50 interviews to help you build your M and A team from scratch. Topics include the order of hiring, establishing your operating model, developing your organization's integration muscle, and more. Find it on Amazon under How to Stand up an M and A Function link is in the show Notes 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 M and A deals.

Foreign.

We are live from New York out of VRC Valuation Research Corporation's office. They're sponsoring our space to host this podcast today. Welcome to M and A Science where we curate knowledge from the best in M and A to continuously improve. If you're interested in keeping up with the latest from M and A Science, subscribe to our free newsletter@mascience.com Every week we share highlights from our interviews, invitations to events, new M and A role openings and other resources as we build the greatest community of forward thinking M and A practitioners. Again, that's mascience.com I'm your host, Kisam Patel, CEO and Founder of M and A Science. Joining me today is Andy Vijaya, Senior Director, M and A at Kla. KLA Corporation is a capital equipment company that supplies process control and yield management systems for the semiconductor industry and other related nanoelectronics industries traded on NASDAQ under klac. Today we're going to talk about how to manage deals from strategy to closing an M and A. Andy, how are you doing today? Pretty good.

Thank you Kisan for having me.

Thanks for taking the time to chat. Can we kick things off with a little bit about your background?

I do have a different background. Somewhat unusual for a technical PhD to become an MNF professional. On the educational side, somewhat straightforward. I studied chemical engineering both for my Bachelor and PhD. There are a few, I would say minor twists. I did minor in finance at the time. The MIT Chemical Engineering Department require all PhD candidates to minor other than chemical engineers. A decade later it proven to be useful for my career and I also did some professional certificate on decision analysis and venture investment. So all I know is mostly technical educational backgrounds. On the education side, career wise, the boilerplate is from the Clean room to the boardroom. In the last decade or so from from billions of nanoscale manufacturing in the clean room, as you probably heard on the news, silicon fabrication and all the way to the billions of dollars decision making in the boardrooms. Now obviously in between those two milestones, I do have 10 plus years in the R and D technical product experience and also 10 plus years on the strategy and M and A. I somewhat managed to structure my career especially on the high tech to kind of see what I call the three major technology stack. One is the silicon. All electronic devices run on the silicon. Then the second stack is device level when you actually build a device, smartphone, laptop, server. And the third stack is basically the software the apps that you install on the device. So I have the opportunity to go through see different stack on the technologies. Right. Granted no one know everything. If someone tell you they know everything is naive. So you can only see a slice of a few things. So you get a bigger picture on the strategy and M and a last 10 years or so it cover a lot of grounds. From cumulative 40 plus billion portfolio management, hundreds of the deal pipeline, direct exposure to 40 plus deal, leading a team to 20 plus deals and across 14 different countries. Right. Global experience.

Yeah. Interesting background. I don't know Andy, if I should refer you to as a hybrid engineer, M and a person or just bipolar. I'm curious if there's any specific things that come from how you learn to think through problem solve in the engineering that you apply in M and A.

Engineer is very methodical, very structured. Also for someone that built a career through a specific industry, when you can see the breadth and the depth across certain industries, in my case the high tech, naturally you probably develop a certain capability. One of the things that I like to say is that your ability to zoom in and zoom out. What I meant by that is you will have the ability to balance a big picture thinker and then a detail oriented sort of multitasker. Being able to do the details and also on the high level conversations. In one meeting you probably work with HR going through compensation. In the next meeting you'll talk about high level indirect strategic value with management. So being able to zooming in and zooming out in any different conversation, you'll get that abilities over time. Given your experience, you probably built some capacity to handle very complex problems and be able to translate that to a simple framework influence or decisions. Your ability to filter the noise, you have seen the bigger picture, you have seen the details. So you should be able to filter some of the Noise what's important for decision making.

It sounds like two different parts. The zoom in, zoom out. And within that is creating these frameworks to filter the noise make better decisions.

One of the challenge in the M and a professional side. There are 1001 problem from the beginning of formulating a deal to the close and fully integrated. At any given time and any given day you probably have many different problems. You need to be able to quickly structure those challenges or problem, get it to conclusion very soon before the next problem come up. So you need to be able to listen to your stakeholder, synthesize their inputs and then structure the discussion and framings. What are the options and what is the uncertainty and get this stakeholder to converge to some sort of decisions. Otherwise you will never solve all these problems. Right. Because there's so many 1Z, 2Z that keep coming up throughout the deal processor.

Let's go through this a little bit because I'm interested. The zoom in, zoom out thing, I'm familiar with it. I'm personally not very good at it. I can do a click down and that's about it. I can't really zoom down to those granular levels of detail which it sounds like you in some ways are wired to do that teach me how would I be able to learn to do that properly?

Different people handle this differently. I've been in the much bigger corporation where there are many M and A deal leads. Each people handle quote unquote a dealer project differently. Some just want to manage up just handling at the high level. I don't like this term but someone like me like managing down and managing up basically manage your team and manage your stakeholder on the upper management. So if you're going to go through managing your team and on the detail, you should be able to hands on. For example, in some of the discussion you may actually have to open an Excel and do how do you distribute, for example retention bonus. It's tricky. Your HR partner will help you but some degree since you're the deal leads, you know where the boundary is where the employee on the other side. Your HR partner will probably need your inputs to drive the appropriate level of a retention bonus. For example. So you go down to the detail. You may actually work on the Excel and then be able to uplevel what you work on and then get the approval from the management side. Some like it top downs, right? You consult with the management. Here's the top down direction. Just work on it. Sometimes you also have to work on bottom ups based on what you know how do you want to structure some of these challenges right down to the working on the excel, those kind of stuff. So it depends on the naturally how you work. Do you only want to on the high level managing up or do you want to go through the detail, have some influence from the bottom up?

What are other examples of zooming in? Because sometimes I hear about people that go personally have conversations with customers and things of that sort. What are good, good examples of these areas that you do zoom into that do create an immense amount of value?

Let's say you have a deal. One of the big deal thesis is product integrations. Maybe make it easier the software so you go through due diligence. You have your technical partner to look at for example the quality of the codes. Do they have any open source code that is not. They don't have the license. So you go through the detail making sure you guide your technical folks, understand what are the risks on some of this product and also help your technical partner to frame what would they want to do with this product? If the deal thesis is hinged on the product strategy, you kind of have to frame and drive the discussion. What is it that you want to do? It could be you bundled the product with existing product. It could be a tier product, brown, silver, gold offering. It could be completely substitute or cannibalized existing or their product. So those kind of detailed discussion, framing it and driving it with your technical partner is another example how you zoom in rather than on the deal, just worry about transaction. You also have to zoom in on the deal thesis, making sure that a good alignment between the deal thesis and the transactions.

All right, now I'm going to mess with you. So we have a timeline of the deal. Now I'll use this scenario as an example because I want to get a sense of pre loi to the level that I would zoom into. And then how does that progress post loi? When we get into confirmatory diligence and using this as an example where a lot of this is around shaping the go to market and what that's going to look like with the product. What's the details and conversations early, then.

How does it progress pre loi? Let's keep on the discussion the product side. You should be able to zoom in up to the level such as product demo. You can see the product in person if it is hardware. During the pandemic. I think the demo of software can be done via zoom. So you have your technical person, you can see the demo. Is this something that we're interested in? Or this is totally different than incompatible with our core offering. Obviously post LOI you could see the spaghetti detail of the code of the software. You can see more due diligence, how is the code is being written, things like that and see how compatible to our offerings. And then you start working on Wait. If you're going to combine this product, the GUI or the interface itself is completely different than us, then how are you going to handle it on the background while you're doing a transaction, you're also driving a discussion. There will be some technical work need to be done here to at least adjust certain things. And naturally you also start thinking therefore wait, there has to be some integration at least if they're going to work together. At least they should be able to access the SharePoint, those kind of stuff. Hence the discussion on the ITS. So you have all these zooming in discussion even though you run transactions.

Is that mainly around identifying capital expenditures and then trying to maybe dial in your synergies or synergy estimates to some.

Degree that more importantly is to validate your preliminary deal thesis and integration strategies. So obviously when you pitch the idea, my personal preference to have preliminary integration plan. So that based on the deal thesis, here's what we think the integration plan is. You have to validate that both the deal thesis and the plan throughout the due diligence, you're also driving the transaction with the other side.

Can you give me examples? How does that pan out? I like where you're thinking about it. The big common fallacy here about M and A is planning the integration late. It sounds like you're validating these things really early, clicking down and getting a sense of how it's going to come together. But then when you move into signing LOI and confirmatory diligence, how does that unfold with getting all those details for having us the right integration plan? And some people think there's a magic template for this stuff which I like how you started with. You can get some structure based on the strategy of integration to start with. But yeah, I'm curious of the details and how things shape from there.

Like you mentioned, time's also the essence on the transactions. I would say when you go through kick off the diligence process, this is assuming you already involved the integration leads you want to frame. What are the most important part in terms of driving the due diligence. This diligence margins process can go all over the places. So as a deal leads, you have to frame it and focus the team on the few items that are relevant to the deal thesis. Could be a product strategy, could be other synergies. Right. If you look at the P and L is pretty much the top of the line, bottom of the line or financial or tax synergies. Obviously top of the line is the product strategy. Bottom of the line could be processing those kind of stuffs. You have to help them focus in term of what important on the deal. This is on top of the typical sort of back end office diligence going into integrations. Given majority of your eminent team most likely is not a full timer. So you have to help them focus in term of where do you want the diligence going for an exit at 30 to 60 days?

I'm wondering are these the same people you're having conversations with on diligence about integrating it? Does that happen at the same time? Are they completely different people? Does it get staged later in the deal? I was trying to get into that piece how you're doing both at the same time. The diligence and integration planning.

This is very company to company, even organization. Even with the large corporation with multiple views and multiple business units. My personal preference, I would like to have most if not all the diligence team become the integration team. But in reality that's not always the case because resources within the corporations at least you have majority of the diligence team become the integration teams. So they will own what they discover and how they will translate that to the integrations.

Could you also phrase that as the integration team owning diligence?

Correct.

Okay. I just want to make sure because I feel like I have more conversations with the integration side that advocates to be involved earlier. In fact do the diligence.

My personal preference that way. But in the bigger large corporation I would say sometimes it's not possible because the fungible of resources, sometimes they get pulled to a different deal or different projects.

Why is it better?

One thing is avoid the disconnects. When the diligence team just owned the diligence and then hand it over to a different integration lead. There is always a disconnect in terms of what they learn, what they discover, things like that. Plus, if you did the diligence and you did the integration, you kind of have that ownership. I did assess that risk as a medium to low risk. I need to figure out how do I mitigate this risk during the integrations. So if there is a disconnect with if there are two people between diligence and integrations, the risk assessment and the mitigation execution could be off.

What's the negative consequences of that I.

Would say it will take longer efficiencies, not just efficiency. It could also hinder some of the dilt synergies. As simple as what I just mentioned to you regarding the product strategies, right? If the IT is not aware of the expectation on integration, if people don't have the appropriate working laptop and stuff, it may hinder how quickly can you integrate a product? For example, if there is a disconnect between what we learn in diligence, what we plan and then a completely new different guy executing the integrations, it could delay some of the execution hence affecting the deal the system.

So slower value capture on one end and then potentially missing out synergies completely.

Correct.

I'm curious because I have these conversations and I'm one is trying to vap. Everybody blames integration for deal failure, right? And there's good points on that. But within the whole process and you think of value leak, I feel like this is probably one of the biggest value leaks that you could have. I don't know if that's the case or if you think there's something bigger.

It's funny you mentioned that because I'm the delit. I did some integration in the past so I can see the importance of the integration. So I'm well aware of that. That's what I would say make my executions a bit different. Some people on the front end always argue the transact is the biggest value. Some people on integration may argue integration is the biggest value because that's where the value creation post deals. In my opinion all is critical. But I know that integration is hard from my experience in the past. Therefore I'm well aware of that. Trying to make sure that my integration team is aligned as early as possible.

This knowledge chasm stuff, any big things you've learned to overcome that besides having the same people involved for both.

I don't know how applicable to other industries because we are in the high tech where technical know how somewhat more important. So identifying the integration lead may be slightly more difficult than other industries. Right? Some big corporation you may have a very robust imo. Their job is basically project management. In the tech world you need to figure out do I need someone that actually know about the product, the technical detail about the software or the hardware? Do I want to put two people in the box? What the PM and the technical pm do I want the technical PM become the integration leads. Identifying the appropriate technical lead is critical in the success of the post deal recreation.

We're touching on some good stuff here. These aren't the easiest things to overcome. But I do like these examples of getting to these specific details that really trail around how you're prioritizing the value drivers of the deal. That sort of gives you guidance on where you should emphasize your attention and make sure you're getting into those details in the area that's potentially be the biggest risk or biggest things to screw up down the road. We talked about the frameworks and my takeaway there was there's a lot of problems to solve and decisions to make and that establishing a framework so you can do both quickly. It's probably one of the engineering critical areas to focus on in M and A. Can you walk me through what those.

Frameworks look like, my personal framework in terms of driving a problem to some sort of conclusions? Generally I would say listen, synthesize. I would say formulate and then converge. What I meant by that is you listen to what your stakeholder just learned either during the target engagement or due diligence. You need to synthesize. Help them synthesize. What does it mean? Then you have to help them frame. Given all these situation you just discover what do you have in mind in terms of option to handle this. Keep in mind your colleague is the expert in the given field or they probably already have some sort of initial thought how to handle this. So you help them to formulate the option how to handle this and understand the also assess the uncertainties. Then you're going to have to converge them and the management in terms of how we should make a decision around this. Yeah, listen, synthesize framing and converging.

When you say what's on your mind that one refers to framing.

Oftentimes you listen to what they discovered, help them shape what is their initial thought. Frame them in them in terms of what option do we have to handle these situations. Usually given their expertise, they already have some initial thoughts. You kind of have to help them guide hey what exactly the options are and with the uncertainty with the given options and then converge any given problem with a few options to choose. We actually have to converge in terms of what is the recommendation, what do we want the management to approve?

Is there anything around feedback or sometimes you got to course correct or redact and try something different. Does that step in there? How do you get that feedback loop?

So this is where the I would say a combination of bottom up and top downs. My personal preference is to have somewhat consistent dialogue with the upper management. Obviously from the bottom up you'll probably have one on one meeting with some of your Colleagues, you have smaller discussion for specific issues that actually involve multiple stakeholders. And you have a team meetings where you making sure it map. Hey, we discovered this. This will impact ABCDE one on one smaller group team meeting. And then you have a consistent discussion with the management side. Either a milestone or decision making meetings. Hoping to get the feedback for a top down guidance is constantly a loop throughout the deal formation and the deal execution. Those kind of stages in the M and A and I'm sure in integration is the same thing too.

Is there any language or approach you use to make sure you're getting that information? Do you encourage it? How do you get the feedback?

Based on my experience, given the large corporation, you have multiple business units, multiple general managers. First you need to understand the style of each different upper management. And my BKM is that you need to make sure that you're going into the meeting is clear what you want to get out of it. Minimum number of slides. Basically here's the situation, here's the option that we are considering. What do you guys have in mind? What do you guys think we should do? Therefore it's clear going in and out, we will get some input. Either decision or input or an action item. There are different approach to this. Some people like an open discussion and dialogue. So the discussion could be all over the place. You will give times for people to discuss an open dialogue. But you actually have to own the meeting and frame it so that you reach some sort of a conclusion or some sort of feedback. So having the right framing going into the meeting and know what you want out of the meeting. I think it's important to get the feedback. Majority of these upper management are exact. So they have, I don't know, 10 to 15 meetings any given day.

Yeah.

And M and A could be just one of them. So you need to frame it. Hey, we spoke with you last time. Here's what we learned. Here's the option. What do you think?

Recap everything, have good documentation. The listen, synthesize, framing, converge. Is that something you're very formal and transparent about and you address that broadly as you work through a deal or is that more of a culture thing and way of doing it?

I would say it's more like a culture thing for myself to be more disciplined in the driving the meetings. It's not a formalized, hey, you have to spend seven minutes on this at the minute and that in the back of your mind you always have to think that way to structure it so that it'll become a meaningful meeting rather than just an Open where everyone branching to multiple places. You have to have them focus. Hey, let's get back to where we are here. Now we have a situation. We think here's the option. Maybe there are other more options. We can discuss it but towards the end where do we leaning to? Or do we need more information before we can make any decisions? There are many decisions before the deal can converge. If you don't, what happen is that any problem will overlap, another problem will overlap another problem. You will never get to the end goal of it. You just have to be efficient in terms of solving problems problem one at a time or consecutively.

When I think of your M and A function, I think of like broadly this growing M and A team as you do the deal that you should communicate some way of the approach as a broader team of how we're going to approach like the framework you described. So I feel like it should be taught. It's one thing to have it cultural, but organization to organization they don't think about it that way. They don't put an emphasis and consciously think how do we optimize for the speed of problem solving decision making. That's where it's interesting where your review you've done it and have the DNA around it. I'm just curious if a good practice wouldn't be to teach it and say hey here's your little boot camp and participate in this M and A deal. We'll give you a high level of how we think about it. Or is that just broader DNA of the company that they're already doing it.

Culturally that way in the large corporation, even within different business unit I would call there is subculture. One approach to certain division or business unit may be not applicable to another business unit bigger corporation tend to have established is MNA team established imo. They may have a good established processes, but at the same time you have to be flexible. When you're partnering with different business unit or different general manager or different stakeholders, you actually have to be adjusting as well. The only thing that you could be disciplined on your own is the framework of your own in terms of driving solutions. Some people don't like processes, they don't like to be told processes. Some people like processes. I would say as an M and A lead, you will have to have that framework regardless whether it was stated or not stated. You have to drive them in order to solve it.

That's a really good view on it. You have to deal with a lot of different personalities and you can't expect them to change dramatically.

Exactly the goal is not everyone to follow your process. The goal is how do we get it done by solving all these challenges between deal formulation to the closings. You respect what the process is.

They want to work well together with them. Is there a balancing act between doing that, working with this business unit internally and then with the target company that you're heavily involved with or are you sort of more shepherding conversations between the two?

It's definitely a balancing act. In essence, you have the acquiring business unit trying to make a decision by learning as much as possible. And the other hand is trying to get the transaction as robust as possible. I think you have the balancing act. How do you drive the transaction and how do you learn as much as possible that you make the right decisions? Now, in any learning during the target engagement, pre ROI and the diligence toward closings, you could put it under three buckets. There are things that you could learn as much as possible and then the problem solved by itself after knowing all this information. That's bucket number one. I won't call it easy. It's more like once you learn technically, you don't make decisions. Problem solve itself. Ah, it become clear that we need to do the following. Yeah, but more often than not there is no perfect or complete solution. Then you just have to understand what the risk is and then have a mitigation plan before or post close. And of course there's the third bucket. That could be what I call the showstoppers. There's nothing you can do about it as you're driving that balancing act. You're trying to assess all this on the business side and you also have to work with the other side to accommodate some of these learnings. We can work through the transactions.

Oh, so the third one, you still get the deal done.

Exactly.

It's going to take a lot more effort than anything else.

Yep.

Okay. That's a good sense of sizing these issues and knowing how to respond accordingly. When you're going through this deal and it sounds like this balancing act of how when the debt that you participate on, how does that shape on the expectation of who has ownership of the decisions to make and problems to solve? Do you have to communicate that or is that people just know like when does it some of these things really become not your problem and it's on the business.

So in terms of ownership, generally it's good to have a clear ownership to drive accountability in a way that it make it clear. For example, in the diligence kickoff, who are the owner of a given function it's clear the expectation. And then whenever there is inter functional problem, you have to identify who should make the call. Making it clear on the ownership, it does help in terms of driving the problem to be quickly solved. What you don't want is basically there is a problem that require multiple function. It's not clear who's supposed to drive that. From my experience, my personal preference is not to put multiple people under one box or having one person to report to multiple people. It creates a conflict of interest, not incentivizing them to the right direction. But that's just my personal preference.

So just having a single responsible owner or person to report to and avoiding.

A duplicate, even if it is multiple functional need to handle certain challenges. It's clear, hey, you kind of lead this way, the other functional group help you with that. Because what happened is that if you have multiple equal lead under the same box or owning the same thing, it could create attention, lack of ownership, this kind of stuff.

So thinking back on that broad approach of encouraging the team and their approach on decision making and problem solving, how do you know when there's just too many cooks in the kitchen? I don't know if that's a consideration that all right, we have 12 people weighing in on this decision. Is that something you think about or would just generally limit even outside M.

And as a project can have 20 to even 50 team members. It's not unheard of. You could have too many cooks in the kitchens. That's why I think you will have this level of meeting the one on one smaller group meeting and the team meetings. Any challenge or problem as the deal lead, you need to be able to drive that in the smaller meetings to have them converge. If you keep trying to address some of the problem in the larger meetings, sometimes it will never converge because of there are too many cooks in the kitchens. You can address that by a smaller meeting and even down to the one on one meetings to make sure it's clear. Here's the framing, how to solve it. And you're the owner on the driving.

So in some ways you have to be proactive to limit the cooks in the kitchen. You sort of take this decision, isolate it a bit.

You've probably heard this many times in the M and A. So even though in the bigger corporation with well established team, from my experience that majority of your resources is A not a full time M and A. And then it's your job to drive this, align them, have them drive to conclusion. Because M and A activity may not be their top priority. They have other jobs, so you have to drive them. You have to set them aside in smaller group discussions. It become clear in terms of ownership that way.

That makes sense. So you do have to do that. Andy, we haven't even touched our interview outline. If you get the chance, let's find some time and actually pick up the interview that we're supposed to have. Andy, thank you so much for the time and conversation today. I learned a lot. You've helped me become a better M and A scientist. Those of you still with us, thank you and here's to the deal.

Thank you for taking the time to explore the world of M and A with our podcast. We love hearing feedback. Tag us on a LinkedIn post, add a review on Apple Podcasts. We'd love to hear from you. If you need help standing up an M and A function or optimizing one that you already have, we're here to help. And if we can't help you, we probably know someone that can. You can reach out to me by email Kisan K I S o n a science.com or you can text me directly at 312-857-3711. If you just want to keep learning at your own pace, visit mascience.com for a lot more content and resources. That's where you can also subscribe to our newsletter. Again, that's mascience.com here's to the deal. Views and opinions expressed on 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.