The Basics of M&A Integration Execution

This is a conversation with Aaron Whiting, Chief of Staff at Crown Peak. He has extensive MA integration experience. In this interview, he explains the basics of M and A integration execution, basically how to train a first time M& A integration lead. We covered how to assemble M and A integration team, the role of the integration leader, setting the cadence of meetings, common challenges during M and A integration, and advice for first time practitioners. This episode is sponsored by our very own business lines, the M and A Science Academy Elevate your team's M and A skills by signing up for the M and A Science Academy. We curate the best of the best M and A practitioners to give you the education you'll need for your next deal. Dive into lively courses that turn complex M and A concepts into engaging, understandable lessons. Visit Mac science.com academy to learn more. Deal Room the best gift you can give yourself this season is a streamlined M and A process. Say goodbye to the hassle of those pesky Excel trackers and hello to the efficiency with Deal Room. The ultimate platform for M and A success. Make this holiday season the best one yet with Deal Room. See why the best Emerson Energizer, Cardinal Health, Neiman Marcus Use deal room. Visit dealroom.net to learn more. Again, that's dealroom.net firm room in the world of M and A, data, security and compliance isn't optional. The best in M and A Choose firm room for three simple reasons. 1. Top tier security while being dead simple to use. 2. No per page billing BS. We all know it's a scam. Don't fall for it even if the bankers try to trick you otherwise. 3. You can sign up in less than two minutes for the free trial and see for yourself why it's better than anything else out there. Get started with a free trial@firmroom.com Again, that's firmroom.com I'm Kisan Patel and you're listening to M and A Science, where we talk with deal professionals and learn valuable lessons from their experience. This podcast focuses on stories, strategies and what actually happened during M and A deals. 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 the latest from M and A Science, subscribe to our free newsletter at mascience. Every week we share highlights from interviews, invitations to events, 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 Kisan Patel CEO and founder of M and A Science Joining me today is Aaron Whiting, Chief of staff at Crown Peak. He's an operating executive of a private equity portfolio company. Today we're going to talk about how to train somebody to lead M and A integration that is brand new. Doing it for the first time. Aaron, how you doing?

I am good. Thanks for having me.

Hey, thanks for taking the time. We're doing something a little different on this interview. We're not going to do this hardcore typical format that we do. We're going to role play this out as if I'm like an intern. We'll go as far as say a dumb intern. You're out of resources and essentially I'm the only person that you have to go really brief on how to lead integration for an upcoming integration project. And that way we're going to try to get this conversation to be as practical as possible and try something different since a lot of the stuff that we both agree is tends to be too theoretical when it comes to M and A training. With that, can we kick things off with a little bit about your background?

My background is private equity software. I tend to move around every 18 months or so. I get pulled into everything from strategic programs to actually doing deals. My primary focus really is post close integration work. Anybody who's done post close integration work knows that comes with a lot of chief of staff work. It also comes with some of that strategic programs work because if you don't have something to integrate into sometimes you're the one who has to build it before you can integrate into it. So that's really My background is private equity software. I tend to hang out in the same size range somewhere in the 20 million ARR, all the way up to maybe 500 million ARR. Above that it gets to be a little bit too slow and cumbersome for me and below that ends up more VC and more startup and I haven't enjoyed my time there quite as much.

I appreciate it. So you got a pretty versatile background when it comes to integration. Been hands on with this stuff and worked around integration from different facets of it. We're going to do something different. We're going to role play, briefing, coaching someone to be an integration lead on the spot. Maybe if you want to set up a little scenario and we can just jump into it.

Probably easier for me than it is for you because in the work this happens, you end up in a company, especially smaller ones and whatever lead you get, that's who you have. Keep in mind the space that I play in is not some of the bigger player spaces. It's not the sales forces or the Ciscos where there's dedicated teams. You're basically collecting who you have. Somebody shows up as a first timer and you start walking through. So usually the first question I get after the intro. Hi, Keyson the intern. Nice to meet you. Is what are we doing next? That's a great first question for you to give me now and we'll get into it.

What are we doing next?

First thing we have to do is figure out where we are in the deal cycle. The only reason that I would be here is because there's something coming. You and I need to get our arms around what's coming and when. And the when for an acquisition is more important than a lot of other programs and projects that you're going to run. What we need to do, we're going to go find whoever's running the deal. There's typically when businesses of this size, where we're playing, there's going to be a deal team and there's going to be an integration team. You can see it where that is, one team. But let's assume for now that if you and I aren't closing this deal, somebody else is closing the deal. Have you had any depth or background on understanding kind of the cycle of a deal and where integration would typically get pulled in?

No.

Buying a company, we're going to talk in a lot of oversimplified terms just because we have 30 minutes to get our feet under us. Buying a company is a lot like a sales process, but backwards. There's a big pipeline phase that you and I care nothing about. It's sometimes interesting. We can look at the pipeline really, just to understand the strategy, but that's not where we wake up. You and I will be doing probably a lot of work on the last project until we hear those three magic letters, which is loi and an LOI is really where we start paying attention. LOI is it's a letter of intent. And that basically is a communication to a target company that says, hey, we're interested. There's a bunch that goes into that. It's lawyers, it's deal teams. We want to have input into that loi for sure. Because one of the things we can do as an integration team is we can start mapping our requirements and our needs into that loi. We'll talk about that a little bit more. We could do a whole hour just talking about how we think about the loi, but just know that for our purposes, the LOI is when we start paying attention. I'm not going to teach you, you know, an entire deal process. So just again, we're going to hit it in simplified terms. So we'll go from loi diligence. You and I are definitely going to play in that space. Diligence is where we get in and we start not investigating, but we really start doing discovery on the company, trying to understand it. And this is one of the earliest, the most critical spots for the integration team to get pulled in. And I'll also tell you it's one of the places where the integration team doesn't get pulled in and it's a miss. What diligence can feel like is you'll have a big legal track, a lot of lawyers digging around through documentation and all the things that would really drive some, like liability concerns. And that's important. You'll also have finance teams heavy on finance, finance teams understanding things like budgets, things like performance. Of course you want to make sure that you're buying a company that's accretive to your goals as a acquiring company. Let's not spend too much time there because again, you could spend an entire day talking about legal and financial diligence. What we'll talk about is functional diligence, just how that goes. Again, it can go in a lot of different ways. One way that it can go is by sending over a drl. DRL is just a data request list. This is your top 10 top 50 top hundred questions that you need answered. Those questions are going to feed into our integration plan. So we want to, if not write that drl, we want to heavily influence that drl. Every question we put in that DRL is going to save somebody a question downstream. So anything we can collect, we want to start now. That DRL will eventually feed functional diligence meetings. So think about meeting with kind of a go to market team where once you have these questions answered in the drl, you'll sit down with a go to market team and you'll just ask them questions about what you saw, what's the approach? And that's where you and I start really formulating our plan going forward as it ties back to the thesis around acquiring that company. Any questions? Anything sound weird so far?

I think I get the gist of it. We want to find out where we are in the deal process. LOI is the main activity we're looking for to really get in gear. And then we're basically focusing on the operational parts of diligence I want to put together a list of requests for information that our team's going to need down the road.

Yes. So that's a kind of a superficial level. That's it. We're trying to understand the company. We're trying to think ahead and ask the questions now so we can save those questions from being asked later. Also, if we know the answer to those questions, we can put together a better plan. And we already have momentum. I mentioned something about a thesis. A thesis is tricky because a thesis is something. A thesis is just the idea of why are we acquiring this company? There could be a bunch of different reasons around why you would acquire a company to enter a new market, maybe just to boost ebitda. Bunch of different reasons. What can be surprising to somebody who hasn't been in the industry for a while is that thesis is sometimes razor thin. There's an idea around acquiring a company without a real well thought out plan about why. What are we trying to accomplish when we purchase this company? I can tell you that it's a lot harder to integrate a company successfully if you don't know why you've acquired it in the first place. If the focus is all around product and you don't know that and you're really focusing on go to market, you're going to miss the point entirely. So part of our job through this process is to make sure that you and I have a crystal clear understanding of what that thesis is, even if nobody else does or if nobody else has really put pen to paper around what we're trying to accomplish. That's going to flow into things like budget. It's going to flow into things like forecasting and planning as well as some of the more tactical integration planning that we're going to do. So we go loi, we go diligence. In the meantime, if you think about parallel tracks, there's a whole deal team and a stack of lawyers that are working on closing this deal. So if you've ever gotten a mortgage on a house feels like that, there's usually an SPA or an APA that determines what parts of the company you buy, so to speak. And that's runs in parallel with us. So once we get through diligence, the biggest part of our year is going to be planning a day one. You want to think about a handoff. Day one is where the deal team, more or less, and again we're oversimplifying, goes away. It becomes less about the deal team because they've closed and it becomes more about bringing that company into our company.

I think I get it.

You want to talk about day one?

Yeah. Let's talk about what day one is.

So day one is not actually day one. Depending on the size of the company you're in, it can happen in a couple of different ways. Larger companies, you'll see proactive announcements like big deals, especially public space. You'll know that a deal is happening for months in advance in the space where we play. It's typically a surprise. There will be a very small, tight, kind of secretive deal team. You, you and I are in it. The executive level from both companies will know about it, but it doesn't trickle down much further than that. That's important because if things get out, it can actually sour a deal. It can impact customers, it can impact financials with a thesis for doing the deal in the first place. Day one is when, again, oversimplified. You can do this a bunch of different ways. Day one is when we will announce the acquisition to both the market and our employees. This is one way to think about it. Day one. So the deal is already done, transactions closed. The lawyers and the deal team have typically had their party. We think about M and A in two halves, the party and the hangover. You and I get to be the hangover while the deal team and the lawyers are high fiving and celebrating. We're executing this day one and it's going to feel a lot like wedding planning or just a throwing a big party or an event. There's a lot of ensuring that we know where people are and that they're being communicated to. There may be paperwork involved if we're updating employment agreements. But everything on day one, when done right, is scheduled down to the minute. And when I say down to the minute, some people will hear that and say, yeah, down to the minute. But I assure you, we will have it down to the minute. Because the people who are involved, the employees and the shareholders and the customers, deserve down to the minute planning in one of these transactions. Without that level of planning, day one can be and will be a disaster. One way or another, you're affecting people's lives. Day one can consist of layoffs, rifts, or not. Either way, it's a significant change in somebody's life to find out that the company you're with is now undergoing this soon to be transformation. You want to ensure that those employees are receiving the level of execution that makes them feel safe, makes them feel like at least somebody has a plan and it's been well communicated and they're being shepherded through this event with a level of organization that they haven't seen probably anywhere else in their career. So we can pause on day one again. We can come back and we'll end up doing hours and days on talking through day one. But is there any high level questions around day one and kind of what that looks like, what it feels like? Do you want to do a little bit more detail on it?

How come we don't get to go.

To the party because we're too busy working? It's kind of the joke, right, is that the deal team gets to be done. It discounts the fact that they've been working 80 hour weeks for the last could be months, could be 18 months on a bigger deal. So we get to give them some lip about it. But really they've been doing their work already.

Day one is important. We're doing a lot of the coordination and communication with the customers, employees and vendors and it's really important to get that right, to set the tone.

Yep. And again, you can do any of these things superficially and you can make an announcement. A Keysan co acquires Whiting Co. But that's not the point. And again, if we come back to the thesis, we try to think what are we trying to accomplish? So another way you can do it is you treat an acquisition just like any other launch, like a product launch. You're trying to bring value somewhere, either to the acquired customers or to the acquiring customers. With the acquiring company somewhere, you're creating value for somebody else. An acquisition doesn't necessarily create value for the people who you want to talk to. So the idea is to bring it through an entire launch process. So rather than sending out an email, company one acquires company two. You're really talking about the why. The acquisition just becomes secondary to the whole product launch. And that's going to flow into our plan. So if we start thinking in terms of not necessarily an acquisition but a launch of a new capability or a launch of a new benefit or a launch of new value that we're creating for somebody that's going to teach our integration plan how to think that's going to flow into things like sales enablement around cross sell or whatever we're doing with this company. Day one is it's got a bunch of stakeholders, employees being arguably the biggest customers tied for first and then stakeholders second behind.

It gives me a gist of it.

You haven't asked me how long does it take to build out a schedule for day one to include all of the communications all of the paperwork, all of the employee onboarding and that kind of touch point internal and external communications. How long do you think it would take to get all that done? If we're going down to the minute.

A month or two?

Yeah. So three weeks I feel pretty good about three weeks. And it doesn't scale exponentially. It's the same process for a 20 person company as it is for a 500 person company. There's more documents that have to fly around, but three weeks I feel pretty good about. I share that to let you know that if we start poking around and we find out that we are less than three weeks out from the close of an acquisition that's coming at us, we're going to have to go fast and we're going to have to work a bunch of late nights to make sure that all this is built and coordinated and that the change management kind of prep inside the company has already occurred. The next question you should be asking me is, hey, that sounds great, but I've never done this before. How do we do this just the two of us? And that's not the case. One of the things that we'll talk about either I'm going to teach you as we go, or you're going to learn as we go or you'll get a certification is scale to agile is your friend. One of the things we're going to do is we're going to identify teams or squads units and we're going to build those scrum teams around objectives. So we're not going to think in terms of marketing, we're going to think in terms of go to market results or objectives. We're not going to think in terms of support, we're going to think in terms of handling our customers, whether it's from software implementation and support. Again, keep in mind my background is all software and we're standing in a software company so that's the lens that we're looking at this with. But you can break this down into people and revenue, generating revenue, keeping customers happy. And then just general operations tends to be the same buckets. There's some harder ones and some easier ones. I think software is a little bit easier, but that's what we're going to do. We're going to apply scaled Agile to this and we're going to start looking for teams, people who can handle those functions and those objectives. So when do we start? Every project needs a kickoff, but keep in mind we've been operating in complete secrecy from everybody for the last maybe 90 days. How do we get that team ready again? There's a bunch of ways to do this. Whatever works is the answer. I've done a couple different ways and you and I will figure out how we want to do it with a plan. Because we're already putting a plan together during diligence, we're going to start trickling that plan out to people as we need them. So for example, one of the first things I try to do, my integration plan, because it makes our lives easier, is I try to get the acquired company onto share our shared email systems on day one. So as people are finding out that this even happened, they're also receiving an invite to be on our email systems. That's not going to work everywhere, but it's going to work for us. To make that happen, you and I will bring in our corporate IT function a little bit earlier. We'll start warming them up and getting them prepared. We're then going to look through our integration plan and we're going to see, okay, what else is going to come next. It's going to be marketing, it's going to be communications. Whoever's going to handle our launch activities around day one, they're going to have to be in with us pretty early as well. HR or pnc, however we think about it, the people handling the employees and the documentation, if we're handing out new agreements, they're going to have to be in early with us. And in fact, they're going to be in with us almost since LOI because they have a lot of work to do to get prepared. So we'll start trickling these people, these leaders from around the company. We're going to start finding them as we go. We're going to start building the team. As the team gets bigger, we're going to separate them into little sub teams. We're just going to launch scaled Agile. So rather than going big bang with a kickoff and kind of a, okay, we start tomorrow, we're going to make this more of a gradual process. It's going to feel like a process, not an event. What else aren't we talking about that we should be talking about?

I think we're getting into the process, the kickoff. We got to identify the team. Is there any more specifics about who do we need to pull in and then how do we address them and kickoff?

Yep. So who do we need to pull in is a really interesting question. And again, it's going to be dependent on the environment that we're playing in. There may be an IMO team In bigger companies, if you ever extend your career and you move on to some of the larger companies, they may have a dedicated imo. And at that point you'll be in your role leading the imo. Some of your IMO consultants or however you want to think about that may already be in diligence. For us because we're in a smaller environment, it's going to be a little bit different. You and I are basically going to pass a hat for good people. And what we're going to do is we're going to approach. The executive team already knows this is coming. So we're going to go around the horn and we're going to ask the executive team, hey, we've got these goals for integrating these two companies. Who would you recommend that we pull in? They have to be not senior, but they have to be at least an up and comer or a top performer. You and I can teach them everything they need to know about integrating a company. But we need them to be a professional. We need them to either know their field, their area really well, or we need them to be a sponge. We need them to learn really fast. The other thing that we're looking for, because you can do this with first time professionals as well, we need them to be unbelievably cross functionally oriented. That is a rarity in most companies. Companies love to operate in silos, integrators, and anybody who gets to hang out with an integrator doesn't get to be a silo. So we're going to find those people who are best at being cross functional. You find them in weird places. You find them in parts of the company where you wouldn't expect to find them. They might be the person that just knows everybody. They're kind of the central points of either culture or like knowledge holders because they know everybody. So those tend to be good integrators because they know how to get stuff done. So that's how we're going to build the teams. We're just going to start asking for execs. There's always a tension too. Just so you know, when we're knocking on these doors, it feels like extra work. So there's a tension of like, hey, we're really excited to acquire this company, but then here comes the hangover crew and we're asking for a resource to help integrate this company. It's never going to go away. You can be smarter about it or you can be less smart about it. What you and I are going to do as we craft this plan is we're going to try to make this integration disappear into the company. So it's going to feel less again like an event. It's going to feel less administratively heavy. It's going to feel, if you think about the launch mentality, the company is already launching products. We just need them to do that again with some information that we give them about this new acquisition. So we're going to rinse and repeat that. The messaging we're going to give to it is, this is nothing special. You onboard new employees every day. We just have 500 at a time that you have to do. It takes a little bit more prep. So that's really the focus. It's not that integration is some brand new process. It's just bringing in, it's implementing a new product into the processes that already exist. So that's how you would go about formulating the team. I'll give you two bits on a kickoff. So if we do a trickle in, there's not one big kickoff. But what I do have at hand, if I'm doing kind of a trickle in building of a team, is I have all my materials, my basic introduction to the company, the thesis, here's what we're trying to do, here's how many people, and I'll record it and I stash it someplace safe and secure. And as somebody comes in, I have them sign an NDA and I have them watch the materials. So now they're all caught up on at least the basics. Not going to have all the nitty gritty detail, but they have exactly what they need to know and they can start executing. So that's the trickle in. I leverage any scrap of technology I can so that I don't have to get people into a room and sit them all down around a conference table. I'll drop it into a secure chat channel, whatever we use, or I'll house it someplace in whatever secure storage area that the company uses already and just have them watch the materials there. The other thing that I leverage heavily is again, your chat channels, whatever your chosen chat channel is or your chat provider, and I start building the team into that channel. So it just inspires and it enables more constant communication. One of the things as an integration lead, as you're managing this team, that will knock you over is how much middleman or middle person you have to play between different functional people will come to you and say, hey, what about this? And you say, oh, have you talked to Kisan before? So then you have to do all this connecting. If you can cut yourself out of the middle and just bring everybody together in one place and free up that communication cycle. It not only takes the pressure off you, but it also accelerates the whole process as we think about integrating companies. Something that has always stuck with me and I'll share this with you and then you can prove me wrong someday is I think about flying planes, landing planes. I would rather as the integrator be the guy on the Runway with the orange cones helping land the plane. That's my ideal. That means I'm just kind of air traffic control. I'm just enabling the professionals to do what they already do. However, it doesn't always work, especially if you get a first time integrator. So I'm happy to be a co pilot. I'm happy to sit next to somebody and help them work through the process that they need to work through to integrate the company. I've seen this more than they have just my accidentally chosen career. And by the time you get through this one, whatever is coming down the pipe at us, you will have seen more than most people have seen as well. So co pilot is fine. We want them flying the plane. If I ever find myself flying the plane, I know something's gone wrong. It means that there's a gap in that company somewhere. Either capability, capacity, something is missing and that's when you and I may have to build a process to handle some of that. So that's a little bit about team and how we'll try to pull people together. I'm not going to teach about scaled agile now, but we talked about you're the quarterback and there's going to be little squads. Those squads can change week over week as they need to as we start dropping some of the objectives off the integration plan. And we talked about how it should feel. Not like any other day, but it should feel like we're just blending this company into processes that already exist. We're not going to make this a separate thing. We're just going to try to make this as much part of the business as we can.

Is there anybody that we report up to?

Depends. This is a function that unfortunately, especially in the size where we are, it can live almost anywhere and it gets passed around quite a bit. It makes sense in a couple different places or it can when we get to a place where maybe there's a head of corp dev that's maybe more the deal side and then integration can live under corp dev. In some companies you'll see the whole thing live under a cfo. Why because the driver is really financial. At some point, no matter what benefit we're bringing to anybody, drivers have financial ties. So a CFO makes sense to orchestrate some of this stuff. Once we get a little bit bigger, or if we want to make this our regular trick that we do, we're going to do these. Any kind of velocity. We may have head of corp dev reporting up to a CEO as well as a head of integration, which starts to feel more like an IMO or a PMO reporting up to a CEO as well. Again, depends on size of the company, maturity of the exercise, how tightly M and A and inorganic growth ties back to the company's goals.

You talked about Agile overview, governance roles, talk through that. There's typical cadence tooling and black dominoes.

You want to talk about cadence?

Yeah, I guess it's like how do we keep things from stalling out, make sure there's good progress.

I'm not going to teach about scaled agile all the way. You're going to learn it as we go. But let's talk a little bit about the Keynes. I will shock you to tell you that typically I operate without a documented project plan and that is heresy in this space. It takes agile to a place that concerns most. It works for me. It may not work for you. When you do that, you have to rely on the cadence above all else. Let's talk about the cadence because you're going to see a huge focus on it. The way I have done this in the past is again, I orient around not a function. I don't have a marketing check in. Because if you think about the way a business works, marketing and sales work pretty closely together and they're making decisions and they're waiting on each other for things. So what I do is I pull them together into a scrum team and anybody else who needs to fall into that go to market meeting, I'll pull them in as well. It might be sales ops, it might be product marketing. However we're configured, I find the little tangle of decisions and cross functional planning that needs to happen and I pull them together and we just rinse and repeat that throughout the company. So we're going to find all the process or cross functional kind of interweavings that we can and we're going to meet with them weekly. Those meetings are typically 30 minute meetings and I have a exceedingly simple agenda for those meetings and you'll be running them. And those meetings basically say what did you do last week? What are you doing next? Where are you stuck That's a weekly. I usually do those Tuesday and Wednesday so that we can maintain some of that progress. But then there's a really critical portion missing. If you just stick with those weekly meetings, you have some of your cross functional things happening, but there are tangential decisions, further reaching decisions, and stocks that can happen. So we're going to spread that out on Fridays and on Friday I get all of the scrum teams together into a big round table. And you will be shocked to find out that the typical agenda is what did we do last week? What are we about to do? And where are we stuck? I'll mix in some spotlights just to get people communicating and give them. Sometimes it's healthy conflict. I love to start a fight in those meetings because it generates some good, healthy discussion around places where we might be stuck. But again, it's just giving those functional leads an opportunity to say, hey, I'm stuck here, I need help, or I have a question. I'm confused. I forgot what we're trying to do. So that Friday meeting really orients them around what are we trying to accomplish? Not the tactical stuff. We know what we're trying to accomplish on a day to day kind of basis. What are we really trying to do with this? Are we thinking about the things and that's the cadence. I hold a steer CO in two different places. One might be with the board just to let them know how that progress is going. The other is with the exec team. In most cases, our integrators, our functional integrators, are not going to be execs. I prefer to have the execs off running the business while we're developing integrators inside the company at lower levels. As low as we can go, that's how low we'll go. So if we can find managers, individual contributors, interns, we'll take anybody who is willing to walk in the door and who's willing to try integrating your company. So that's the cadence in a nutshell. How do we close it out? Is one of the harder questions that I don't think I have a great answer for. Do you know how long it takes to integrate a company?

A couple months? It depends.

It takes the number of days between day one and the day you schedule the closeout is the best answer I've come up with. So all my integrations take 90 days. Why? Because I schedule the closeout 90 days from day one. Again, we're working in a space where we have a playbook for this and it should take about 90 days or less. There's long tail pieces to an integration. Some of the technical stuff, infrastructure or culture. You'll never fully integrate culture in 90 days. So we're talking about really the phase one integration. But we schedule a close out just to give us an excuse, but an ability to work towards something. It's the most important part of the closeout is having it on the calendar so that we know where the end zone is. You don't have an end zone. People don't know when they get to be done, so they eventually run out of steam.

What's an umbrella track?

We talked about some of these functions. We talked about pulling together, go to market, we talked about pulling together the client, making clients happy. Like those functions. Business Systems is one of these umbrella tracks that spans the entirety of the integration. It's a completely separate track and it's one of the biggest tracks from Business Systems I think of in terms of like your CRM, your erp, your marketing tech. I do a light switch go live, meaning on the same day all of those systems go live. I'll pull that as early into the integration process as possible. But that's typically the long pole in the tent. Imagine all of these functions working together in your weekly cycles to integrate functionally. Making sure that people are in team meetings and pulled into process. Tactical stuff like rebranding all the material. There's like regular work going on, but you can't be done until people are in Shared systems just doesn't work. You can have an outside the system process for a little while, but eventually you will break the scalability of a company if you have too much technical debt left over. So Business Systems is this umbrella track that runs almost separately. I have one person that will run that. You'll meet them at some point and they'll be your best friend because they're going to coordinate collecting requirements from all around the business and understanding how the two companies overlay in their software architecture. From a core business systems perspective, corporate it is a little bit separate, doesn't draw the same amount of focus that our CRM, ERP and marketing tech stack is going to draw. It's a track that kicks off on day one with us and it's going to run to the end.

We got a good overview of all these activities that are happening. How do we track all this stuff?

So if we're good, we don't. I have a concept that I walk around with in my head around. Maybe it's milestones, maybe it's. I've always Called them special dominoes or black dominoes and a string of white dominoes or however you want to think about these points that create a lot of momentum. If we can find those things, we have to track less. One of the things that I tried to get away from very quickly, in addition to being a middleman for a lot of this work, is tracking 1800 line project plan, waterfall style with dates on everything. And it just becomes too cumbersome and it becomes administrative. So one of the things I realized is you can cheat in doing these integrations and you can find these little activities or events in the process that drive everything else. For example, we could track meetings and tasks and documentation, all required to understand the products and the go to market motion and marketing positioning, all that. We could turn that into a thousand lines. Or we could approach sales enablement. Whatever function owns sales enablement. And we can say as long as it ties back to the thesis. For example, we want to train sales to cross sell these two products by the 1st 1st of November or the 30th of March. Just having that one clear objective will drive a ton of activity. We suddenly don't have to track all the falling dominoes on the way to this one event. We can just ask sales enablement, are we tracking to our cross sell enablement date? They're going to be watching all the tasks. We can check in and we can poke and we can prod and we can make sure that they're thinking about their things. But we've just gone from trackers and kind of project coordinators to momentum creators and that's really what we're going to look to do. I have found enough of these in a business where I feel way more comfortable operating without a super detailed plan than I do with. And what I have found in my limited but glorious experience is that our functional leads will appreciate it more as well. If you want to get pushback while doing a project, have somebody update a track. If you want to get buy in into creating value in a company by doing some of this stuff, have conversations with them in these scrum meetings. The other thing that frees you up to do, you and I are complete idiots in this process. We will never be as good at marketing, for example, as somebody who is in marketing is. We're just not. We are designed to stay out of the way. If we can create enough momentum, we don't need to force this in, we can just create momentum and we can steer the river. What we don't want to do with an 1800 line project plan is stifle somebody's creativity when they're professional in their field. Some of the greatest success that I've had has not been my success, but has been the success of others who just had the freedom to operate. So we just post a problem. Hey, we need to do this. I'll give you an example. We had to figure out quickly how to adjust pricing in one of these exercises. And if I had built out the plan all the way down to a task level before we even closed, I wouldn't have been close. But because we just posed this problem of adjust pricing and we just left space for the professional to provide input. During one of these Scrum meetings, it was a great conversation around between sales and marketing and sales ops who were all sitting in the same call. And this individual came up with one of the most creative ideas I've ever seen of basically having sales quote out of a sandbox. So they were leveraging some of the new pricing rules and and methodology which was absolutely required for the thesis of the acquisition months before we had them into the systems. I never would have thought to put that in a project plan because it was just free flowing creativity that came out of it. So on the question of how do you document. I don't. Maybe a PowerPoint slide here and there if I need to make a point in a meeting, especially a roundtable. But even at that, as we stand here talking today, I've been running these meetings for years now. The last 12 months. I can't remember the last PowerPoint slide I put up in one of those meetings.

Can we talk about the inverse? All the potential things that could go wrong and screw things up.

There's about a million things and they all fall into the larger bucket of thinking of an acquisition integration as some. Something completely foreign to other business process. I don't want to say that people and organizations make too much of it, but they try to make it too complex. We'll talk about that a little bit when we get to launch. Failing to launch one. But the big bucket is treating it like some unknown creature. But if we take a big step back, what's the first thing that can go wrong? And it's not having a plan. So one of the things that we see, especially from. If you think about the transition from deal side to integration side, the deal side is very high level thesis oriented and sometimes you get stuck there. So one of my questions early on, when I started having the pleasure of dealing with these kind of projects was how do you convert a thesis to an actionable plan. I don't know that I have a scientific answer for how to describe how that happens. But if you get stuck at the thesis level, it's hard to do something with that thesis. So I'll give you an example of why are you doing acquisition X. And the thesis may be because it expands our footprint into the European market. That's really like thesis level kind of stuff. And anybody who's been in a deal has seen incentives since similar to that. But when you say, okay, what does it mean to expand into a European market? Like, what's the next level down? That you don't need a thousand lines in a project plan that's written down to get to how you're going to do that. You just need to know, okay, how are we going to expand it? Are we going to use a indirect, like a channel market to expand, cross sell? What's the next thinking that we have to do about what is that thesis even trying to get to? As soon as you know that next level, it gives you access to all the task level items. So if we know we're going to expand by leveraging a partner channel to cross sell products from the legacy into the acquired company channel, we know that we got to get to enablement pretty quickly. And that's going to be my second weekend of enabling sales teams. And how do we combine? Partner marketing drives a lot of the actual planning that you can do. When I say not having a plan, it's getting to that next level of what are we actually trying to accomplish here? And that comes up all the time in not just integration, but just organic business process. If you don't know what you're trying to accomplish, you're not going to be able to do it. That's one thing that can go wrong. I'll say something controversial here very simply and then I'll walk it back a little bit. Another thing that can go wrong is you cannot integrate companies sometimes if they don't know what they're trying to accomplish. They have a lot of momentum coming up through the deal. They close the deal and then there's this moment where the company or the organization starts trying to figure out what to do. Now it's not because it's been a carefully thought out process around different levels and styles of integration. There are certainly scenarios where you may not want to do a full integration and we can walk through all different types of kind of a matrix of how deep of an integration you want to execute. But the lack of execution due to the lack of a Plan is where it can go wrong. Because essentially what you get is a deal close everybody high fives, and then there's radio silence. And then following confusion. Are we combining email addresses? Are we repapering employees? All of the things that lead both acquired and acquiring employees to feel like nobody has that plan and nobody knows what's going on. So creating confusion through lack of planning is one of the things can go wrong. So when I say failure to integrate, what I'm really saying is failure to integrate when you should have been integrating. That's not to discount the fact that sometimes you may not want to do a full integration if it doesn't support what you're trying to accomplish.

It sounds like a lot of the planning lends to the prioritization, which ultimately is those active activities that make the integration successful.

That's what it is. It's just, what are we trying to do? There's a big difference between acquiring a competitor that you might sunset in the market and acquiring for growth and expansion. The plan that comes out of those two things, for example, are wildly different in how you order them and what you prioritize. But it also impacts your decisions upstream in the deal. So if you don't know what you're trying to do by the time you sign loi, it impacts your diligence because you're asking different questions. You're in an area where you may be looking to remove a competitor from the space. The set of questions that you're asking are completely different in diligence from what you would be asking about somebody in the space that you're trying to grow and accelerate.

Similar with integration plan, you want to have something that's specific to the deal, what you're prioritizing to deliver value on.

Yeah.

Any other, like mechanical things that could go wrong with the deal that just things to look out for or some gotchas that pop up when we think about.

And let's tie it back again to the plan. If an organization doesn't really know what they're trying to accomplish, a lot of the day one communications are fuzzy. So it can impact your message internal to the company and the communication, your onboarding, Messaging, your Day 1 Town Halls, however you want to think about it, really focus around what just happened. You've been acquired. The next question that the employees have is, and then what? So if you don't have a plan, you can't really communicate that out and you can shake the employee base of two companies on the same day and people start thinking, okay, what are they not telling us. It may not be a desired lack of transparency. It may just be that there wasn't a plan to begin with. So you can actually start some pretty significant employee churn and exits if you're not clear about what it is that you're trying to do, as people assume the worst. You can also do the same thing in the market if you focus too heavily on the acquisition as the purpose of the acquisition. It doesn't land with customers, it doesn't land with partners, it doesn't land with vendors. Because again, it doesn't sound like you have a hey, we acquired X and they go, what's the next thing? It's got to be. This is going to add churn into what I'm trying to do. So let me start planning to not renew next year or let me start looking for somebody else to partner with, because I know where this is headed. So one of the gotchas is really, are you treating your day one communications or your announcements as acquisition announcements? Or for example, a product launch, just a new capability in the market? Other mechanical things you can forget. Onboarding, same thing. It's all tied in. If you miss your messaging, you may forget to make a decision around how you want to bring employees into the company, or you may just not bring them into the company. You may tell them they've been acquired and then let them sit in radio silence for three months while the leadership figures it out. That's a really dangerous one. Some of the most important people to the process early on are your hr, your pnc, but especially your engagement professionals who are really running. If there's a corporate boot camp or an onboarding program to bring in acquired employees as if they had selected the company. This just happened to be a couple hundred or a couple thousand employees that started working that day all the way through. Do we have to do anything with their hardware, their laptops, really bringing them on as you would bring on any other employee. And organizations forget about the acquired employees too frequently. The other thing that can go really mechanically wrong, it's one of the long poles in the integration tent is your infrastructure, your software, your business systems infrastructure. Email. And I can say this because I'm not an IT professional, email is easy, right? It's a big project, but it's relatively straightforward and it's easy to think of because as soon as you acquire employees, the first thing you want to do is schedule a meeting with them. And if you're not on a similar email system, it's hard to do. And somebody raises the Issue. Hey, it'd be nice if we were all in the same place so that we could talk to each other more easily. So when I say easy, it's very visible and it's a smaller kind of project. Your business systems around CRM, erp, your marketing stack, any of your standard kind of reporting that is one of the more complex pieces of an integration. It's specialty IT track and depending on the size of the company, different companies handle the different ways. But forgetting to do that or starting too late can J Curve company's performance pretty quickly. Anytime you introduce friction into something like closing a deal or reporting a forecast or driving sales performance through some of that reporting, because you're looking at two different systems and there's not a plan to get out of that that can really drag on a company's performance. And it's hard. It's hard to do it. It's hard to do it fast. And the longer it goes on, the more project fatigue sets in in the company. And not all companies have the personnel needed to be able to do it well and fast. So mechanical issue number two is not having the skill set in the company to begin with or not having those roles properly filled out and identified ahead of the acquisition.

A lot of this is around prioritization, accountability. When we have kickoff meetings and tried to set the tone and alignment. Can you walk me through that? How do you make kickoff meetings? How many kickoff meetings, who's in them?

It actually brings up a good point. So let's talk about something else. Maybe not mechanical. It's something else that can go wrong and it goes wrong all the time. And that is anytime you create a gap or a handoff and there's a lot of places along the way in these parallel tracks where you can create a gap called a chasm between the deal side. The integration people want to highlight that because it's obvious. But if you think about very tactically, then we'll. I'll tie this back to the kickoff. Think about the deal team and how a deal team can be configured. You may have a dedicated finance like a modeling kind of resource on this deal team who's handling the entire model. As you're going through the deal and you're trying to prove that it's accretive to whatever you're trying to accomplish, there comes a moment at close or slightly before close, some organizations operating that model is handed over to the go forward finance team. If it's done perfectly, you don't miss a beat. However, it's never done perfectly. If somebody uses a different format, the formulas don't match up. What goes from a simple, like free statement is made unnecessarily complex. You have to understand how somebody treated accounting rules and how they're accounting for them. So the handoff anywhere where you create a gap or a chasm between a person who started it or an organization who started it, and a person who's an organization who's taking it forward, that's a mechanical issue. That's a place where you can create that gap. So one of the ways that you can solve for that, and I think the last time we chatted, I talked about how I do a rolling kickoff to get people engaged, get some of your functional lead engaged, rather than doing a big bang approach, is you can do a little mini launch or a little mini kickoff after you've done a soft launch with your leads. And you can do it however you want to do. You can do it in a deck, you can do it in a presentation format, you can do it on a spreadsheet, you can do it in a tool. It doesn't really matter. The concept is through a kickoff, you really want to be delivering the next level down from the thesis. You want to take all of the driving purpose in the deal and you want to convey that to the team who's going to be integrating. So you boil that all down and you basically write stories out of it. So if you're thinking about when is the integration done, for example, you can describe what good looks like on one page, let's take sales, for example. But you can write up a few simple statements. Just around done is when sales team A is successfully cross selling products from acquired company B. We'll know this because we can see it in a consolidated dashboard in our business systems. There's a couple of simple words in there, but a lot of things have to go into that. So that really helps you codify the purpose of the acquisition. And as you're bringing your leads in, that's the story that you're telling them. Hey, this is what good looks like. Just so you know, at that point, you don't need a thousand lines to tell them how to get there. You're just telling them where they need to get to.

Can you give me some more examples of stories? Maybe different departments, just to make sure I get this, because it sounds pretty pertinent to have a format where you're communicating what the end state or goal looks like.

That's the beauty of stories. They don't have to be overly complex and you're no longer focused on the how the tasks to get there. If you think about an HR or a P and C story, really simply, it might be something like what good looks like is 100% of acquired employees have received go forward paperwork as designated by their governing entity or whatever are visible in a consolidated hris and have completed a standard onboarding session if adjusted to their current work schedule. That's simple and quick, but it gives you an idea of like, okay, we've already made the decision that we're going to repaper employees. We're definitely bring them into our HRIs and we're all going to be one happy family. And we can't forget about onboarding because we want to bring them in culture wise too. Not just the mechanical kind of paperwork stuff, the stuff that moves from HR to pnc. You take simple sentences like that and you can throw it in whatever format you want and you hand it to your P and C lead and you say, this is what good looks like.

What's a pnc?

People and culture.

Okay?

So as you move through the process, you onboard your functional leads into the idea of what you're trying to accomplish at a kickoff, that functional lead can now present back to you and leadership and whoever else needs to be there. The company if helpful. Here's what I am trying to do in this integration and it's the stories that you've already given them. You can ask them questions about, hey, what do you think are a couple of the big milestones you're going to need to hit along the way? Just to see there's going to be conversations around maybe consolidating payroll that might not be the driving factor behind the acquisition, but it may fall out of some of the other pieces of the story that you gave them. So they're crafting their plan as they go just by understanding what you're trying to do and then you work through the integration and as long as you have good alignment in the company around what good looks like when you're done because you threw your stories on a page, by the time you get to a closeout, wherever you set your closeout, those same leads should be able to stand in the closeout and say, I know that I'm done because here are the stories that I was tracking to and I can show you pictures of the fact that it's done. It's hard to show pictures of completed tasks, but you can usually find some examples just around in a company in your day to day operating that are good visual Depictions of done if you've written a story well enough.

I like this reminds me of user stories in the tech world. Like here's the standardized format, we all agree to it and what are we going to call it in the M and A world? That's not user stories, it's called a user story. Why not that basically what it is, it's user story you're using in a similar way but different purpose.

That's all it is. And again, I didn't invent any of this. The tool is there, it's fit for purpose, for use in acquisition integration. But again, if you think of acquisition integration as something that's so complex and different from organic business process, you look past the fact that all you're doing is is collecting requirements, executing and delivering. You can make it simpler than we have made it as an industry for too long.

I think that's a good point in all this is keeping this level of simplicity. It's easier to communicate and keep people aligned.

I don't know if I've shared with you before, but I run documentation light almost to a fault. And where I really started going with it was this concept of using stories to guide the functional leads as professionals. What I found when I really started backing off some really deep integration plans, the thousand lines or the 2000 lines, those plans tend to box professionals in and they tend to tamp down on creativity. And if you're delivering somebody a 2, 2000 line plan, what you're focusing on is what date are you done with line 89 and what's your red, yellow, green status now? Which there's a place for waterfall and there's a place for task management. But at the higher level, if you tell somebody I want to be cross selling in three weeks and you send them off to make it happen, if you're working with professionals, they can find some creative ways that nobody else would have thought of to even put in an integration plan. And I've seen that play out Sales ops professionals that come up with something that you didn't even know could work shortcuts and hacks that nobody else would have even thought about. And it accelerates the plan. So rather than box people in with the hows and the steps and the what's, just lay out the goal and let them navigate their way there. It takes coaching, it takes mentoring and there's some air traffic controlling that you have to do when you don't have tasks that you can tie back to dependencies. But it tends to make it a little bit less Constrictive and less oppressive than hitting somebody with updates on a project plan weekly.

How do you know when you're done, things are done, ready to move on, sign off on everything? Like, when does that happen?

If you've done it well at the beginning, you've pulled your requirements just like anything else. It's like developing a piece of software. Your software is never done. You're just developing features or pieces or the next iteration. So if you've done your work at the beginning of the project and you've pulled requirements from your stakeholders, what does an integration look like when it's done and really work through that process across all of your different functions? Or your stakeholders could be the board, could be internal, could be whoever. Then you know you're done when you've checked off all of your stories. There's a really hard question around doing rapid integrations and some of the long tail stuff that will never happen on a short timeline. Culture is one of them. You can do some of your basic core mechanical integration stuff in a couple of months, but culture builds and it merges and it iterates over time. So to say, okay, we're going to have a full cultural integration in 90 days is not going to happen. So you may run a long tail on your cultural integration with your PMC team, but it should all flow out of a story. If you take a requirement from them that here's what a culturally integrated company looks like and you look at it, you say that's probably going to take a year, that's fine. Work through your other requirements that you can get done in a couple of months. And then you just build out your cadence to after your big closeout. Maybe you have quarterly check ins with PNC and just track to that same story that you pulled at the beginning that really defines what does culturally integrated look like. So you know you're done when you've met your requirements. The hard part is nobody pulls requirements at the beginning of these. They just start integrating your company and you have to try to figure out when it's done.

Sounds definitely easier said than done. What would be any other best advice you'd have to give somebody doing this for the first time?

Keep it simple. Don't let the process or the plan drive the activity. It is an area where, and again, keep in mind the section of the industry where I do most of my work is smaller to mid end. It's where most of the deals happen in the industry. At some point you cross a threshold up into some of these larger players. In the space. And some of this will break down or will need to be adjusted. But keep it simple. Don't let the plan dictate the activities. Work with the professionals in the organization. Most organizations don't run with a full portfolio management, task management kind of approach. So why bring that with an acquisition integration? It's overly complex. People aren't used to it. They're not used to signing into somebody else's system to work through it. So meet the company where they are, work with individuals as if they have never done an integration before and go back to some of that story approach and try to make it as organic a business process as it possibly can be. I have seen examples, I've been part of examples where an acquired company had a predetermined org cutover date, meaning I have acquired the company that you work for. You are in sales. I am in sales, but you're not going to report to me for at least 90 days because we don't want to disrupt the organization. There's a lot of positive intent behind that. However, if you think about an organic business process, I think of you not as an acquired employee, but I think of you as a new hire to my team. There's no way that I would leave you off on some island for 90 days because I don't want to disrupt you. I want to bring you into the team as quickly as I can. I want to get the team's arms around you and start bringing you into processes and the culture and the meetups. And I don't want you to feel new for very long. But for some reason in acquisitions we tend to do this where we unintentionally keep it in us in them. Reporting structure is going to continue for 90 days. It creates all types of alignment issues at the top and no ill intent. But misaligned, competing priorities can flow through. It's hard enough to keep priorities aligned in a single organization, but keeping two separate organizations is next to impossible. Bringing that person in as quickly as you can, that's an organic business process. So don't do it differently than you would otherwise. Don't launch an acquired company. Don't message an acquired company. Turn it into a product launch. You already have a product launch process in your company. Use that. Why would you use anything different? It's already the tools that you have don't hold up separate business process, misaligned business process for any longer than you have to cut them over. Just think about it's not integrating process, it's meeting a team that for Some reason has been doing it, quote unquote wrong the entire time.

Essentially you're trying to act as one team. That's how you want to get to.

What a strange concept. Now all of this comes back to the fact that there are different types of integrations that you can run, but that'll all flow out of an actual plan. There are excellent reasons to hold up a business unit. Those reasons are fewer than the reasons to fully integrate a company, especially in the space where I play. But there are reasons to leave companies fully. Not off on their own, but with a separate operating structure and with maybe a GM in place. And there's a couple of things that make that not make sense really quickly and you can spot them in the deal as long as you're doing the work on what is it that we're trying to accomplish? Simple things like we have a goal to cross sell. That can knock down a business unit pretty quickly. So if you know that early on, you say, okay, the business unit's not for us. We're going to do more of a comprehensive integration here. Once you know that, just do it.

This has been really good information here. I always got to ask this question, but what's the craziest thing you've seen in M and A?

I think it's some combination of all of those things that I just mentioned happening. Like poorly falling dominoes leading to the end result of nobody knowing when you're done. I have seen also so on the other end of it, maybe not process, but just situation I have seen. Maybe not the craziest thing. It's an unfortunate thing. As you look at some of these deals during functional diligence, it becomes really obvious that it's not one company, it's remnants of partially digested companies. Five, six, seven companies where the systems were never aligned because of all the things that we just talked about. Maybe poor planning, poor execution, whatever it was. But as you look at the company from a high level, functional level, you can see the pain that it creates and you can see the misalignment and you can see broken product positioning because nothing ever connects. You can see how hard it is on the employees just to live in their own systems, just to get clean reporting out of something. The stuff that employees shouldn't have to think about on a day to day basis suddenly becomes their whole world. Just dealing with some of the inefficiencies. And that can really drag on the company, which ironically makes them more affordable. Unfortunate that you get to look at a company that's been Frankensteined together and you can feel the pain on the employees, but also just the unfortunate drag on the company. And you see the opportunity that was missed for that to be a successful company or a more successful company. But you then have the opportunity to correct that on the backside by doing it and bringing it in properly. Those are a lot of work. Those are never fun. But you have a chance to really do what acquisition integration is all about, which is create value. So cleaning up the inefficiencies, cleaning up the leftovers, bringing some consolidation and just efficiency and ease to people's day. You can create a lot of value really quickly by doing that just because somebody else didn't know how to do it.

I think you set us up for the next podcast where we can contrast these companies that are essentially cobbled together, Frankenstein versus the well done integration and maybe figure out what the difference between the two. And what do you do with the cobbled business to make it right? It's been good. Thanks for doing this. I always wanted to pilot the different format for a podcast. I was thinking about it in this interview. I don't think Teach the Dumb Intern is probably the right title for the series, but we can call it My First Deal and it's just all the conversations for somebody just working on their first deal.

I like it. I've been around enough deals. I've done my own deals. I'm not great at it. That's not where I belong. I can get it done for sure, but it might be interesting to bring in somebody else like a Subia Khan or something who's done a lot and can talk about the deal at a more tactical level just to be able to bounce some of this around. Integration is really cross functional, obviously, but the deal side and the integration side, the cross functional nature of that is often overlooked. If an integration lead can find a true partner in a deal lead, there's so much magic that can happen there that's often missed because of the chasms or because of my side, your side or we'll let you know when we're done kind of thinking. But you can achieve so much value so much further upstream than we usually do if you really find a good partner in that space. That's a great point.

This has been great. Thanks again for taking the time to have this conversation. I learned a ton there and every conversation I have helps me become a better M and A scientist. So thanks you for helping to contribute to this growing M and A science community.

Absolutely. Thanks for having me. I've shared with you before that. One of the reasons that I'm still in this field, in this industry is M and A Science. I was on my way out at one point because I just figured, this is too hard. It's not for me. Nobody understands what this is all about. And then I met the M and A science community several years ago now and heard, oh, I am not alone in how miserable this profession can be sometimes. And it really kept me in it. So I'm happy to be here. So thank you. As much as you're thinking me, wow.

I really appreciate it. It's really meaningful. Let's keep the conversation going here. Those of you still tuned in, thank you for sticking through. Until next time, here's to the deal. Thank you for taking the time to explore the world of M and A with our podcast. We love hearing feedback. Tag us on a LinkedIn post, add a review on Apple Podcasts. We'd love to hear from you. If you need help standing up an M and A function or optimizing one that you already have, we're here to help. And if we can't help you, we probably know someone that can. You can reach out to me by email Kisan K I S o n@mascience.com or you can text me directly at 312-857-3711. If you just want to keep learning at your own pace, visit Masscience.com for a lot more content and resources. That's where you can also subscribe to our newsletter. Again, that's Masscience.com here's to the deal.

Foreign.

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.