Integration Strategies in M&A Part 1

Hello M and A Scientists. Are you looking for some new ideas to freshen up your M and A practice or learn practical how to's from leading M and A practitioners? Check out the M and A Science Fall summit coming this November 8th. This is a free online event. Topics cover a range from M and A integration culture and operating model valuations, fair market versus investment value, the role of EQ and tech integrations, developing an investment thesis, retaining talent and more. We do cap the number of free signups so get registered today@mascience.com again that's Masscience.com see you there. I'm Kisam Patel and you're listening to M and A Science where we talk with deal professionals and learn valuable lessons from their experience. This podcast focuses on stories, strategies and what actually happened during M and A deals. Hello M and A Scientists. Welcome to the M and A Science Podcast where we learn from the best in M and A to uncover proven techniques for enterprise value creation. If you're interested in learning more about the products and services we develop to support world class M A teams or want to get involved with our community of forward thinking M and a practitioners, visit mascience.com you can get started by subscribing to our free weekly newsletter for the latest insights and events. Again, that's mascience.com I'm your host, Kisan Patel, CEO and founder of M and A Science. Joining me today is Chris Evans, experienced M and A leader, former head of Corp dev integration at Amazon. And also joining me, Scott Boyd, independent M and A consultant, former head of Corp Dev integration for AWS, and longtime employee of Chris's. He's currently the Deputy Director of Strategy Implementation at the Bill and Melinda Gates Foundation. Today we're going to talk about integration strategies at M and A. Gentlemen, how are we doing today?

Doing great. It's great to be here.

Yeah, doing great. Thanks for having us.

I'm fired up. We are here live in person at the Gates Foundation. Scott, thanks for making that happen.

Absolutely. Thanks for coming.

I got both of you. Yeah, I got this. This is everything I want to possibly learn about M and A integration right here. Can we kick things off with the intro then? Maybe how your paths actually came together.

As you mentioned, I'm the former head of Cooperative Integration at Amazon. Before then I was a tech investment banker and then moved to the US to do an MBA and then joined Amazon in 2005. I was at Amazon for a little over 17 years, 15 of those running dev integration where we closed over a hundred Acquisitions. Then last summer I took a sabbatical and I enjoyed that so much I didn't go back. More recently I've been doing some M and A consulting and some one off independent work for various companies as I miss talking about the shenanigans of M and A integration.

After a misspent youth in the military and teaching English in Japan, I came home to join management consulting companies of Capgemini Consulting and PricewaterhouseCoopers where I quickly found my way into the M and A service offerings there. After a few years in consulting, I applied for a Seattle based tech company called Amazon Early Days, back when they only had about 30,000 employees. Was lucky enough to join Chris's team. Spent 10 years there working my way up through the ranks and learning an awful lot about really the breadth of Amazon's businesses, but also AWS in particular. Very rewarding 10 years. And then for me personally, like many, took a step back, looked at what I was up to in my life and decided to make a change over the pandemic and found my way here to the Gates foundation where I've been for about two years. Obviously Ms. The world of M and A, so do a little work on the side largely helping smaller tech companies stand up an integration function.

A lot of deals you guys worked on. What was the working relationship like? Cause Chris, I know you're an Amazon parent, got aws. What did it look like behind the scenes? Was it completely separated? Did you overlap work together?

I worked directly for Chris. He was the Boss for all 10 years. I'm probably an outlier at Amazon for having the same manager for an entire decade.

Yeah, we worked very closely together all that time and I really saw Scott was a key partner as we were making decisions about the team and our approach to transactions. I mean, so much in M and A is in the gray. Like it's not the black or white. There's no right, wrong answer. And so having somebody just to talk through what was happening with that deal or our approach or something like that was massively helpful to me as we worked through that. I think early on we were just trying to, you know, get deals done and just term sheets would sign. It's like, oh Scott, this one's yours, I'll take this one. We would divide up between the team and we had no control over the inbound of term sheets, which I think is something that is a struggle for many integration teams is that the inbound work is variable but the headcount is fixed. Working with Scott super closely to figure out how we can actually execute on these deals that come along was a lot of fun. And then over time, as AWS became more significant and was very different to the rest of Amazon enterprise sales, such a global business, it just made a lot of sense to have some a team that was dedicated and thinking about the integration strategies and execution for aws. And I was fortunate that Scott leapt into that with two feet and ran that for many years.

Wow. That's how it really evolved. Kind of worked together jointly and then you ended up leading aws.

I think you have to have a certain amount of fungibility in M and A. As Chris pointed out, there's no predictability in where a deal flow is going to occur. So it makes no sense to overly segment a corporate development integration team and have the consumer team going crazy while the AWS team might be twiddling their thumbs or vice versa. I think it's absolutely essential for talent to be mobile across business units, especially at a big company like Amazon. So given that my team would regularly work on projects that my peers would run, it was one big team.

Hey, so you're both here to teach me M and A integration strategies. Let's kick things off with what are the different types of integration strategies.

It really starts with what the business strategy is. And so business strategy drives everything. And then from an integration strategy, I think about it as you have a spectrum of how integrated or not a company should be. And so at one end you have a very standalone business which is going to run very separately with some very specific tie ins which you need to be very careful about. And at the other end you have just fully integrate the company. But again, like most strategies, you end up somewhere in the middle, integrating some things, leaving some standalone. But I think of integration as that spectrum from full integration to standalone business, very much defined by what the deal rationale is and how you're looking to get value out of that transaction.

That's a big variable between full integration and not touch anything.

Yeah, very much so. And even the don't touch anything, you never truly don't touch anything. Over time, we worked on a number of transactions which had a high level of autonomy from Amazon. I don't like the word independence. I think it implies that people can do anything they want at any time. They're still part of the bigger company, but they do have autonomy in a lot of decision making that they have. But there still should be a number of key actions that are integrated, such as business governance and managing the business, information security and a few others. Which are important and even sometimes when you have an acquisition that seems very standalone to the outside world. Amazon acquired Zappos, which was this great company that sold shoes and had this wonderful open culture. And they had a high degree of autonomy from Amazon. But we fully integrated the warehouse, we fully integrated the fulfillment business, which Amazon obviously has a lot of expertise in. But it's being very deliberate where you integrate and where you don't, so you maintain the value in that business.

One common misnomer in the world of acquisition integration is the idea of a governing, all consuming playbook. In a lot of the work that I've done, particularly with sponsors and trying to talk through what our integration approach would be, I think the better metaphor rather than a single universal playbook is really more of a toolbox with a variety of different modules and ways of working that you essentially custom create for the needs of any business rationale for an acquisition. For example, we've made intentional decisions in the past to keep sales teams completely separate. We've made intentional decisions to deeply integrate and try and drive cross selling. It really needs to be true to the business rationale and the situation on the ground. And I think the best thing that a integration function can do is be flexible while at the same time be robust in being practiced, being documented, and when you call the play, show up knowing how to execute.

All right, we want to create a very bespoke strategy based on the business rationale.

Exactly.

This is very different than what I was taught, which is basically there's buckets of what we talked a little bit full integration, partial integration, standalone, then this thing called transformative. Is that such a thing? Do you look at transformative as a different way of thinking through integration?

It's somewhere on that spectrum. That spectrum is fairly all encompassing. Having an integration strategy that's bespoke, as Scott said, is really key because that's where you get the true value out of the transaction. And if you stick to, if you have three archetypes or four archetypes, then you go through that with a company and they're like, Chris, why are you integrating our sales team? Because that's not, doesn't help us. We're not actually adding value that you're actually going to lose revenue. That doesn't seem like a strong decision. And the answer that's because my integration strategy tells me to do that. Because it's integration strategy number four is the wrong answer. It's that flexibility. And sometimes when those business sponsors say, hey, just hey, give me the playbook, my team can execute this. It can't be that difficult. We have a good crew here. We're going to go and run against the playbook. And really that playbook is maybe 10% of the value it's important to have. It is critical to know what the plays are. But the real value comes from having a team that knows when to follow the playbook. Exactly. And then those also when to throw it in the trash and do something totally different. And so that's where integration teams add real value to deals. It's super important to have that flexibility.

Yeah, agree, I would say, and maybe just to illustrate with a couple examples, there's obviously a significant difference between doing a vertical integration where you're rolling up a supplier versus say a growth strategy based integration. So just to maybe double click on a vertical integration, generally the sources of value are going to be threefold. You get the margin that your supplier used to have. So there is going to be some cost savings. You get control. And by that I mean certainty of supply. You're not going to have any other customers cut in line. And then third, and I think the third is often the hardest to tangibly model which is just driving innovation at lower levels in a stack. Being able to work deeply with a former supplier now subsidiary to help drive deeper innovation where there used to be very hard boundaries between a supplier and a consumer. And then on the other end for a growth strategy, you're probably not overly focused on back office synergy, at least any more than you need to in order to enable the salesforce to drive meaningful revenue. The approach really is genuinely different depending on the acquisition rationale. And like I said earlier, I think it's more about being ready to execute on what the right strategy is than it is having one universal approach.

What's easy to integrate.

So I would say easier as every deal has its quirks. I always thought that if I got to the point when I was like okay, we're going to buy this company, this one's going to be easy, that's the day that I should quit because that's when I've lost track with reality. It's no such as easy and everything has quirks, but there is easier. And so I think on that spectrum if you are fully integrating or you are having strong standalone, they are two known ends and they're more specific. People can understand more easily what full integration means. There's less ambiguity. And then what standalone means there is less ambiguity. And the stuff in the middle is where things get more complicated. If you're at One end of the scale or the other. It is easier, but none of them are easy.

And to maybe go a little deeper on one end of the spectrum, certainly there is greater simplicity at say, like what I think is commonly referred to as an aqua hire, where the value really is in the human capital that you're bringing on. When the CEO in particular, which is such an important stakeholder in any transaction, when they are very energized by their product, by the engineering work, by the sheer invention that they're trying to drive, that's an awful lot of a more, let's say amenable stakeholder to the various changes that'll happen in an integration than someone that truly loves being a CEO and loves controlling a full enterprise. That's simply not going to be the case post acquisition. So I think a lot of it comes down to the culture of the team, the makeup of the specific executives, and then of course, just the state and maturity of the business.

All right, you give me a lot of variables. I'm not getting easy answers out of you. I was going to, I was trying to figure out my boundaries here. So I got the easy end, which isn't that easy on the hard end. What is like the extremity of the complexity. What's the hardest thing you've ever had to integrate?

I think the difficulty comes when you're in new markets, new countries, new scale. And over time at Amazon, one of the fun thing was we kept on doing more complex transactions over time. When we first took the role, we were buying relatively small US Based companies. And so we built up a capability around that. And then, and there was, oh, hey, we're going to buy Zappos, you know, okay, that's a very large company that's going to test this in a whole bunch of ways. And we learned that and then say, okay, we're going to do a bunch of E commerce acquisitions in Europe. All right, that sounds fun, let's go and do that. And then with some of the AWS deals with global sales forces, and then you buy Whole Foods, it's those incremental deals which have new things that you've not done before is what drives complexity. And then over time you build up a team or a team at the integration function, a global network of people who understand acquisitions to some extent that can support them from across different businesses. And so as you build that, you, you build the integration competency at the company more broadly. But definitely those incremental transactions really stretched us at the time. But they're also the Fun ones as well.

They really pushed the boundaries, allowed you to challenge yourself and work on more and more complex deals.

Yeah, very much so. At the time, doing acquisitions is a little bit like having children. I remember the positive times. I look back very fondly on many of these transactions, but at the time, they're incredibly challenging. And remembering when told like, okay, we're looking at Whole Foods, okay, how many employees does that have? Oh, it has 88,000 employees. And so it's. Then there's the initial shock, but then there's the fun of, okay, how do we actually make this happen? How do we make this a thing? How do we give 88,000 people a great experience?

That's a lot. Teach me how to do this. I want to get a good understanding. What I'm really curious is when I think of developing the strategy of integration and I'm paralleling this against the timeline of the deal now I want to get a sense of how do I start thinking, what are the things I should be thinking about early in this process? I know you got that perspective that maybe a lot of the heads of corporate development listening don't want to hear. Maybe we can walk through that of like, ideally, what are these points of considerations through the timeline? I don't know if we want to make up a fictitious deal here, but.

It'S never too early. Is I think the shortest answer to start thinking about considerations related to change management. Ultimately, any business that you would acquire is composed of human beings. And those human beings are going to challenge with the change. That will certainly arise in some form or fashion. And I don't know that this needs to be a rigorous process. But I would encourage deal leads, Corp dev professionals responsible for sourcing that are working closely with a business sponsor to start thinking about culture. Even pre letter of intent or term sheet, that sponsor needs to be able to see a world where that acquired team can fit into their organization. And if they struggle to see that, I think that's pretty telling. Early on, as you enter into, let's say, formal due diligence, post letter of intent or post term sheet, I think that's the right time to bring in a change management consultant and expert. Over time, we were able to staff those internally at Amazon. I think largely they aligned with Chris's vision for what the Corp dev integration team should become. But having someone purely focused on what the change will mean across stakeholders, employees, certainly employees, customers for sure, even vendors, depending on what change is likely to unfold. Best practice is absolutely having someone look deeply at what the change to come will be start to think about what sequencing of that change should look like. And that should start to be written up and documented. I would say even before sign or during the sign to close window. If it's a fast process through due diligence and then once you're post day one welcoming these employees to the company, it's time to start setting expectations. People are going to come with a lot of questions. It's not realistic to have answers to every question on day one. But being able to be clear about when you'll come back to them, what the realm of possibilities are, and just being super honest and transparent to the extent you can, I think is super important and is generally well received by newly acquired employees and really humans everywhere. You don't need to tell people the answer they want to hear, but you need to be honest about what changes.

Is likely to unfold from an integration team's involvement. As you lead up to a term sheet signing. A lot of transactions fall by the wayside just before the term sheet and so we would generally get involved when the term sheet signed because then there's a commitment from the company and we're on the clock and then at that point we're running before then. One of the benefits of having business specific integrations such as AWS was that Scott was actually more involved pre term sheet than I think most of us in helping guide and direct integration thoughtfulness like pre term sheet, that's very helpful. A lot of deal folks and other folks around the company didn't really understand the practicalities of what happens post close and what some of the implications of some of the large decisions that people are making upfront. And so having an integration person who understands the business be involved pre term sheet is helpful, but under the understanding that it shouldn't be a huge amount of time because the chance that those transactions come to fruition is likely fairly low. But then once you sign a term sheet, then it's all in. And over time, our integration team took over more and more of due diligence. And so I think it's general best practice that the integration team should be involved during the due diligence process and then run post close or post sign. But we took it one step further that we ran due diligence like we ran the process of the transaction overall in very tight coordination with the transaction lead, but we ran diligence. We understood the companies super deeply, which enabled us to make good integration decisions. Going that level deeper made us a much better team where we could Drive and understand first and build relationships early on so then we could hit the ground running faster when we got to sign and close and actually working closely with the company.

Yeah, just to pile onto that, I would also offer that just being cognizant of the general profiles that gravitate towards say a corp dev negotiation and sourcing role versus an integration role. The types of people who take integration roles naturally have a lot more cross functional leadership built into that makeup. So at least at Amazon it was a great way through the due diligence process for us to work very closely with our various cross functional leads from every corporate function and product and engineering function that you could think of. And being able to work with those teams throughout the due diligence process builds a certain level of familiarity that will absolutely pay huge dividends throughout the integration lifecycle.

Can you give me some examples these benefits you get running the diligence? This isn't a common practice. I hear of it occasionally that there are more mature integration teams that end up running diligence. And we have this whole agile M and A framework where you preach a lot about continuity between diligence, integration and what better way to create the continuity than have the same team run both.

You have direct and active engagement with the business sponsor, with the CEO of the company, with the senior leadership of the company. And you have to execute. Execution is obviously critical. So you have to execute incredibly well. And through that due diligence process, you gain the trust of those key parties such that they then have more trust. When you're trying to roll out a bunch of change, a bunch of scary change or change that concerns them, they already understand, they already know you a little bit, you've earned that trust with them to make that go hopefully a bunch easier. And so I think that stakeholder management is incredibly important. And then there's also just deeply understanding the company. We focus on our team who just became scarily familiar and had such a deep understanding of some of the companies we acquired. It was amazing, you know, what they garnered through due diligence and it's a more active role. Early on when I was involved in due diligence, I would have a passive role, which I think is a different mindset. But when you're actually leading it and running it, it's active. You're in the weeds. You truly want to understand all of the details because you are responsible for it. And I think then if you deeply understand the business, then you make better integration decisions through the lifecycle of a transaction. The transaction leads or the people that are running strategy, they've been in partnership with business sponsors for months or years. They've known these CEOs on and off for years. Hopefully they already have a really strong relationship through that due diligence process. There's a transfer of trust from that deal lead to the integration lead, because come close, that deal lead is going to move on to the next transaction and be chasing various other deals. And so you enable that transition to be a lot smoother rather than a transaction lead running due diligence and then getting to sign and being like, all right, guys, I'm out here, let me introduce you to your integration lead. I think that's a much poorer experience for those big stakeholders that are involved.

There's a few things that I would tease out in particular that I think are huge benefits. In particular, one of the biggest I would offer is due diligence is exhausting. And being able to have the integration team participate, lead and manage the due diligence process just removes so much redundancy that would occur otherwise shortly post close. Saving to be acquired or target executive teams from having to tell professionals from the acquirer everything under the sun about their business, first for informing a transaction decision and then informing an integration approach, I think is very frustrating and is something that we absolutely want to spare target leadership from going through. And I think it's so important for newly acquired executives to have a positive first taste of working with their new parent company. Having to repeat yourself on everything that you said during due diligence, I think is a pretty excruciating way to start that new relationship. I would also offer there's a real opportunity by having integration professionals run due diligence. And certainly there's the relationship building aspect, but it's also an incredible opportunity to build a reputation with that target management team as someone who can get things done, someone who knows the company inside and out, someone who can get on the phone at a moment's notice and help a CEO or whoever's replying to the thousand line due diligence sheet on how they should prioritize. Yes, it's okay to say not applicable to some of these questions, and generally be an advisor and really a Sherpa through the transaction life cycle to help newly acquired teams through that process.

All right, here's my business case for why the integration team should run diligence, engage with the leaders earlier, build trust, be positioned for better execution, position to drive change, a better ability to learn the company that you can ultimately make better integration decisions, have a Smoother transition into integration and ultimately reduce a ton of redundancy and headaches and create a better incoming experience for that target company.

I think that's right. I also think it is natural for to be acquired executive teams to know how things are going to be post close. There's no one better positioned to answer those questions than the integration lead.

Great points. I think that a big case there encourage more companies to take that approach.

Some people have asked me about that before. Oh, Chris, how did you take over due diligence? It wasn't from one day to the next. It was a process over several years where we would lean in more heavily. There was maybe there was a new deal lead that was coming in. It was, hey, this is my first deal at Amazon. Can you guys lean in a little bit more on diligence? Yeah, absolutely. And then we did that very deliberately and then we wrote down what we did and so that other people on the team could learn from that. We just built a reputation within Corp dev I think of being good leaders of due diligence and it took several years to do that, but it wasn't overnight. I think turning up and being and saying, hey, I want integration to run due diligence is not the best approach. It took years and it took a lot of very strong execution through those transactions to build us to that position. And then it just became, of course integration is going to run this due diligence process. Who else is going to do it? Who else is going to take that role? And it just became the way it got done.

Is there anything that you do differently than the deal team was doing prior in running diligence? And we got a lot of good benefits, but in terms of I actually did it.

Deal leads would typically use their own approach and so there was more variability between the approaches. The deal leads were very experienced. They'd done deals at other companies. They had been private equity and venture capital like very seasoned deal folks. But there wasn't a consistent approach to how to do deals within Amazon early on. And each one was fine on its own. But then you have this broad cross functional team who's working on every transaction, who has to think, oh, okay, today I'm working with Bob on this transaction and tomorrow it's Kevin on this transaction and I have to think differently. And so the broader cross functional team very much appreciated the increasing consistent approach over time. And it also enabled the people running the deal or the deal leads running the transaction to be more focused on some of the issues that cropped up in Due diligence and addressing those in negotiating the share purchase agreements, in working through the valuations like deeply understanding financial models gave them more time to do the work which they are truly expert at by us taking some of that due diligence burden as well.

I completely agree and I mentioned it earlier, but I would retouch on integration almost by definition is inherently cross functional and so is due diligence. I think it makes a ton more sense to take the integration person with a highly relevant skillset to managing that cross functional team and running due diligence in a far more efficient structured way which only as we talked about earlier, helps reinforce the relationships both on the target side but also internally. I remember any time of day or night getting on the phone with my HR M and a integration partner through due diligence processes, talking through various issues that would crop up and not so much because they were a risk to the deal per se, which is appropriately what a corp dev negotiation lead would use as their filter. But integration folks, both cross functionally and central corp dev players intuitively understand from experience what the consequences and dominoes are going to be throughout the life of an integration and really the life of owning that company based on decisions, commitments and statements are made pre acquisition sign integration leaders very much are promise keepers, not just promise makers. So having those promise keepers in the room early on I view as entirely essential.

Great points. Reality check here is most of the companies I encounter are much much earlier. They're not operating at Amazon scale here. They're maybe occasional acquirers doing zero to one deals that are starting to become that frequent acquire doing consistent two deals and that's when they're starting to put together a dedicated M and A team. Given that scenario, how would you, given all this lessons learned from 100 plus deals, position your approach in terms of how you would start structuring that M and A function to be able to execute. Given some of the things that we just talked about.

There's critical milestones in an M and A transaction and thinking about how you want to approach a milestone, whether that's we had consistent documentation for the kickoff. Okay, we sign a term sheet. What do you do now? And so we had consistency around around the kickoff, we had consistency on the approach to due diligence, a standard due diligence list and there's many M and A lawyers that can provide incredibly strong M and a due diligence list which then you can layer on the business specific areas. And then what does diligence write up mean? What does it mean to complete diligence, what do you want to share with senior management about that? And then how do you make the decision to actually acquire the company or not when you get to the point of signing the transaction and committing the company to the transaction. And I think building some consistency around those key milestones is essential and then that gives the team those goalposts to meet and working with them closely to do that on a consistent basis, I think is a great place to start.

I think it's important to acknowledge and be honest that integration work is a full time role. One of the biggest cautionary tales that I've encountered in working with some smaller companies is trying to make integration a 10 to 20% tax across every functional team, across the business sponsor as well as the newly acquired company that's very much still running their business day to day, ensuring that those costs are incorporated into the deal model are understood and weighed in that decision making that Chris is discussing I think is super important and really can't be understated in terms of completely acknowledging that maturing companies that are going from zero to one. It just does not make sense to hire a tenured, multi year experienced integration professional. It's such a niche role. I would say that having a dedicated project or program manager that not just has the, let's say organizational backbone of a project manager, but also is respected within the organization and is a project leader as well as a project manager that other folks at the company will look to as a legitimate leader, driving change is absolutely essential. And where I would start as I was looking to close an acquisition stand up an integration leader, whether it be the first time or early dozen, half dozen acquisitions at a company and trying to build experience within regular players across the cross functional team would be where I would start. One thing that we did at Amazon that was very early days and that I've seen a number of other smaller companies do, is start to bucket the M and A integration roles, whether they be functional or central in say a strategic projects team that actually has some variability built into their model. A lot of times I think M and A teams can be grouped with global expansion. There's a lot of commonality between some of what you'd encounter in entering into a new region or a new country. That can be a parallel, not a perfect parallel, but there's some similarities with the types of issues that you encounter. That's another good way to start to centralize and drive consistency of the integration experience while growing a company that can't justify fully dedicated corp dev Headcount.

Dedicated headcount evolves over time. When I took the role initially it was just me. Thankfully there was also an HR M&A person who was dedicated to that job who also managed some other projects. But there was somebody in hr, there was somebody in legal, there was somebody in Tax and somebody in accounting. I was very fortunate to have those four people in place that were working through as the kind of two deals a year we were working on. You had a consistent team even at that point, and then it's being deliberate about which other teams do you add on over time? And in the end, you know, you skip forward 15 years and you had 16 cross functional teams with dedicated people. You know, some of them were still one person, but most of them were larger teams over time, incrementally building out. And as integration leaders, as leaders of the integration central integration team, I felt that we were deeply responsible for that cross functional team as well. I felt strongly that I was responsible for their success or I wanted them to be successful and do things to set them up for that. When keeping an eye out for those folks, like understanding which teams were struggling, how I could help them make the case for incremental headcount with their senior leaders in Corp Dev has a strong voice in a lot of companies and did within Amazon. And if Corp Dev was going in with them to say yes, I think this is time to add dedicated headcount or bring on some consulting resources or do something else. I, I really try to look out for those teams and work with them to build them out over time. And incrementally you end up with 16. But it took a lot of patience and education of leaders within those teams and being scrappy and thoughtful around what things or what areas would they work on if there wasn't deals to be around? Global expansion's a great example, but being thoughtful around, that's incredibly helpful. And over time you build an M and a community within the organization that just makes deals better, makes the chance of success of deals increase as you build that community up across the company.

We have a few different themes here. We had developing consistency through the process around the key milestones, defining this program manager, the central change leader and making that clear who that is. Then also your roadmap around the headcount, as your M and A function matures, strategy evolves and so forth. In the process piece we already talked about this a little bit, right? M and A is a pretty big variable. Deal by deal. How do you strike that balance between creating a process for consistency but also enabling the agility that you need to drive the success on these deals over time.

You put in these sort of bigger documents or milestones and people would talk about a playbook and like, we don't really have a playbook. We're not that team. And I don't want to be a team that has a playbook where somebody pulls it off the shelf and starts at the top and works their way through it. It was challenging to build a process that had consistency, but flexibility was always the challenge. And adding additional milestones or steps in a process that actually help people rather than just become incremental burden for folks. And so it's very conscious that the team's very on a deal. There's a lot of things happening. Me adding incremental administrative function on the team, I need to do that in a way that helps people rather than just benefits me or just benefits other people around the company. It's that balance of adding incremental steps and consistency, but also ensuring that people are aware that it's very flexible. And I think there's good starting places to come from. As many a very large consulting company who has playbooks, you can come across the basic playbooks which I think enable people to. People don't know what they don't know going into an acquisition. If you're going from that zero to one. And so having a playbook just gives you a little bit of that confidence that you're not missing anything big or crazy that you can always be back of. Oh, okay, let's have a little look on the list. Was it there? Did we cover this? Is that okay? It's a nice backstop and it's a nice risk mitigation function. But then building up something that's more flexible over time is actually more important.

One thing that I've done in the past is, and this is true for both working with sponsors as well as newly acquired leaders. I think it's very important to be crystal clear on what you believe the integration end state will be, both from a business perspective as well as a cross functional perspective. And then I think it's important to be very flexible in how you get there and very cognizant what's happening in the business both on the target side as well as on the sponsoring side. For instance, there's a lot of companies that over time will require all companies to get on their financial systems for a variety of reasons. That doesn't mean it needs to happen in the first six months. It's important to take stock of what's happening at the newly acquired company. If they have a very important launch that's all hands on deck, 90 days post close, then that financial integration is not going to start in those first 90 days. I think it's very important to be receptive and to be open to adjusting your integration approach both from a timeline as well as a, say, process or who's even responsible for leading the project. I've had great success in tapping into as a result of the acquisition, underutilized target employees that are eager to be involved, that are eager to learn more, and are likely auditioning for future roles at Amazon in that case, and having them lead change efforts and integration efforts is a great way for them to both learn about Amazon and for there to be a very authentic, self driven change at the newly acquired company. So I would absolutely say be clear, be honest about what change needs to occur and then be incredibly flexible in how you get there.

I think it's very fair and it's an example. The CFO at a company goes through the acquisition, probably is a very central figure in due diligence, has worked incredibly hard through the transaction. And then you get to close and if you have just a bunch of individual playbooks, you'll have the treasury team saying, oh, we need to move all of your bank accounts to our bank, you need to redo all of your insurance and an accounting site, we can need month close, we need tax site, we need this, that the other. And on an individual basis. They're all appropriate things to do, but they don't naturally talk to each other unless essentially integration team is being thoughtful around what truly do we need to do? When do we need to do the bank accounts now or what would be the risk if we push that off for three months? If we got visibility, let's get visibility into the accounts today, but let's do that in three months time. Being very thoughtful and staged about what to integrate and when to do it is an important function of the integration team as somebody who looks across that broad cross functional team and something that a CFO or someone in that role is incredibly appreciative of, that somebody's coming in and telling Amazon no, or any company no. Because an acquired company finds it hard to say no, because they want to be good corporate citizens. Most people are oftentimes very happy to be acquired. They want to show well in front of their new peers and their new bosses and so they struggle to say no. And that is a very strong role of the integration team to come in there and be like, actually let me go and take care of that for you, or let's have a thought about how we should balance this out.

Sounds like it's part of the culture that you have to develop of how you execute M and A. Can we go back pre loi, talk to the deal folks out here? Because a couple of things we touched on a little bit was the culture and there's a sense of that pre loi but also this end state that you referred to, I wanted to get a sense of pre loi what are the things that we should be doing to really understand the culture of this organization, the considerations around it? Are we looking for big red flags to know that this is a deal we shouldn't do? And then I guess lending into the end state as well, like how much of that should be really defined? This is where I get really confused on this stuff because there is a lot that goes into how you integrate, obviously depending on the strategy for buying some technical capability. And we're planning to integrate into a platform. But then we get loi happy and we just put offers out there to get the deal going. Where do you actually strike that balance? Like how much of that needs to be defined and really factored in to get to that signed loi?

This is where your business sponsor is probably the best, the best judge of how well a newly acquired target is going to fit into their organization. I do think, and this goes back to Chris's point related to there's an incredible amount of volume pre loi versus the number of transactions that get through an loi. Like it absolutely has to be process light. I wouldn't necessarily recommend a ton of documentation because I think that's a pretty quick way for it to never get used. But I do think being highly intentional with your sponsor, can you see yourself managing this team? How do you think it'll be to manage that? CEO in particular are super important questions for the sponsor to opine on and be very confident that there is a positive path forward with that organization. In the acquiring organization.

I guess we need to separate the culture piece and the considerations around the integration itself. Culture piece sounds like a big upfront. Is this leadership team, those interactions you're having, are you going to get along with them? Are there other components that you'd want to dig into? Obviously there's like data online, the Glassdoor and things like that. But is that really material?

Glassdoor is incredibly helpful, but in that early interaction it is primarily with a very small number of that leadership team. And so you have to come to conclusions based on those interactions. And there's also how people talk about their culture. Lots of people will claim a certain culture or will write down a certain culture and then act in different ways. It's understanding what the company's take on their own culture is, ensuring that they're acting following those guidelines that they've set themselves and then separately thinking where does that align to the acquiring company, where could there be clashes and how might that play out? Because every company does run differently and there will be pros and cons as that works through. That's important in the free loi. Like having a true deal rationale, like what is the true value, what are the high level goals of this transaction are important and having a strong opinion about why you're buying it and where the value is. And then also being upfront and being like we don't know that much today. Here's a bunch of things we're going to dig into in diligence or you go to leadership and say we're looking to sign this term sheet, here's our opinions today, here's our risk, this is what we don't know, this is where we're going to focus our due diligence efforts on or we're going to dive deeply into this and we'll come back to you on this. Being upfront, honest about that can be very helpful in getting buy in and just building that momentum through the transaction.

Outside of culture, one of the biggest things to be mindful of is expected changes to a target company's operating model. Thinking back on my time supporting aws, obviously one of the leading cloud providers in the world, we would at times acquire companies that had on premises offerings, whether it be physical hardware, whether it be downloadable software, completely and totally orthogonal to the AWS business model. Huge challenge from an integration perspective. Challenge for the employee base and really thinking through what the magnitude of changes to that operating model will be, I think are important to wrap your head around early on and to ensure that you could see that organization, that executive team making it through that kind of change. And that's the sort of thing that I would encourage both deal leaders and sponsors to really think hard about early on. Building on what Chris said, I think it's less of a what's the right thing to do and more what to steer clear of. And I think the most important thing to steer clear of is just making open ended promises. I think this is where discussion of independence, which is by definition very ill defined and I think means whatever the Listener wants to hear can be very dangerous and can end up being a multi year pain.

We're still a pre loi to Yep. Start defining these expected changes to the operating model.

To be clear, I don't think that there is no impetus to communicate those things early on. Rather, I think it's important for the sponsor to start thinking them through. Rather, it's the other side of the coin which is don't make promises that you're not sure you can keep.

Got it. Thinking about this free loi we look at the business unit leader and working with them. There's a big variance of M and A experience coming from those leaders. How does that toggle things around when you're working on a deal if you have an inexperienced BU leader?

I think it's typical. That's the case. There was a handful of times where we had repeat business sponsors. That's obviously great to have repeat business sponsors but the typical is that a person is going through that for the first time or going through it for the first time with Amazon. Every company approaches M and A slightly differently. It's educating that person on the way deals are done at that organization is super critical and it's key just to lean in. As Scott mentioned earlier, the business sponsor is such a critical person in the life span of that transaction. That person is going to own and live with this deal for many years into the future. And so it was our role to set that person up to be successful. We would do anything we could to help that person through that. The first thing we would do is sit down with that person and be like, okay, great, you sign a term sheet. This is now what this looks like for the next six weeks or three months or six months. Here's what you need to expect. And it wasn't just here's the process. That doesn't sound that much fun, but it was. Here's the questions you should be able to answer at different stages of this process. At a certain point, what's your view of the management team as individuals? And a wide variety of questions. We would have them be thoughtful of and we would provide them with a document. And the appendix had a consolidation of all of these questions in one page. And sometimes we go and talk to the sponsor a few weeks later and sometimes you saw that page ripped off the back and pinned up on the wall. That's when I knew we had success. That's when that person was taking this seriously and was very involved and was going to make the time and be a great person to work with and was thinking about this in the way that we were hoping they were going to think about that.

I would completely agree and I would even offer some of my most positive experiences with sponsors was actually first timers. It's more important to approach an M and A scenario with genuine curiosity and to intentionally make time for it rather than just trying to squeeze it in is so critical. On the other side of that coin, some of my more challenging experiences was working with sponsors who had done maybe one or two deals and had formed very rigid ideas about how it's going to unfold. Not really thinking through that. Those experiences were based on the nuances of those earlier transactions and not necessarily representative of how everything's going to go.

Re Loi what are the most important questions I should be asking? Observations I should be looking for.

So as a business sponsor, as integration.

Leader, teaching the deal guys how to.

Do deals Clarity of Vision Many businesses face challenges in growth, in getting resources. In many respects people can go down the wrong road to make an acquisition buy a large company. If I buy this company, it's going to solve my problem here and I'm going to have less headaches in that area of my business tomorrow. People think buying a company might, you know, that that will run itself for a while. I don't need to worry about that part of the business so much versus the reality which is you buy any company as a leader, you're going to spend 30 plus percent of your time on that with that company or with that part of your business for an extended period of time. It is why are people making the acquisition and is that going to play out in reality in the positive way they think that is the case? That's step one to me because as we work through many deals, we have many lessons learned, we have many scars, we've made many mistakes. Helping others learn from our litany of mistakes and litany of lessons learned versus the oh, I did one deal last year on the last deal I did, I did this thing. We'll just do that again. So it's like that clarity of vision and then how practical and pragmatic that is and will people get the value out of it with that vision in.

Place post close, what does that vision entail? Is that also including like this whole go to market chain as you start.

To get more granular. One thing that worked really well when I took the role focused on AWS and I think as Chris alluded to and having a relationship with the negotiating leads, it's really about being a resource to them that they feel confident that they can call in integration support anytime. One area in particular where I have regularly found integration folks to be more deeply aware is the absolute must haves cannot negotiate within the parent company. So I'll give you an example. Multiple times negotiation leads from corp dev focused on AWS acquisitions would come to me and ask is this possible? Is this something that our sales team would be willing to support? Is this something we can get over from a security perspective? How do you think about entering this new country for this acquisition? And those sorts of highly bespoke questions are exactly where an integration leader can add real value pre loi in simply being able to share with the deal leads. Actually, at that revenue number, the AWS sales organization isn't going to support that or isn't going to go beyond what their normal playbook would imply. No, we probably can't get over that from a security perspective. These are the sorts of things that we've done in the past and this is what it might mean for that business. Understanding those things early on is absolutely essential to understanding what the probability of success from that acquisition would be. It's less about having universal set of questions and more about being a resource to those corp dev professionals, having that strong relationship and being able to on demand bring that integration experience to bear as new issues are encountered.

Pre loi, there's more about the curiosity for you to understand clarity of the vision, the deal rationale. Yeah, I guess that goes the same with culture to just asking them how they do things, make decisions.

I think culture is tricky. You learn a lot about culture during due diligence. Culture is pretty high level pre loi and again just that the interactions with the folks and how they react in certain situations and how they make decisions. But as you engage with a much broader team in due diligence and actually go in and do cultural due diligence and have a change manager be in there and being thoughtful and deliberate about that. But I think pre loi it's relatively high level.

All right, that's the first part of a discussion with Chris and Scott. A lot around integration strategies and approaches. The second half we talk a lot more around the change management specifically. Look for part two Till 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 a science.com or you can text me directly at 312-857-3711. If you just want to keep learning at your own pace, visit mascience.com for a lot more content and resources. That's where you can also subscribe to our newsletter. Again, that's mascience.com here's to the deal. Views and opinions expressed on M and A Science reflect only those individuals and do not reflect the views of any company or entity mentioned or affiliated with any individual. This podcast is purely educational and is not intended to serve as a basis for any investment or financial decisions.