Mastering Serial Acquisitions

Hey M and A scientists. We all know that tracking progress in M and A is crucial. But let's be honest, manually creating reports is a time consuming headache. Nobody wants to spend 10 to 15 hours a week dumping data into Excel and crafting PowerPoint slides. That's where Dealroom BI comes in. Dealroom BI automates all your M and A reporting completely. We're talking about pipeline reports showing where every deal is at, what stage they're in, and timelines. Need a full diligence readout? Done. Want to track integration progress against milestones and synergies? Dealroom BI has you covered. You can even schedule these reports to be emailed out automatically on a weekly basis. Imagine reclaiming all that time you spend on manual reporting. Put that analyst back on sourcing the next big deal and let Deal Room BI handle the rest. If you're tired of wasting time and want to streamline your M and A process, check. Check out Dealroom VI. Visit dealroom.net to learn more. Trust me, it's going to save you a lot of time and headaches. Here's to the deal. I'm Kisam Patel and you're listening to M and A Science, where we talk with deal professionals and learn valuable lessons from their experience. This podcast focuses on stories, strategies and what actually happened during M and A deals.

Foreign.

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 to learn more about how to optimize your M and A practice or want to get involved with our community of fourth income and a practitioners, visit mascience.com subscribe to our free weekly newsletter. Otherwise, social media is where it's at. Head over to LinkedIn, follow M&A Science myself. Keep up with the latest. I'm your host Kisan Patel, founder and CEO of Deal Room and Chief Scientist at M and A Science. Joining me today is Gwen Pope and Tracy Smith, both veteran in house M and A practitioners from the large enterprise corporate arena and Big four consulting. They've worked together in several settings including Google and Maersk, and now collaborating to launch a boutique services offering that draws on this experience. Today we're going to talk about mastering serial acquisitions by taking a programmatic approach to strategy and execution, including bridging, inorganic and organic planning. How are you guys doing today?

Awesome. It's awesome to see you. And by the way, this is it's especially interesting to talk today, Kisan, because as maybe some of your listeners are aware, we had a conversation or two some years back and we first met or connected when I was at Google through some mutual colleagues and it's really interesting to check in down the road and some years later and share how our thoughts have progressed and just evolving perspectives, trends, et cetera. So I'm excited to dig into the conversation for that reason alone, but also to hear some of your feedback and commentary on what we're bringing to the table to discuss today. This would be great.

Likewise. I feel like I'm getting better at this over the years too. So those of you for reference, Gwen has been on the podcast before. We'll maybe throw a link in the show notes but look for that Tracy, welcome to M Science.

Thank you. Yeah, brand new to podcast, little nervous, not going to lie, but we'll get through it should be fun. I'm excited, excited to talk about what we're going to go over today. So that makes it a little less intimidating when you know the topic.

Well, let's jump into it. Let's kick off with a little bit about your background.

I'll just say that at this point in my career path, M and a generalist seems to be the best way to describe myself. Short and sweet, but to provide a little bit more color than that, I will say that I started out in a career path that was really highly technical. If you go back enough years or decades, you'd see me with my sleeves rolled up and doing software engineering, enterprise application integration focused on middleware architecture, service oriented architectures and back before everything was so cloud focused I was really working with a lot of web, native and hybrid environments. The forefront of that move to cloud and then ended up working with companies like Oracle and Apple, focused on solution architecture and veered into M and A work somewhere along the line and I've built and led a number of M and A functions, tech product platform go to market sort of around the table. Companies like Microsoft and Google, ebay, Maersk create greenfield models within brownfields if you will in and then take away from that what seems to work, what doesn't and created a lot of frameworks over the years and taken learnings from that. That brings us to today and I'll pass over to Tracy Gwynne.

You have definitely taught me a few things along the way. My career path didn't start off in tech, anything tech actually. I was a litigation paralegal for a number of years, about 14 years and then went to work for Oracle in their contracting group and then somehow became a negotiator negotiating contracts and Then Oracle started acquiring at a rapid rate back in 2009. I sort of landed in the deep end of M and A by accident, then couldn't swim my way out of it. So here I am. And I love it. A lot of people question sanity when you say you love M and A, I think. But I love the fact that you get to solve something on a regular basis and really get into into the day to day operations of new companies. It's exciting. Your day is never the same and then yet you're trying to create repeatable processes. So how do you do that in such a crazy world? But I would say indefinitely a generalist at this point. I don't think I have any one particular space that I'm better at. You just pick up pieces as you go and move along. So that's me.

Both have very interesting backgrounds. The fact that you didn't take a traditional finance banking ended up here coming from operation and law backgrounds. And I'm really excited to have the conversation. You've both worked with large strategic acquirers. What do you see as the most common challenges for large acquirer like the Microsoft, Cisco and Googles of the world that they face, particularly in the integration process?

I'll start off with maybe a super obvious point, but there are some nuances around the implications to this point, which is inherently a serial acquirer is of course they're transacting an ongoing flow of deals, whether it's an acquisition or a divest or something in between that then you have this both accumulation of deal projects that you've just transacted and at various stages of planning or integration. Also you have this anticipation of future deals and that all of that represents one of the strategic levers that you're pulling to execute on your corporate roadmap. That's the basic assumption. So the implication of that of course is that you have a number of plates to spin and they're all spinning at various phases of what they're going to do. The key challenge that serial acquirers face and that I honestly haven't seen supported well either in planning or execution, is to make sure you have an awareness and really a fundamental understanding of what part does that one particular deal play in the bigger picture and from a change impact perspective, what would happen to the deal thesis or maybe even the indicated integration strategy or guardrails if one of the other pieces changed or vice versa. So really the interconnectedness of the transactions is a key piece to what serial acquirers face. That acquirers that wouldn't be Categorized as such would face. And then another thing of course is that you need to consider the ongoing resource needs and prioritization definition of roles. So you actually have an operating model, whether or not it's super lean and you only have a few dedicated resources and a bunch of what a lot of us will lovingly refer to as the volunteer fire department model or MA functions that don't really have dedicated resources. So it's really making sure that you have the strategy piece, that awareness of the bigger roadmap, the resource model, at least a minimum viable one, defined that readiness to repeatedly execute. And then ideally, of course you need the framework, need to have a way to repeatedly operate and a strategy, a philosophy around how do you do deals. But that's really boiling it down to just basic building blocks and. Tracy, did I forget anything?

No, I don't think so. But it really is the building blocks that you need to picture it. If you need an image is building a path to integration is really what serial acquirers need to keep in mind and have an approach for as they move forward.

What I picked up was the complexity really comes from having these deals at different stages of the deal life cycle and how each deal correlates to the big picture. Also the interconnectedness of these deals because they're all going to the same company and they're going to have their own different impact. And then also the resource model, are you prioritizing the resource? How's this going to evolve? Changes in the overall operating model?

Yeah, that covers the basics and again it's just inherent and an obvious point. But the fact that you are going to repeat and you already have executed on multiple deals, it begs a repeatable approach and a readiness from a resource and strategy perspective. And again, to avoid the narrow short sighted thinking to say here's this specific deal and its specific thesis and objectives and it is the most awesome deal ever. And we're so excited about this bright shiny object. And we're not looking at the rest of what's going on with the corporate roadmap, whether it's inorganic or organic related initiative, when there's unavoidably connectedness, super important.

How do you do it? The typical private equity playbook. You build 100 day plan and you go execute on it. You just added a bunch of complexities with the whole nature of doing deals in a series. So now we need to figure out how to manage the short term needs and then also align with long term objectives. Fill it out. What's the secret sauce?

So it's probably helpful for your audience and maybe even just our thinking and walking through this conversation. To start simple and then build from there. The secret sauce is really in having the awareness and ambition that as a serial acquirer you do need a repeatable model. That's step one. The fact that is a need and that it merits the prioritization of resource and focus in order to stand up a minimum viable model and then iterate from there to not lose sight of that importance, that priority at an executive leadership level. And there I'll note that a number of roles I've been in, a number of companies I work for, there were vastly varying degrees of understanding and then commitment with consistency at the executive leadership level. What that does is either it maintains the foundation for having a repeatable model that's actually viable, or it keeps you in a very reactive mode. Back to the point about focusing on executing just on a per deal basis being reactive and you're not very cost efficient that way. You're not mitigating against the potential of other factors in the roadmap or maybe even external market factors prompting the need to pivot or course adjust. You're not ready for any of that if you're just in a reactive mode. So really it's having that awareness and then commitment to establish the model and then of course following through with the things like defining a cross functional raci so that you understand who's doing what and defining how do we execute the deals, who is responsible for creating and iterating on the playbooks per function. Also working with again, back to the elt, working with the ELT intently on an ongoing basis for education. So they know what to expect from the M and A practitioners and functional leaders and they know what's needed from them as well as far as setting clear direction and articulating and explaining corporate priorities and foundation of the strategic roadmap, et cetera, and how that needs to guide deals.

I mean, if we're talking about secret sauce, and we typically understand that executive leadership is sometimes looking at an entirely different part of the universe, that it needs to be brought out of a black hole. I guess, if you want to look at it from that perspective. But Gwen, you hit on the education piece that really is the secret sauce when it comes to acquiring companies. If your executive leadership really takes the understanding that they need to understand what it takes to bring a company and integrate it into their go to market plan, then you win. It's a huge win. They think they know and it's no slight on executive Leadership, they have different priorities but they also have to bring their thought process down a little bit to the operational side to really understand what it takes to get to an integration. That's the only thing I would add. Education is a huge piece and it's ongoing throughout the process. It's not just like a one and done because as you get to different phases there's different levels of information that need to be talked about, discussed, decided on.

Yeah, this reminded me of something too and actually I won't name names but from one of the companies that, that we worked together at. But it really shone a bright light on the need for humility as an M and A leader, M and a practitioner in working with the executive team. There's always this, even in the best of stakeholder landscapes, there's always this tension of oh, if we only could get. Just fill in the blank with the title. We could only get that stakeholder to understand or to appreciate what we do or to respond or support in some way that the M and A leadership community needs internally. But you need to also bring humility to the table and seek to understand what the objectives and what matters to the executive team and translate what your objectives and needs are into their terms. So relatively straightforward exercise, but it's often challenging. And what I mean by that as an example is try to avoid just talking about in terms of MA deliverables and MA methodology. The leadership team is not necessarily going to understand or care about the fact that you're working towards let's say a day 100 milestone or that there are certain deliverables that are required for let's say a pre signed deal review milestone. They are going to care if something is going to delay or prevent let's say the joint sales teams post close from going to market with cross selling and bundling acquired products with your products and getting it to market in a region that's a wholly new customer base for you. They're going to care about that. So it's just an exercise in interpreting what your objectives are in terms of what their priorities and commitments are. And of course okrs, what are their butts on the line for? It's an important point.

So step one is admit you have a problem. Actually I like awareness and ambition. Like have awareness and ambition that you need a repeatable model and then from there just getting something started, have an mvp, be able to iterate on that model. Having leadership commitment to this is going to be important. You mentioned Raci, which folks that don't know you can google it Raci, what does it stand for? Do you remember?

Responsible, Accountable, Consulted and Informed. So it's just defining that there are different ways in which stakeholders are either contributing or just need to be aware. Regardless of how you delineate the roles or define them, the point is who's going to do what and who just needs to be aware that something is going on.

Yeah. So it kind of lays out who's doing what. And then the other thing you mentioned is defining the how as part of taking this approach. And then we dug into the elt, which stands for Executive Leadership Team for Education. Your definition of education is making sure there's a clear direction and helping them know. Because this happens sometimes people get a little chip on their shoulders and things can be easier said than done. Giving them an understanding of. Well, you mentioned Tracy, like helping them with a thought process that's in the operations and then you flipped it around and saying there's also a perspective of just seeking to understand what those executive leadership team care about.

Yeah, absolutely. Because at the end of the day, M and A is just one of the strategic levers at the executive leadership team's disposal. And we all know very well that there's specifics, there's nuances that are particular to M and A work that you're not going to find in the organic initiatives and scope and execution. But it's crucial to make sure that you don't lose sight of the fact that it is just one of the strategic options and that at the end of the day you need to keep an eye on what is the set of corporate objectives? What does the strategic roadmap look like? Because the M and A is just the how. That's where you're deciding, okay, we're going to execute like this as opposed to building in house or what have you.

Why does most people in integration tell me that it's the long tail of doing integration that makes it. I get like fatigue that what is it? I think that's why they came up with 90 day, 100 day plan, because people are just going to check out after that. I want to hear from you, donut.

The day 1 to 100 segment of deal projects. That does deserve a quick double click. And I'll pass it back to Tracy in a moment because there are some helpful examples that we could illustrate around that. Around the day one to 100 peculiarities and challenges. The longer tail. Yes, it's about fatigue and a lot of the, as we know, the resources that are engaged and accountable for executing on a deal project. Post close, a lot of those same resources have been involved since some point of diligence. So for them it really is a long tail. So that's point one. Point two is there are a lot of, I would argue, relatively more straightforward deliverables and charters areas of scope that you'll see defined in M and A playbooks that basically stop at day 100. Because the Greater complexity and the bigger challenge, I would argue the bigger call for maturity within M and A models and teams is to be able to set the direction and figure out the solutions, the integration solutions required to get you to the end state. That's a broader complexity and the end state, going back to our first point requires of course, understanding where does that end state fit in the bigger picture? Within product portfolios, in the whole strategic roadmap that's in motion, or around the deal project, et cetera. So it's the complexity, it's the deal fatigue. It's a challenge where you inevitably see some either a revolving door or outright turnover. At the executive level, I would nickname the executives that are plugged in as deal stakeholders, deal sponsors. You'll see that term different things at different companies, but those very important roles, stakeholder roles, you'll often see some turnover. Maybe someone shifts roles or maybe they even leave the company and then you have a new person in that deal sponsor role. And then you have to educate them and keep them aligned. That can cause some issues as far as being able to have a through line of execution on what you originally intended with integration strategy and guardrails. And then of course you also see external X factors that can impact budget, resource availability. Maybe a pandemic happens, maybe a market crash, maybe something drastic happens in your particular product or industry sector and then you have to execute the rest of the integration plan on a much leaner resource budget or what have you. So all a lot of things can happen to disrupt your ability to get to the end of the integration plan. But last but not least, building out a full fledged, cross functional, truly operationalized integration plan. It's such a challenging thing that requires a lot of maturity and experience from M and A practitioners in house that I haven't seen that done very well. Various places that I've either worked at or worked with. That's part of the thing too is that what an integration plan is and needs to be is usually not well understood or completed.

A good example to kiss in as part of the long tail is really the contracting piece is a good example. So you have pricing, you have underlying agreements that have been negotiated, things like that, that really impact the customer and they impact your partner's expectations. Because you've brought all of your customers with you into this new company, what does that look like? They think everything stays the same. It's not going to stay the same. But what does that interim period look like for them from a pricing and contracting perspective? So those are things that you have to put in place, a contracting sort of transition plan, what does that look like? So that terms and conditions can align at some point and be sold on one paper, one order form, things like that to consider. And then some of the strategies we've seen, depending on the types of contracting agreements, is leave their terms in place and amend or rip and replace. That's definitely something I've seen done before and that's terrible and it's really hard on everyone. But you're typically going to be dealing with or looking at your key accounts in that sort of perspective from that lens, what is it going to do to your key account customers if we rip and replace, what does that look like? And then how do we then give them an interim solution for billing and again back to pricing and support and sla? Things like that that really matter to the customer. So that is one really good example of a challenge that happens within day 100 and beyond. Definitely should be being talked about in days one to 100, but likely not, not necessarily impacting or affecting that part of the process right then. But by the time you get to reviewing contracts, everyone is exhausted. And like Gwen said, a lot of times you don't have the resources to go ahead and go through that mechanics of making sure you have everything aligned.

A lot of things that could go wrong and challenges to overcome.

Contracting is a just on this particular area. It's a great example not just of complexity and challenge that you'll often see in a large enterprise setting in particular impact of something like contracting. But it's a good example to talk about because it's an example of an area that typically stakeholders won't understand, even M and A practitioners won't understand why it creates problems or why is this so impactful as either a delay to get to market with cross selling or bringing it acquired product to market in a way that meets the standards and policies, et cetera, required to have your sales teams sell it and contract it, et cetera, but also because it's tied to a bunch of cross functional, usually guardrails, how you bill, how you're taxed, how you're able to commit to certain terms in different regions to different customers, the pricing that you're committing to, who's responsible for and who's benefiting from the sale, as far as commissions and the models for the sales teams, et cetera. It's one example of a good nexus of integration factors and guardrails and usually constraints that then ties to all sorts of other integration milestones. When are you consolidating billing, when are you transitioning entities, et cetera? It's typically a hotbed of half informed debate or people arguing through their own lens of we can't do this now because of X. And then you talk to another functional stakeholder and say we must do it because of X. And then you go back and forth trying to determine what are the overriding priorities and the options for solutioning our way through this. And I would really point to the importance of something that I've defined and worked with in a number of places, and Tracy and I did this at Maersk as well, but to define what we termed a North Star for the deal project. And ideally this is something that should get created pre sign internally and then it gets iterated on and used as a sort of cornerstone touch point for any other integration planning or execution artifacts because it's a collection of guardrails. What are the core requirements and why? How do they tie and anchor back to why we're even doing the deal in the first place? And then that helps with the complex challenges and solutioning around things like contracting.

A lot of things that go wrong from fatigue, turnover, X factors, unexpected things in general, and managing the changes, things to overcome. It is setting the direction which is that North Star and then defining how to get there and also being mindful that this could be iterate as we go through the process. And the integration planning is also a really key thing. That sounds easy, but also is really hard. I've noticed that trend too. A lot of easier said than done. I had a question about structure of all of this because I've seen that be very inconsistent in the companies I spoke with, especially when it comes to integration, that we could buy a company and give it to the business unit saying here you go, your child, your paperwork's done, the deal's done, signed, it's yours, to having a centralized integration team that's there, but they're sort of brought in a little bit later in the process, deal teams doing their thing, and it's like, all right, we can bring those integration folks in and they come back and then they're essentially like rediligence. The Deal playing catch up. What I've seen more recently is the real merged together Corp dev integration team where integration folks are very integrated in the process and even I'd say probably even a trending thing is people are going to reach out to me and ask me more or bug me about this, but integration folks leading a lot of that deal process like the diligence and so forth so that there's a real synchronization between doing the diligence integration planning. Yeah, I'd love to hear from your experience, I'm sure you've seen the different variations, but I want to know the pros and cons because you know when I do meet that company that just gives it to the business unit and like maybe there's a circumstance where it makes sense. I don't know.

Yeah, I think it's a really interesting question about operating model or M and A functions. Certainly seen a really wide range just as you were noting Kisan and the question of what model is best or what are the trade offs is definitely in the back of my mind as a consistent thread. Here's the thing, there's pros and cons to all the models, the options that you mentioned. But one of the cornerstone that has to be there regardless of which model you go with and that is accountability and support at the executive leadership level. So if you play out the couple of basic options, you say you have a central team corrupt dev integration maybe corp dev integration is called imo, what have you. And then you have all of these M and A functions that are embedded within their respective parts of the organization. Whether it's sales support, customer success, tech, it, whatever the function is, hr, finance, et cetera. The benefit there is that you get those MA functional leaders close to both the objectives and the constraints, the concerns, the decision making within their respective function and when that works well, that really works well. That's awesome. But you also need to make sure that at the executive level that you have both awareness and support for whatever that slice, that cross section of M and A activity and responsibility is. So the head of sales, whatever that role is, whether it's the chief revenue Officer or something else, or the head of customer support services, customer success, etc. Each of the leaders needs to back and understand the priority of M and A activities. One of my roles I was in there was for a long period of time no one at the ELT level whose responsibility it was for integration. Overall it was a huge gap. Once cork dev and associated roles, once they were done with their deliverables and then their core charter, then it was really the case that the deal initiative was just tossed over the wall and then no one at an executive level had the responsibility to make sure that it was executed. But also no one was available for either providing support for escalations or providing contributing decisions at the executive level to settle a debate about what do we do about this issue or challenge or trade off, et cetera. So I really think that regardless of what model you go with, it's important that you have not only the awareness and backing, but also commitment as far as what are the OKRs, the objectives and the commitments from an internal performance perspective that one or more executives are on the hook for.

So no absolute. It is a depends. And then a lot of this hinges around ability to make decisions.

There are ways to make each model work for sure.

One thing too that typically forgotten as part of that process. Kissen and Gwen, you can agree or disagree, but I think leaving out the long term or the steady state team for such a long period of time is a huge sort of misstep in M and A and integration because it's that in state team that's going to take your newly acquired company, whether that's one year in or three years in. They're going to be the team that's seize the long tail all the way through to integration and then take over. So it goes to someone after integration. Leaving those cross functional processes out of the mix is a huge mistake because if you wait until the very, very end, now you have disruption again. And that's the one thing you want to try to avoid is disruption. You want it to be as smooth as possible in a crazy atmosphere. But bringing in your steady state people cross functional teams earlier than later is probably, in my opinion one of the best sort of strategic things that you can decide to do early on.

That's a great point. Let's talk about decision making. Decision making is interesting. From doing these podcasts I've learned so much of M and A success hinges around this because you have two different organizations coming together that have different ways of making decisions. And so much of doing integration is an exercise of making a lot of decisions as quick as you can. So I'd love to hear your perspective about it. And let's talk through like how do we make it work?

This is one of my favorite topics. First, there's a need to not just have that North Star defined, of course, initially it really is truly just a set of assumptions. It's anchored to a deal thesis, initial deal model as far as what is the value that you're after, you have to be prepared to iterate or suggest if it's appropriate. But to have that North Star as a direction setter, that's key. But then also to be prepared. As you step forward and progress through the phases of the deal project, be prepared to establish a key decision. You can call it a log, I've seen it defined a lot of ways. But to capture the key decisions across the functional lenses and also articulate what happens or what's intended to happen across the deal phases and phases of integration particularly, then you can really work not only awareness through visibility, but also alignment and prompt for feedback and iteration if needed across the functional leaders, whether they're M and A functional leaders or their business unit leaders. To Tracy's point about pulling in business leaders during the planning, not just wait till you're ready to execute and make sure that you're all singing from the same page. And here's an example on capturing key decisions. You might look at it from a product perspective very, very simply, boil it down to what of the acquired products or services are going to be kept in market or maybe pausing sales and then intend to bring it back to market. What are we doing with the acquired customers, what are we doing with the acquired partners, what are we doing with contracting, pricing support, any of the key areas where function leaders and teams would need to know what are we doing and what are we supposed to not be doing and what do we tell customers and what do we tell partners? At a very high level to have that reference point is key. Of course you're not going to know answer to all of those blocks of decisions initially. So you work with working assumptions and then you use that to prompt for at the right time decisions and strategic inputs from the executive or steer code level for the deal. So then you rough it in and then you flesh it out. The idea is by the time that you get to, let's just say, sign, roughly speaking, because I'm such a huge fan of not only integration, led diligence and having that lens early on, but also making sure that you have, to the best of your ability, a directional plan in place and alignment on that before you close. You're looking at then a set of key decisions that set the direction and guardrails for day one, day two, 100, 100 plus, etc. Those two things are really key, therefore decision making. Last but not least, to have the information flow mapped out, not just who's making the decisions and giving the Approvals. But then who needs to be aware? Who needs to be aware so that maybe they have the opportunity to raise questions or input, et cetera. In various places, I've nicknamed that the nervous system. Just how is the communication going to flow? And, and that sort of ripple effect of making sure that there's visibility and opportunity to provide input or responsibility for inputting decisions, if that is what your role is.

Assumptions is a big piece of it. The two big pillars I got was one actually like planning decisions ahead, which is something I never thought about. And then logging decisions, you basically have these broad assumptions. And based on that, that lends you to start planning when you'd make decisions at the right time. And then when you do make those decisions actually like log those decisions and then that lends into the information flow. Because when you do make those decisions, you want to be able to map out who should be aware and communicate that and then have that as a reference point. So people can always go back. No, that sounds really a key part of this. And I'm just trying to get like a visual, maybe we could even talk through example. But does this decision turn into like a tree structure? Because I almost feel like you make a decision to do this and all of a sudden you got to make a lot more decisions after that. Does it sort of turn into that kind of. What does it look like?

It often does. An example that Tracy mentioned earlier around defining a contract transitioning plan, that's a great case in point. There have been a number of other so called big rock topics and decisions that, that I would point to around when and how to do the billing transition or when do we. Or must we transition entities? So acquired entity, the decision around do we keep it? If not, when do we transition it? And then the tree structure that you're referring to. Absolutely. And you can apply this to if you just take the entity decision, what are the basic trade offs? Either the prompts or the trade offs. And often the first question that I raise if sitting down to a discussion around which things are the priorities in the earlier stages of integration versus something we can defer to later, is do we have a reason why we need to do it sooner than later? So going back to the idea of a North Star, if you look at the basic components of, at least in my view, what a North Star would include, you have value creation or growth objectives as prompts, you have compliance, whether that's regulatory or internal policy or what have you. You have compliance oriented prompts. That constraint you have to do something in a certain way or by a certain time or not do something, etc. And then you have drivers that are around cost savings, so capturing or realizing synergies. And then you also have the need for various reasons to keep the lights on, so to speak. So, so keep something legacy, whether it's internal legacy, something you have or something that was acquired and you're gonna keep that going for a while because you need to support and maintain some momentum for some operating model until a certain time. So maybe there's a requirement there, even though it seems messy, it's non standard, it's costly, but there's a reason. So of course again the importance there is to understand the guardrails and the reasons and then last but not least, customer experience and employee experience. So you have retention and adoption and acquisition and retention drivers there. So to understand what those basic ingredients are for your drivers and your aspirations, then that will help you to weigh then the tree and the unavoidable cross functional intersections or rabbit holes, however you want to define it, that that sprout out from the decisions. If you take the entities like we don't have to do it now. However, there's a financial and like tax burden to continuing this entity. It seems harmless enough, let's just transition it, let's just retire that entity. But then you find out when you go look at how are we going to continue billing for that acquired product that we do intend to keep in market, we can't shift to billing as the acquirer until we're ready to have the billing system integrated, whatever. And I'm probably calling out examples that are so common and so obvious to your listeners that are like, yep, we've been there, but the point is the connection. And to be anticipating that each of these key decisions are going to prompt a need to make sure that everyone that's supporting the decision making and plugged into the project, that you're ready to educate them and support them on a sort of a straw man framework of how do we come together with a really quick lean analysis on the trade offs and then bounce those trade offs off of the North Star of the deal and then inevitably put it to the steerco level stakeholders that are responsible for the decision. That's really the basics there is to make sure that you're anticipating it to your call out Pisan and then also that you have a, a little lean structure ready to plug in. Say okay, we got the North Star, got this piece, we've got this artifact, we've got the decision log with the Working assumptions and then plug that in into a quick sprint of analysis so that you can raise that up for decisions.

One of the ways that we've done that before in the past is sort of a what do you know and what don't you know? So a knowns and unknowns exercise. Today we know this and if this stays the same, what is the outcome of that? And if it doesn't stay the same, what's the outcome of that? It's an analysis of if we do nothing, fine, if we do something, then what? And then it becomes a matter of when do we do something? Decisioning. So you have to go through that analysis before you can kick off anything. Know what you know and then make a decision about it and how to get to the next step. That's always the biggest part of the process.

And don't forget about the end goal. Those who have worked with me know that I have a penchant for pointing out what seems like the super obvious. But I will say don't get distracted too much by the complexities of the interim states. The day 100 ish state where you're like, oh, there's this scope to do. We don't know which thing to do first or it's all interconnected, we the solutions, decisions, et cetera. But in that decision making and analysis set of activities, it's important to remind particularly senior leadership stakeholders that first and foremost you have to have an eye on the end value, what was the objective and the assumption for the deal. As far as the deal model, which deal models are never perfect, they're preliminary, they're a thesis by design. But the point is, is that if you get too concerned with avoiding disrupting the current business model, particularly for the acquired company and there's always understandably a lot of sensitivity around oh, don't disrupt this, don't change our contracts, don't shift our sales model and commission model, don't do that, it's going to piss our customers off. Don't do that. It's going to piss our whatever teams off. It's going to disrupt our ability to make the numbers this year. All those things are important but you have to weigh against what was the longer, bigger picture goal. That's a key piece too that I would add to all that as far as the hat trick of decision making and handling navigation of that decision tree.

Can you teach me how to do this? Can we role play this out?

Absolutely.

Let's say I'm a tech company, a really cool M and a management platform really cool. 1. I'm acquiring a AI integration doohickey company. We're just kind of setting this deal up. Typical CEO that's hungry to do a deal, want to add this capability in. And a friend told me to talk to you two and make sure we set this up so we don't screw it up like the last one. And everybody was so confused when we closed the deal. They had no idea who's doing what. And. And the thing is, they couldn't make decisions without me. I want to get an understanding of like what you described. How do I actually approach setting this up and also like setting it up in a way that's going to foster making decisions fast so we can do the integration fast.

I would first say, Keith on Tell me in just the most compressed nutshell why you think this is a good idea. Never mind that, like technical specifics, customers.

Are going to love this AI capability because it's going to help them plan integration much faster. It's really going to bridge that gap between diligence integration. It's something that's missing in the market. We've seen customers struggle with integration. We don't have strong capabilities in integration. By buying this company, it's going to enhance our offering and make it compelling and we could probably upsell it. We like upselling things. We. So the upselling is going to give us a good revenue lift and we see some strong synergies there as well.

Awesome. So then I would say if you're looking at this as a critical value add, and presumably you are intending to either embed it within and deeply integrate it within your existing product platform, or at least tie it under the hood through APIs, et cetera. Then I would anticipate that there's going to be some key decisions around integration timelines and readiness. Do you have the resources with the right skill sets, or are you relying on the Fire team predominantly to enable not only a robust integration plan and by that I mean literally product integration. And also I'm assuming that you want an accelerated timeline, like there's a timetable at which, beyond that it wasn't worth doing the deal. If it took you for some reason two years to tie the products together enough that it made sense to bring it to market as a value add for your customers, then there's no point and I'm just picking a timeline arbitrarily. So I would say on the product level, expect that you're going to need the resources and the focus to see that product integration timeline, both the plan defined and also the commitment to execute quickly and make sure that your assumptions are vetted around the domain expertise of the resources on targeting. Make sure they actually know their stuff or is it just a couple of the co founders and then their teams are actually really junior they're not going to be able to help you do the product integration. I'm sure Tracy has some things to add and prompt you with around readiness from a commercial standpoint to make decisions around how do you sell this and what do you expect the teams to do selling it.

Yeah, I would say that you would have to consider what that commercial model looks like. Are you selling a SaaS model? Are you selling a license model? What is the customer getting from you and how? What's the methodology? Is it a link? Is it a from a SaaS type product or do they actually need a license key? Depending on how you're going to sell that to the customer that's going to matter. Pricing, what does that look like from with your product contracting? Is it click and go like just an online sort of agreement terms and conditions? You don't negotiate those types of things. You need to take a look at from company that you're looking to acquire. What do they do today and does what they do today work? Where are their big rock problems? What are they looking to solve by being acquired? Is it just a money flow issue or is it truly a product issue? The product might look really exciting but if they can't get it off the ground then you have to really consider what that does to your own company.

And last but not least I would ask you Kisan to consider preemptively consider what would piss your customers off most based on their expectations and I'll give you a couple of examples. Do you think that they have just things that maybe they take for granted that you are already satisfying them with like good contracting terms, favorable pricing, Maybe they like how their terms renew automatically. Whatever it is that they like, they are most likely going to be upset if that's disrupted or changed. So anticipating if you buy this company how quickly can you actually from a commercial standpoint, from a go to market model standpoint, bring that to your customers in a way that is not going to cause more disruption than provide added.

Value bringing back the other stakeholders perspective. So I can see how these assumptions I got a few big assumptions and now you're starting to get me think operationally and that these assumptions start cascading into more smaller assumptions and then it seems like there you starting to surface like where there are going to be some Points of decision. And some of that we need to wait till we get more information. Some of that we can start at least hypothesizing now of what's going to happen if we go plan A or plan B. I'm getting a sense we're going in that direction. What about like a model? Or is there anything I need to define in terms of how we make decisions or sort of get everybody on the same page around that? Is there anything that I should be thinking about?

I would ask you, who's responsible for in general, weighing in and setting a direction and weighing in on key decisions for the different aspects of your current business. So who makes a decision on product strategy? Who makes a decision on. And maybe this is the same person, but from an engineering perspective, how something is built or integrated or triaged, who makes a decision from the perspective of the commercial model, whether that's broken into pricing and contracting, et cetera.

That race model.

Yeah. Make sure that those people or a proxy for those leaders is then plugged into the deal initiative. That's step one and then step two. Of course, having that North Star piece and in the beginning, honestly, that could be half a page. It doesn't need to be something that's overcomplicated, but something that sets the groundwork for. These are the core requirements that enable the deal thesis.

I'm not creating a lot of technical rules. It's more of really making sure the right people are looking or sort of guided to make those right decisions, but then having that North Star defined so they're conscious about it, that, hey, this is the outcome we're going for. So let that guide you to making the right decisions.

Yeah, absolutely. And there's relative priorities too. There's a relationship between the priorities. There may be a priority around the target company's product and also its people, but maybe for this particular deal. Kasan, do you technically care more about the product? Is that more central? Not that you don't care about the target company people, but maybe it's not such a critical piece. On the flip side, back to our earlier points, you could tell me, you know what, I don't have the deep enterprise application integration, particularly when it comes to AI and ML tools. I don't have that expertise across a ton of resources. Internally, we just have pockets of resources. So we really need to lean on the target company. And if that's true, then I would say that the target company people is practically equal to the importance of their product and their technology. So it's understanding that relativity too that helps to guide decision making, whether it's trying to answer to a prompt around, hey, are there opportunities to streamline resources post close if maybe there's a budget crunch or maybe there's a question around creating the retention bonuses and what do we need to put in place within the deal terms itself to ensure that we're keeping the right people around that are really critical to executing on that engineering and product roadmap?

So there's a level of prioritization there. What about the stuff that pops up? The challenges, the problems? How do I keep people from running to me for all those little things? Stuff we didn't map out or expect?

Yeah. So back to the RACI understanding and then empowering the roles from a functional perspective. If you're going to say, let's just arbitrarily that you have a go to market M and a functional leader, they're responsible for both driving the planning and also coordinating and escalating the decisions and insights around everything that is related to go to market sales, it's marketing, it's sales ops, it's customer support, et cetera. And then you have another lead and their team that's responsible for all the technical aspects and then you have another one product, et cetera, et cetera. Then you need to make sure that those functional leads are empowered to be responsible for either defining a decision if it's appropriate for them to do that, or working with their respective leadership to go get that decision made. And if it's something that can't be solved for within that functional path, then at the very least they need to bring back or work with other functional leaders to do this for a cross functional analysis, raise up to the deal leads and to dealseerco an assessment of the options and trade offs to really focus on the accountability for not just pointing to scope and problems and issues, but also here's the options. We've looked at this from a lean assessment sprint perspective and based on the deal objectives and the guardrails and the North Star, et cetera, this is what we would recommend considering. There's this, but it costs a lot, require a lot of resources, but it solves it like this. And there's this over here. You allow for the cost and some issues to continue, but there's a trade off because you're not investing in a throwaway solution or whatever.

Also Kisan, one of the things to touch on is if you're really wanting to put something robust in place like from day one, an integration help desktop per se, or a guardrails the racy piece, making sure that artifact or that documentation has been created so that you know, going into it, who's going to make these decisions? Who am I going to empower to decide these particular items? And having that sort of laid out prior to is super helpful. And again, it can be half a page and iterate because as you go you may uncover different things that need to be decided. But it doesn't have to be complex, that's for sure. It can be an easy process. You just have to have the right people willing to and informed enough to be able to make good decisions.

Starting to see a theme here of assumptions, people, strategic pillars. As we progress through this deal where people are aligned and we're making decisions that drive towards the North Star. We're humans like we forget everything the next day. How do we, if we mention the decision log, how do we like walk me through how do you actually make a decision log that works? Because I feel like it's just such a big challenge, small or large company.

Yeah, here I am mentioning another seemingly super obvious thing to call out. But one thing that I've seen back to the point of the nervous system. What visibility do I need to share around certain areas of information or artifacts that are created within the deal project, not to mention tracking status, et cetera. And the benefit of having even just a single shared folder, let alone a SharePoint site or something that is a restricted site at first just for deal project members, and then later you can open up certain areas of it to either broadly internally or adjusted, certain leaders, et cetera. But the point being that you have something that is a source of truth, touchpoint, whatever that structure is of that document or Deck or SharePoint page or whatever it is, make sure that you have that created early on and then make people aware of and remind them where to go for it. So maybe for instance, at the bottom of every one of the initial like deal project decks, like you do a kickoff at the start of diligence or what have you, you have your functional leads assembled that are the cross functional members of your deal project. And at the bottom of key documents include a link to the, you know, the internal project page or landing page, whatever it is that you want to point them to, you start to train, not only provide awareness but to train build that muscle memory. Oh, okay, there's the deal project page or whatever. And then have within that share shared touch point you have a reminder of, here's the key dates and milestones. It's up to you whether or not to try to get fancy and have iteratively updated like project tracking, et cetera, but even just to have the basic dates and milestones recapped and then to have a reference point of Here's a list of the functional leaders, back to the responsibilities aspect of knowing who to go to or who to expect is handling certain areas of decisions. So there you have who's on what base and then you also have the access to the deal North Star, this is why we're doing this. And these are the core assumptions or guardrails. And then when it's ready, then you also publish whatever form the decision log is in. And again, it could be really simple. It could be, hey, let's define it across product and go to market and tech employee experience, whatever the facets are that you want to detail and then say, okay, here's day one to 100, the assumptions, day 100 plus end state or final integration, whatever you want to term it and then say across those phases, what are you assuming? And as the key decisions actually get made and formalized, oh, we've definitely decided that these things are no longer going to be happening or permitted or what have you. And we're also going to be able to then do other things or start sales on something or what have you. Then you put those key decisions in where you're replacing what used to be just working assumptions again. It might seem really obvious, but just making sure that you have a mechanism for providing the awareness and then enable people to access that and then in later stages of a deal project is of course really helpful to do things like a newsletter.

I like that.

Just a monthly email that goes. Tracy mentioned the notion of a help desk at a few places that we've been implemented. We've worked with the functional leads on a deal project and said okay, either you or someone from your team needs to be added as a member of this distribution group behind the scenes. And then when we kick off post close integration execution, we're going to, in any acquired employee or stakeholder communication, we're going to include a mention of this help desk alias, Project XYZ Integration Help, whatever it is, the email aliases. And then behind the scenes, any of those inquiries or issues then come in and the members who support that alias are able to from a functional leadership perspective, hop in and say, ah, everybody.

Has access to the email like on the acquiring company or just the leaders.

It's ideal if it's everybody.

Yeah.

So that then they know, for instance, if they're really spinning their gears let's just say spinning their gears and maybe starting to fill the void of lack of clarity around an integration decision. Hey, when do sales commission structures change? Then people make stuff up for better, for worse. They're always gonna just make up an answer if they don't have the information, the ability to then into them. Maybe it's actually going to impact their behavior or their team's behavior drastically. How motivated are they to do something that is part of the go to market plan for the deal and supporting the overall deal objectives? So maybe it's actually quite impactful. You want to encourage and enable people post close to raise a question to get it answered, to flag it as urgent if it is truly urgent. Maybe they have a customer facing issue because their large enterprise customer is super pissed off at the apparent fact that they now have to sign four different contracts just to be able to get your products that it was working with already and also pay up for the acquired company's products as well. And they just want a single contract. So that's a pretty important question anyway. So yes, ideally everybody internally.

So the way to make this work is being proactive on communicating these decisions, which could include having the log in a central place that you remind people that's where to go, newsletter be another way and then also help desk. Yes, yeah, or M and a management platform here has some of this capability. But at some point I can like learn from you because the thing we're missing is like how do you tie this up to the North Star? It'd be interesting to like kind of productize some of that, making sure that stays sticky because it's the most common thing you hear about. And it's always. It's again easier said than done. Oh yeah, the strategy, communicate the strategy. But then all of these people are working on things. Everybody forgets why we're doing the deal.

And that's part of what we're motivated and preparing to do. Because drawing from the learnings of it's almost serendipitous at this point because it just keeps happening. But I found myself in so many roles where the prompt was you need to create and implement framework a repeatable model and also find a way to bridge from that repeatable M and a model over to the whatever you call your standard operating model, whether it's from the Amazon world, the OP operational planning or if you call it something else, it's whatever your standard non M and a way of prioritizing roadmap and resources and budget, et cetera. You need to connect that as soon as possible at an appropriate point in the deal phase to that. So it's about getting that connected. And I would say that the aspect of productizing solutions for those repeatable models, that was one of the biggest motivations I had over the recent year in realizing that there are not only a lot of repeating patterns and repeating solutions, but also there is a way to construct adaptable sets of artifacts and adaptable framework that a company can take that and say, okay, we're going to tweak this. We're going to mold this to fit not only the way that we do business and the way we want to do M and A, but the realities of what resources and roles we have in play. And also occasionally specifics on a particular deal project. Maybe it's so nuanced that you need to adapt a particular artifact or way of working.

I can see this applying really well for rollups as well. Just because they're doing deals at scale.

Absolutely.

Maybe there's an opportunity to collab on our M and A either science fair or summit later this year. Roll up is going to be a big theme going to 2025.

That would be very cool.

Yeah, it'd be fun.

I gotta ask you both. What's the craziest thing you've seen in M and A?

I can think of one. This goes back a few years. The company I was at, we bought this great company out of the uk we planned for their integration and migration of their product. And we planned well. Like, I have to say that our systems team was pretty robust and incredible. So all of the testing went well. We were set. I was in New York City, super excited to be there with the team for that particular office. And it was like go live time. And I'm telling you, we had done months of training with this exact exercise of go live. And the minute we hit the switch for true go live, everything died. We lost all of their data, all of their customers, everything we had planned for gone just like that. And I literally thought we were going to have like salespeople and the old CEO, like, jump off the building. He was. They were freaking out. We all were, frankly. But it was. It was really crazy.

This is like a day one type of cutover.

Or it was like, no, like day 100 plus. It was a true cutover.

It was really like systems cutover.

Really, really system cutover. And we thought it was going to go well. Like I said, we had a great migration team, great systems team. Testing went well. Tons and tons of testing. We were just like, yeah, it's time, let's do it. And everyone logged in right after go time and nothing. Nothing. Not even a screen was available. Talk about panic.

Easy. It's easy. Sounds easy. It's not easy.

Not easy. The words all sound great, but they don't always come out as planned. So that was pretty crazy for me.

There was a particular deal that had been struggling for several years and technically Corp Dev, imo, from a formal sense, had already bowed out. But because there was a need to prompted from the ELT level and need to figure out how to unblock things. Hey, we never captured the value out of this deal. Not sure why. Don't want to spend any time on figuring out why. But can we just solve that, Unblock it. And so IMO leaned back in just for a short period of time to sprint through driving integration and got to the point after several months of working with imo, Sterco, et cetera, to try to drive progress on decision making and landing like, okay, let's agree, this is how we're going to execute on this long tail. And then arrived at a critical Steerco meeting that was to raise like, here's three or four key decisions with trade offs. And the main deal sponsor showed up to Steerco and essentially said, I don't know what all this noise is about. I didn't read the proposals, I didn't read the requests, but I don't know what this is about because integration is already done. So we don't need an integration plan and I don't need to prioritize resources. And that was probably one of the craziest things that I've heard. And it shows, of course, back to think about awareness and education, just a fundamental gap that necessitated, as you might expect, revisiting fundamental conversations.

Let's just say was integration in his definition?

That was the next question.

Yeah, we got the contract signed, we're fully integrated, we're good to go, we're done.

Yeah.

And it's funny too. We've talked about this a lot, Gwen, you and I for sure, but integration means something different to everybody. And that's something that was a huge lesson learned that I always thought I was using the word the way we all understood it. And then turns out this last year we all had a huge sort of aha moment where it's like, integration to a lot of people meant we can sell the product and that's not integration. You're just lucky enough that you're still selling the product in a way that was a legacy process. But you're certainly not integrated.

So it's a good reminder in that education piece and communication piece to also check your semantics. Is the all out there. Yeah.

Thank you both. Gwen Tracy this has been an great conversation. I learned a ton. Learned a ton about decision making specifically. You've helped me become a better M and A scientist today.

Thank you.

Well, we learn a ton from your ongoing conversations with other practitioners. Always a pleasure.

Pleasure is all mine. And fellow M and A scientists, how you get to the end, I love you for it. I want to hear from you because you are the true M and A scientist for sticking through and that's I make it intentional. I put the good stuff towards the end of the interview. So reach out to me. Love to connect. It's been fun. I get folks that reach out, connect on LinkedIn, send me messages, feedback, topic ideas, criticism, I guess some of that which I welcome. That's how I learn and get better. Till next time, here's the deal. Thank you for taking the time to explore the world of M and A with our product podcast. We love hearing feedback. Tag us on a LinkedIn post. Add a review on Apple Podcast. 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 MNA 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.