The Basics of M&A Integration Execution

Coaching an integration lead

At 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 Salesforce's or the Cisco's where there's dedicated teams. You're basically collecting who you have. 

So when this happens, somebody shows up as a first-timer and you just start going and you start walking through. Aside from getting to know that person's name, the 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. So, you and I need to get our arms around what's coming and when. 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 is go find whoever's running the deal.

Typically, in 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.

Involving the Integration Lead

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 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, deal teams. We want to have input into that 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.

From LOI, we'll go to diligence. 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, most critical spots for the integration team to get pulled in.

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 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 an acquiring company. 

For us, the important thing is functional diligence. It can go in a lot of different ways, and one way that it can go is by sending over a DRL (data request list). This is your top 10, top 50, top 100 questions that you need answered. Those questions are going to feed right into our integration plan.

So, we want to write or 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 the functional diligence meetings. 

So think about meeting with 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 and kind of 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.

At a superficial level, we're trying to understand the company and think ahead, asking the questions now to save them from being asked later. Also, if we know the answer to those questions, we can put together a better plan and already have momentum.

I mentioned something about a thesis. A thesis is tricky because it's just the idea of why we are acquiring this company. There could be a variety of reasons to acquire a company: to enter a new market, maybe just to boost EBITDA, among other reasons.

What can be surprising to somebody who hasn't been in the industry for a while is that the thesis is sometimes razor-thin. There's kind of 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 the product and you don't know that 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, forecasting, planning, as well as some of the more tactical integration planning that we're going to do.

So 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, it feels kind of like that. There's usually an SPA or an APA that determines what parts of the company you buy, so to speak.

And that runs in parallel with us. So once we get through diligence, the biggest part of our year is going to be planning day 1, and that's really if you want to think about a handoff. Day 1 is where the deal team, more or less, goes away. It becomes less about the deal team because they've closed, and it becomes more about bringing that company into our company.

Integration on Day one

So day one is not actually day one. Depending on the size of the company you're in, it can happen a couple of different ways. In larger companies, you'll see proactive announcements. In big deals, especially in the 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. So there will be a very small, tight, somewhat secretive deal team. 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 sour a deal, impact customers, and impact financials with a thesis for doing the deal in the first place. So we typically keep it pretty tight. 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 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&A in two halves: the party and the hangover. You and I get to be the hangover. 

So 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 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.' I assure you we will have it down to the minute because the people who are involved, the employees, shareholders, and 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, RIFs, 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.

We don't get to go to the party because we're too busy working. It's kind of the joke that the deal team gets to be done. But it discounts the fact that they've been working 80-hour weeks for the last few months, or even 18 months on a bigger deal. So we give them some lip about it, but really, they've been doing their work.

You can do any of those things superficially, and you can make an announcement like 'Company A acquires Company B.' But that's not the point. If we come back to the thesis, we try to think, what are we trying to accomplish? 

Another way you can do it is to 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 you want to talk to. 

So, the idea is to bring it through an entire launch process. Rather than sending out an email, 'Company 1 acquires Company 2,' 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 guide our integration plan. That's going to flow right into things like sales enablement around cross-sell or whatever we're doing with this company. 

So, day 1 has a bunch of stakeholders. Employees being arguably the biggest, customers tied for first, and then stakeholders second, right behind.

Getting ready for Day one

You haven't asked me how long it takes to build out a schedule for day 1, which includes all of the communications, all of the paperwork, and all of the employee onboarding touchpoints, both 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, 3 weeks. I feel pretty good about 3 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 are more documents that have to fly around, but 3 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 3 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 of this is built and coordinated, and that the change management prep inside the company has already occurred. 

The next question you should be asking me is, “well, 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 is, 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 of scale to agile is your friend. 

One of the things we're going to do is we're going to identify teams, little squads, little 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 are 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 of 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. So I try to get the acquired company onto 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. 

So, to make that happen, you and I will bring in our corporate IT function a little bit earlier, and we'll start warming them up and getting them prepared. We're then going to look through our integration plan. 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 1, 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 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, and we're just going to launch scaled agile. So, rather than going big bang with a kickoff and kind of an, okay, we start tomorrow, we're going to make this more of a gradual process. So it's going to feel like a process, not an event. 

M&A teams to pull in for integration

Who we need to pull in is a fascinating question and it's going to depend on the environment we're in. In larger companies, there may be an Integration Management Office (IMO) team. If you ever move on to larger companies, they might have a dedicated IMO that operates as a unit, and you might find yourself leading it. Some of your IMO consultants may already be in diligence. 

For us, in a smaller environment, it's going to be different. You and I are essentially going to seek out skilled individuals. We're going to approach the executive team, who already know this is coming, and ask them, 'We have these goals for integrating these two companies. Who would you recommend we pull in?' They need to be either an up-and-comer or a top performer. 

We can teach them everything they need to know about integrating a company. We need them to be a professional, to either know their field really well or be a quick learner. We also need them to be incredibly cross-functionally oriented, which is a rarity in most companies. 

Companies tend to operate in silos, but integrators and those working with them can't afford to be siloed. So, we're going to find those people who are best at being cross-functional. You find them in unexpected places in the company, and they might be the person that knows everybody. They're kind of the central points of either culture or knowledge because they know everything. Those tend to be good integrators because they know how to get things done. 

So that's how we're going to build the teams. We're just going to start asking for executives. There's always tension when we're knocking on these doors. It feels like extra work. 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 like an event and less administratively heavy. 

If you think about the launch mentality, the company is already launching products. We just need them to do that again with some information we give them about this new acquisition. So, we're going to repeat that process. The messaging we're going to give 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 implementing a new product into the processes that already exist. So that's kind of how you would go about formulating the team.

Kickoff meeting strategies

I'll give you two bits on a kickoff. If we do a trickle-in, there's not one big kickoff. But what I do have at hand, if I'm doing 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. 

I stash it somewhere safe and secure and as somebody comes in, I have them sign a Non-Disclosure Agreement (NDA) and have them watch the materials. So now they're all caught up on at least the basics. They're not going to have all the nitty-gritty details, but they have exactly what they need to know and they can start executing.

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 or 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 your chat channels. Whatever your chosen chat channel is, or your chat provider, and I start building the team into that channel. It just inspires and 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 needs.

People will come to you and say, 'Hey, what about this?' And you say, 'Oh, have you talked to Kisanon 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 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, 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 because that means I'm just kind of air traffic control. I'm just enabling the professionals to do what they already do well. However, it doesn't always work, especially if you get a first-time integrator. So I'm happy to be a copilot. 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. It's just my accidentally chosen career. And by the time you get through this one, whatever's coming down the pipe at us, you will have seen more than most people have seen as well. So copilot is fine. 

We want them flying the plane now. 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 void. So that's a little bit about the team and how we pull people together. 

I'm not going to teach about scaled agile right now, but we talked about the other 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.

Who we report up to depends. This function, especially in our size of company, can reside almost anywhere and often gets shifted around. It logically fits in several different places. When there's a head of Corporate Development (Corp Dev), that's typically more on the deal side, and then integration might reside under Corp Dev.

In some companies, the entire function might live under a CFO. Why? Because the primary driver is financial. Regardless of the benefit we're bringing to anyone, the drivers have financial implications, so it makes sense for the CFO to orchestrate some of this. 

Once we get a bit larger, or if we decide to make this a regular activity—if we're going to execute these with any kind of velocity—we might have a Head of Corp Dev reporting up to a CEO, as well as a Head of Integration, which starts to feel more like an Integration Management Office (IMO) or a Project Management Office (PMO), also reporting up to a CEO. 

Again, it depends on the size of the company, the maturity of the exercise, and how closely M&A and inorganic growth are tied back to the company's goals.

Maintaining regular cadence for good progress

You might find it surprising that I typically operate without a documented project plan, which is often considered heresy in this space. It takes agile to a place that concerns most.

It works for me, but it might not work for you. When you do that, you have to rely on the cadence above all else. So 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, 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.

They're making decisions and 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 processes or cross-functional interweavings that we can, and we're going to meet with them weekly.

Those meetings are typically 30-minute meetings, and I have an 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? 

So, 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 because you have some of your cross-functional things happening but there are tangential decisions and stops 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 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 needs 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 oriented around like, what are we trying to accomplish? Not the tactical stuff. We know what we're trying to accomplish on a day-to-day basis. What are we really trying to do with this? Are we thinking about the right things? And that's the cadence. 

I hold a steering committee 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 is willing to try integrating a company.

So that's the cadence in a nutshell. How do we close it out is one of the harder questions. I don't think I have a great answer for, do you know how long it takes to integrate a company? A month, it depends. It takes the number of days between day 1 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 1. 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 a long tail 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 1 integration, but we schedule a closeout just to give us an ability to work towards something. The most important part of the closeout is having it on the calendar so that we know where the end zone is. If you don't have an end zone people don't know when they get to be done so they eventually run out of steam.

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. Business systems are one of these umbrella tracks that span the entirety of the integration. It's a completely separate track and it's one of the biggest tracks.

And business systems, I think of in terms of your CRM, your ERP, your marketing tech, there is 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. So, imagine all of these functions.

Working together in your weekly cycles. To integrate function, making sure that people are in team meetings and pulled into process and tactical stuff like rebranding all the materials. There's 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, it 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 simply. 

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. It's not as focused as our CRM, ERP, and marketing tech stack. So it's a track that kicks off on day 1 with us. And it's going to run right to the end.

How to track integration activities

If we’re good we don’t track those activities. I walk around with a concept in my head around milestones. I've always referred to them as special dominoes or black dominoes in a string of white dominoes, or however you want to think about these points that create a lot of momentum.

If we can identify those things, we have to track less. One of the things I tried to move away from quickly was being a middleman for a lot of this work and tracking an 1800-line project plan, waterfall style with dates on everything. It just becomes too cumbersome and administrative.

One of the things I realized is you can cheat in doing these integrations. 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 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 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. And we can check in, and we can poke and we can prod, and we can make sure that they're thinking about the right things, but we've just gone from trackers and 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 tracker. 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 that frees you up to do is, you and I are complete novices 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 kind of steer the river. What we don't want to do with an 1800 line project plan is stifle somebody's creativity when they're a professional in their field.

Some of the greatest success that I've had has not been my success, but it's been the success of others who just had the freedom to operate. So, we just posted a problem. 'Hey, we need to do this.' I'll give you an example of, 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 adjusting pricing, and we just left space for the professional to provide input during one of these meetings, it was a great conversation around between sales and marketing and sales ops. We're all sitting on the same call. And this individual came up with one of the most creative ideas I've ever seen of basically having a sales quote out of a sandbox. 

So they were leveraging some of the new pricing rules 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, but I, in the last 12 months, can't remember the last PowerPoint slide I put up in one of those meetings.

Challenges during integration

There's about a million things, and they all kind of fall into a larger bucket of thinking of an acquisition integration as something completely foreign to other business processes. So it's not 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. 

So, if we take a big step backward, what's the first thing that can go wrong? And it's not having a plan. Especially from 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 kinds of projects was how do you convert a thesis to an actionable plan? And 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.

I'll give you an example of why you might do acquisition X. And the thesis may be because it expands our footprint into the European market. That's really a thesis-level kind of stuff. And anybody who's been in a deal has seen a sentence similar to that. 

But when you say, okay, what does it mean to expand into a European market, what's the next level down? 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 how you’re going to expand. Or we're going to use an indirect, like a channel market to expand cross.

So what's the next thinking that we have to do about what is that thesis even trying to get to because as soon as you know that next level, it gives you access to all kinds of 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 have to get to enablement pretty quickly. And that's going to be my second weekend of enabling sales teams. And how we combine partner marketing drives a lot of the actual planning that you can do.

So when I say not having a plan, it's getting to that next level of what we are actually trying to accomplish here. And that comes up all the time in not just integration, but just organic business processes. If you don't know what you're trying to accomplish, you're not going to be able to do it. So that's one thing that can go wrong.

Another thing that can go wrong is you can not integrate. So, 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. We can walk through all different types 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 closed, 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 a plan and nobody knows what's going on. So creating confusion through lack of planning is one of the things that 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.

That's what it is. It's just determining what we are trying to do. If it's acquiring a competitor that you might sunset in the market versus acquiring for growth and expansion, the plan that emerges from those two scenarios, for example, are wildly different in how you order them and what you prioritize, but it also impacts your decisions.

Upstream in the deal, if you don't know what you're trying to do by the time you sign the 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 a competitor that you're trying to grow and accelerate.

Mechanical things that could go wrong during integration

There's a ton of them. When we think about it, 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. 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, but 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. People start thinking, 'Okay, what are they not telling us?' It may not be a desire to lack 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 exit if you're not clear about what it is that you're trying to do because 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, partners, or vendors because, again, it doesn't sound like you have a plan. 'Hey, we acquired X,' and they go, 'Well, 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 how you are treating your day 1 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 kind of 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, it's 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, and it's one of the long poles in the integration tent, is your infrastructure, your software, your business systems infrastructure. 

I can say this because I'm not an IT professional, email is easy. 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. 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 reporting. That is one of the more complex pieces of an integration. It's a specialty track. And depending on the size of the company, different companies handle it in different ways, but forgetting to do that or starting too late can J curve a 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 well, 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 right skill set in the company to begin with or not having those roles properly filled out and identified ahead of the acquisition.

Setting alignment for kickoff meetings

Let's talk about something else, maybe not mechanical, something else that can go wrong and it goes wrong all the time. That is, anytime you create a gap or a handoff. There are a lot of places along the way in these parallel tracks where you can create a gap, a chasm, between the deal side and the integration people. I want to highlight that because it's obvious.

But if you think about it very tactically, and then 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 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, and in 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. There may be a different format, the formulas don't match up, what goes from a simple free statement is made unnecessarily complex.

You have to understand how someone 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 or an organization who started it and a person or 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 functionality 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. You can do it however you want to do it, but the idea is 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 your knowledge, all of the driving purpose in the deal, and you want to convey that to the team who's going to be integrated. So you boil that all down and you basically write stories out of it. 

So if you're thinking about when the integration is done, for example, you can describe what good looks like on one page. And let's take sales, for example, 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 are 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 1000 lines to tell them how to get there. You're just telling them where they need to get to.

What success looks like through stories

The beauty of stories is they don't have to be overly complex, and you're no longer focused on the “how” or the tasks to get there. If you think about an HR or a P&C story, it might be something like, what good looks like is 100 percent 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 adjusted to their current work schedule. 

So that gives you an idea, and it's simple and quick, but it gives you an idea of like, “Okay, we've already made the decision that we're going to prepare for employees. We're definitely bringing 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 P&C.” 

So you take simple sentences like that, and you can throw it in whatever format you want, and you hand it to your P&C lead and you say, this is what good looks like.

P&C means People and culture. It's the new HR. 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 at 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. And 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 operation that are good visual depictions of done if you've written a story well enough.

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

And, 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 1000 lines or the 2000 lines, is that those plans tend to box professionals in, and they tend to tamp down on creativity.

If you're delivering somebody a 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 right now? 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 3 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, like shortcuts and tricks, 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 whats, just lay out the goal and let them navigate their way there. It takes coaching. It takes mentoring. And there's some air traffic control that you have to do when you don't have any kind of 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 to know when the integration is complete

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 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 P&C team. But it should all flow out of a story. 

So 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 after your big closeout.

Maybe you have quarterly check-ins with P&C and just track to that same story that you pulled at the beginning that really defines what culturally integrated looks like. So you know you're done when you've met your requirements. The hard part is that nobody pulls requirements at the beginning when they start integrating your company, and you have to try to figure out when it's done.

Advice for first timers

Best advice for somebody coming in is 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 the smaller to mid, and 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 are 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. Try to make it as organic a business process as it possibly can be.

Here's a concrete example. 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, if 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. 

And I want to get the team's arms around you and start bringing you into processes and the culture and the meetups and I want to make it, 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 and them kind of feel. Oh, the 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. So bring 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 processes, misaligned business processes for any longer than you have to cut them over. Just think about, it's not an integrating process. It's meeting a team that for some reason has been doing it “wrong” the entire time.

Trying to act as one team is such 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 size of the space where I play. But there are reasons to leave companies with a separate operating structure and maybe a GM in place. 

And there's a couple of things that make that not make sense really quickly. You can spot them in the deal. As long as you're doing the work on what 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 is not for us; we're going to do more of a comprehensive integration here. Once you know that, just do it.”