Why You Should Update Your M&A Management Approach

Text Version of the Interview

How do you make integration simple? 

You start simple. In my experience, our comfort zone is in the details. We get very tactical very quickly and I've learned the hard way. You have to keep people at the big picture for as long as possible to ensure everybody gets it and can move forward. 

It sounds simple, but it's not. Like many things, keeping things simple is hard to do. We love complicated gnarly things, and the sooner we're there, the better off we are.

I like the analogy of the boulder, rock, pebble. With the boulder being the strategy, the big problem you're trying to solve. The rocks are the deliverables,  integration budgets, timelines, projects, micromanaged micro projects within projects. 

And that's where eventually you get to the pebbles. The people that love to live in the pebbles are the ones that scare me the most cause they're like looking at everything through such a finite lens. 

Keep things at the boulder level for as long as possible to make sure people get it. Because if you don't start out aligned, stuff breaks really quickly and, in some cases, very expensively.

Keeping Alignment

It's all about communication, and it needs to be communicated simply. When I started at Microsoft, our new CFO had a very unique style of communication. He never wanted to see a deck presented to him around a deal that was more than five slides, more than five bullets per slide, and more than five words per bullet. So five by five by five. 

He never wanted to know details about our work, and all he wanted to know is how our work hangs off the strategy. If we went over those 5 by 5 rules, he would reschedule the meeting. 

Biggest Challenge

It's making sure people understand it. My experience with well-drafted strategies is that they, too are simple. Strategies are basically problem-solving. What problem are you trying to solve with the strategy? I think it's that simple. 

There are firms out there that feel like they're paid by the slide and that they're paid to make the thing so freaking complicated that nobody gets it. 

How to Avoid Checklists

I did that early in my career, thinking that more was better. But I've learned over the years that that's not true. 

I start at the end to effectively manage my team and build out the integration plan. What does done look like? When we're going around and saying we completed the integration plan, what does that look like? Can you explain it?

And then you work your way to what I call the left of the process or the milestones just prior to that end state. And then you move another step left and another left. 

This is important because nobody early in the deal is going to have a thousand-line checklist to define done. They're going to have a big idea in their mind, what does done look like, that they need to communicate, which by definition should be simple. 

And then as you back up through the process, you can start to go from 1 to 5, to 10, to 30, to a hundred, to 500, to however many rows people need. 

But I don't ever want to see that body of work. I just want to know:

• What are your milestones? Which is the macro level of all those sub checklists.
• Is it in the proper order? 
• Have you identified the interdependencies? 
• Have you identified the resources needed to accomplish it? 
• Is it bought off by the business that's responsible for the acquisition? 

You got to keep it simple for as long as possible.

And this process tells you if they know what done look like. Because most people don't know. They can sit there and say, all the employees are onboarded. They all have payroll, and they all have computers. There are six different IP or product milestones. 

Independently they all make sense, but how does it all work together? Do we have all the right developers to achieve those milestones, which is both a people workstream and our product workstream? Have those two workstreams talk to each other. And they don't know. They just know that those things need to happen. 

So we need to double click back up and identify how does your work hang off the strategy? How does this support the strategic rationale as you identify what work looks like at the end state and what done looks like? 

Big Picture Alignment

I try to stay out of the way, cause I have a tendency to weigh in. So I don't want to be in the mix of the work. I trust my team to do the right thing the right way. But review with them every week where they are in the process, and make sure they're going down the right path before they finish.

And then the other thing is ensuring that they're talking to interdependencies. I don't want to be in the meetings, but are you talking to all the functions and team members that you have interdependencies with? Because the interdependencies are what will break things. 

If everything just goes down a skinny little bowling alley but doesn't connect to the other bowling alleys, then you just end up with pins at the end of your workstream knocked over, but you don't know that they fell on the right order.  

Did you need to knock all of them down? Did you need to knock any of them down? 

To me, the brilliant part is when someone says I don't need to do anything. I don't need to be part of this. You don't need me because this body of work is not part of what done looks like, so I don't need to be involved. 

Frameworks over Checklists

I am not a fan of playbooks. There's a playbook for sports, and those are needed. There's a playbook for M&A, and those are clearly needed because it exhibits someone's understanding of the work. But that loosely translates into a checklist. 

And I'm horrible with checklists. I don't want to be told what to do, and I certainly don't want to be told what order to do it in, but that's what a checklist is. It's boring; it's redundant; it's repetitive. 

It assumes that the approach and the solution are the same for every M&A transaction, which, as we all know, is the farthest thing from the truth. 

So I became a very large fan of frameworks, which is basically a playbook blown apart with all its components. What I need is problem-solvers, critical thinking skills from integration experts who can problem-solve their way through the process without drawing outside the lines. 

But I love when people pressure test the framework and ask - why won't this work? Maybe we need to expand the framework as long as we don't break anything material. 

I hate it when people just follow a checklist, which suggests they just have to do one, then two, and then three. I always ask, so what if you don't have to do number five? And the silence is deafening. 

Types of Frameworks?

I use a four-box scenario based on the business plan of records. We ask the business to fill this out early in the process. 

• What are you going to do with the people? 
• What are you going to do with the go-to-market? 
• What are you going to do with infrastructure? 
• What are you going to do with anything else that's left?

The business needs to tell us because it's not in the integration plan, and you need to tell me what you're going to do in these four areas, and it's got a hang off the strategic rationale. So it goes back to the simple statement that says, this is why we're doing this deal. 

They fill in these four boxes, and it has to hang off the strategic rationale and what this solves for us as the acquirer. And it's really easy to see when it doesn't. 

So we take the business plan of record, and then we build our integration plan starting from that using five bullets or less. Just tell me very simply, what do you want to do with the people? What do you want to do with the go-to-market? What do you want to do in R&D? What do you want to do with the back-office?

Maintaining Cadence of Progress of integration.

The simple answer is on communication. Tell me what you're doing, when you're doing it, and if you need help. 

Every team is different. Some teams and projects require weekly check-ins, and sometimes it's biweekly. Rarely it's monthly; that's too much time to go by without understanding where people are. 

It's easy to get a little complacent because of burnout. This isn't easy work. And problem-solving should be a challenge. If it were easy, I wouldn't call it problem-solving. 

If I went to some textbook and got the answer, and that's how I did it, that's pretty good problem-solving. Copy-paste is not overrated. If the success factor already exists, use it. You don't have to come up with something new, but I do think checking in with people to see where they are in the process and listening to how they communicate their work.

I think it becomes pretty obvious for a good manager to recognize if his team is burned out. So now you have to divide. Do I keep pushing them or take our foot off the gas for a little bit? 

I've done this before where I went to the execs and told them we're taking a week away from this project. It's not an easy discussion to have, but we're not going to realize the synergies if the team burns out and leaves. So this is the right thing to do. So 

And that's what my job is running an M&A integration practice in a company. It's not getting into the weeds with the team. If I get sucked into the weeds, I give them permission to get sucked into the weeds. 

My job is to watch, observe, and understand what's going on with the team. And when I say the team, it includes the team that's doing the work on the acquired business side. Because there is a mirror image that I think frequently gets forgotten or ignored. 

And we don't always give them credit for the amount of stress in their life. They're just about to get acquired or have been acquired, and I have no idea what's going on. And most of them were not asked for a vote.

So that's where my job is, to check in with people. See how they're doing, understand the work, but sometimes, getting to know them and their personal lives. Showing them that you care.  

Responsibilities of Integration Lead

To me, I feel like I own everything. I always use the phrase trusted advisor. And when we do a material deal, the CEO, the CFO, the COO, the head of sales, they're all looking to me. 

I have to be a trusted advisor. Do you trust me to drive the right outcome? Yes or no. If not, what do I need to do to gain your trust? And again, that trusted advisor role plays on both sides of the equation. 

I also need the acquired company's executive team, and employee-based, to trust that I'm driving the best possible outcome for them as well.

My job really is to make sure the right outcome is driven and achieved. And sometimes that means going back to the execs of the deal and telling them that the initial assumption was wrong. We should not do that. 

Who owns Change Management?

Everybody. I know that there's a lot of companies that have change management as a function, and I've also tried that in the past. 

But my view is that change management is part of everybody's job. If I have to pull in another team to drive change management, I'm just adding more people and more risk to the process, quite honestly.  

I need my go-to-market lead to be able to explain to the acquired field how their job is changing? How did they get things into our opportunity tracking system? How do they do the actual transaction? How do they follow up on it? Where does that information lie?

Because it will be different from what they did in the past. And so I think it's, I think it's everybody's job. 

Getting your Team Onboard

This will sound simpler than it is because change management is not simple. But having the right people driving the project is crucial. 

For instance, whoever's driving the finance or both for due diligence and integration planning should be able to and be comfortable with, understanding how to do that other job.

They're an accountant typically. So that person should have the experience and be able to explain at a reasonable level of detail what that change means to that team as they come over.

If they can't, then I don't know how bringing in a change management person can help you. That person is not a finance person. 

So that's why it's incumbent on the functional leads to be able to drive that discussion, be comfortable driving that and be confident in driving that discussion. 

Change Management Framework

I actually tend to bristle when people bring change management. It's just part of your job. Don't call it change management. People react viscerally to the term. Don't suggest that it's some big thing that they have to worry about. 

We're just going to tell you how to do your job in our environment based on how you did your job in your former environment. That's really what change management is. 

So like accountant to accountant, finance to finance, customer support to customer support, developer to developer. It's really doesn't need to be any more complicated than that. 

Pressure Testing

When people are struggling, I like to test them and ask them: "If you were to do this, would it break what we're trying to accomplish in terms of what done looks like?"

And it's actually not complicated; it's actually a really simple way to think about it. If one chooses to look at it too detailed, they'll never get to the answer because there'll be in the middle of the problem, not at the beginning of the problem. 

But I ask people all the time, what breaks if you do that? And sometimes they don't know the answer. I don't know what breaks if we do this. 

And the breaking is things like, if we go down this integration plan or this specific workstream, does anything break in terms of the asset in the company that we acquired?

Culture is a really good example of something that can break from one company to another. Go down any workstream and ask if anything breaks if we do this next thing? It's pretty simple, like yes or no. It's binary. There's no sort of. 

So let's limit the self complication for as long as possible. What breaks if we do this? What breaks if we close down these two facilities and move all those employees to our facility, what breaks? 

Employee Experience and Customer Experience

There are two things you have to get right in integration. And it doesn't mean you don't have to get the rest of them right. But if you get these two wrong, the rest of it does not matter. 

You need to drive the right customer experience. Because customers equal revenue, and that's the equation. So what do you do to drive revenue while you engage customers? How are you engaging customers? 

And that only happens after you drive a successful employee experience. Because if your salespeople or employees dont like your process, commission, quotes, technology, or products that you're selling, your revenue gets impacted because they're going to leave. 

Employee experience is not just HR. When I say employee experience, it means: Do they like their new job? Do they know how to be successful in their new job? 

Don't call it change management, call it success. It's not something that you have to study or read in an article. Everybody can talk about success. So what does success look like for you in this job as part of this company? 

You can double click your way from the employee experience pretty quickly and pretty deeply, but you got to start simple. Stay simple as long as possible. 

If you get employee experience right, you're golden because then everything else follows. If you get those two things right, you've got 75 data percent of what you need and to drive a successful integration. 

Relationship Management

In one of my previous deals, the target company didn't ask any questions about the acquisition. When I told them about the integration plan, everyone was quiet. But when I asked them for coffee outside, questions started coming in. 

And because I was building the relationship, they realized that I wasn't someone who was just there to ramrod their company into our company. They got to know me as a person and that I was their trusted advisor. 

They must understand that I am there to drive a successful integration, and I can't do it without them. If they're not on board, I'm not going to get anywhere. And then I suffer, and I'm not doing my job. So that's why I talk about relationships so much. 

Continuous Improvement

You take those learnings via post-mortem: What worked? What didn't work? I think it's that simple. And you can feed that back into the knowledge base.

But it doesn't have to be back into the playbook. We have a SharePoint site where we have all our post-mortems from all our deals where we've done post-mortems, and we don't do them on every deal. 

They're there for people to look at, and they sit there and tell you the summary view of what worked and what didn't work on a specific deal, and hopefully with suggestions of what would be done differently the next time. 

Integration Success

A successful integration is when you have an agreed-upon vision of what done looks like.

And the reason it's got to be an agreed-upon vision is because of things like the legal entity consolidation. They are never done in a year, and sometimes those things take 2 to 5 years because of regulatory issues or tax issues.

If you incorporate that as part of your definition of done, you're going to be working on ideal that entire time, which seems ridiculous to me. 

So again, defining what done looks like, and then having that final meeting with all the business and all the key leadership involved and informing them that you have done everything that was agreed upon. 

That's what a successful integration looks like. 

‍