Mastering Serial Acquisitions

29:32And then you have all of these M &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, etc. The benefit there is that you get those M &A 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 &A activity and responsibility is.

30:18So 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 &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 corked out 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.

31:00And 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, etc. 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.

31:42So no, absolute. It's sort of, 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's typically forgotten as part of that process, Kisan 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 &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 sees the long tail all the way through to integration and then take over.

32:25So 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 &A success hinges around this because you have two different organizations coming together that have different ways of making decisions.

33:19And 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.

34:06You 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 &A functional leaders or they're business unit leaders. 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.

34:48And 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?

35:30At a very high level, to have that reference point is key. And of course, you're not going to know the 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 again inputs from the executive or steerco 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 an 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.

36:26Those 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, etc. In various places, I've nicknamed that the nervous system. How is the communication going to flow? 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.

37:04The 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 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 and know.

37:38That sounds really a key part of this. And I'm just trying to get like a visual. Maybe we can 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 I would point to around when and how to do the billing transition or when do we or must we transition entities.

38:22So 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.

39:10You 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 keep something legacy, whether it's internal legacy, something you have or something that was acquired. And you're going to keep that going for a while because you need to support and maintain some momentum for some operating model until a certain time.

39:49So 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 in the tree and the unavoidable cross-functional intersections or rabbit holes, however you want to define it, that sprout out from the decisions.

40:30If you take the entities, we don't have to do it now. However, there's a financial and 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, you'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 tradeoffs and then bounce those tradeoffs off of the North Star deal.

41:35and then inevitably put it to the steer code 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 case on. And then also that you have a little lean structure ready to plug in and say, okay, we've got the North Star, we've 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.

42:15So 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 that 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 yep those who work 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.

43:07We don't know which thing to do first, or it's all interconnected. We need solutions, we need 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.

43:52Don'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. And 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 roleplay this out? Absolutely. Let's say I have a tech company, a really cool M &A management platform.

44:31Really cool one. I'm acquiring a AI integration doohickey company. We're just kind of setting this deal up. Typical CEO. It's hungry to do a deal. Want to add this capability in. And a friend told me to talk to you too 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 the thing is, they couldn't make decisions without me. I want to get an understanding of what you described. How do I actually approach setting this up? And also setting it up in a way that's going to foster making decisions fast so we can do the integration fast.

45:16I would first say, Ketan, Tell me in just the most compressed nutshell why you think this is a good idea. Never mind the 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 and 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.

45:52So 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, etc., 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 acquired team predominantly to enable not only a robust integration plan?

46:38And by that, I mean literally product integration. and also I'm assuming that you want an accelerated timeline. 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 plan defined and also the commitment to execute quickly.

47:17And make sure that your assumptions are vetted around the domain expertise of the resources on target. 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 to the product integration. And 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?

47:55Are 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 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?

48:33What 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 granted that you are already satisfying them with? Like good contracting terms, favorable pricing.

49:13Maybe they like how their terms are new automatically. Whatever it is that they like, they're 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 getting me to think operationally and that these assumptions start cascading into more smaller assumptions.

49:54and then it seems like there you're 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? 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, but weighing in and both setting a direction and weighing in on key decisions for the different aspects of your current business.

50:33So 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, etc. That race model. Yeah, make sure that those people or a proxy for those readers 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.

51:19I'm not creating a lot of technical rules. It's more of really making sure the right people are sort of guided to make those right decisions. But then having that North Star defined so they're conscious about it. 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, Kisan, do you technically care more about the product? Is that more central?

51:57Not that you don't care about the entire 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 the expertise across a ton of resources internally. Normally, 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?

52:44if maybe there was 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 racy. Understanding and then empowering the roles from a functional perspective.

53:24If you're going to say, let's just arbitrarily, that you have a go-to-market M &A functional leader, and 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, etc. And then you have another lead and their team that's responsible for all the technical aspects. And then you have another one product, etc, etc. 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.

54:10And 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 deal Circo 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, etc., this is what we would recommend considering.

54:50There's this, but it costs a lot, requires a lot of resources, but it solves it like this. Then there's this over here. You allow for the cost and some issues to continue, but there's a tradeoff 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 desk 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?

55:32And 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. I'm 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. We forget everything the next day.

56:09How do we, if we mentioned the decision log, 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, etc. etc. 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.

56:53And then later, you can open up certain areas of it to either broadly internally or just to certain leaders, etc. 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 assemble that are the cross-functional members of your deal project.

57:37And at the bottom of key documents include a link to 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 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.

58:29So 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?

59:15And 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.

59:53I like that. Just a monthly email that goes back. Tracy mentioned the notion of a help desk. At a few places that we've been implemented, we 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 and 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 alias is. 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.

1:00:49Everybody 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 or more, they're always going to 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 drastic.

1:01:27How 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.

1:02:04And 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 would be another way. And then also help desk. Yes. Yeah. Our M &A management platform here has some of this capability, but at some point I can learn from you. Because the thing we're missing is how do you tie this up to the North Star? It'd be interesting to like kind of prioritize some of that, making sure that stays sticky because it's the most common thing you hear about.

1:02:45And just always, again, easier said than done. Oh yeah, strategy, communicate the strategy. But then all of these people are working on things and 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 &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 &A way of prioritizing roadmap and resources and budget, etc.

1:03:31You 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 and realizing that, ah, 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 &A, but the realities of what resources and roles we have in play.

1:04:13And 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 roll-ups as well, just because they're doing deals at scale. Absolutely. Maybe there's an opportunity to collab on our M &A, either science fair or summit later this year. Roll-up is going to be a big theme going into 2025. That would be very cool. Yeah, it'd be fun. I got to ask you both, what's the craziest thing you've seen in M &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.

1:04:49We planned for their integration and migration of their product. And we planned well. 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.

1:05:34He was freaking out. We all were, frankly, but it was really crazy. This is like a day one type of cutover? It was like, no, like day 100 plus. It was a true cutover. So like really 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 sounds easy. It's not easy. Not easy. The words all sound great, but they don't always come out as planned.

1:06:17So that was pretty crazy for me. There was a particular deal that had been struggling for several years. And technically, CorpDev, IMO, from a formal sense, had already bowed out. But because there was a need to prompt it from the ELT level, a 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, Styrco, etc.

1:06:58to 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 Styrco meeting that was to raise like, here's three or four key decisions with trade-offs. And the main deal sponsor showed up to Styrco 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.

1:07:40And it shows a perspective to think about awareness and education, just a fundamental gap that necessitated, as you might expect, revisiting fundamental conversations, let's just say. Was it 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.

1:08:16And 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 specifics is all out there. Yeah. Thank you both, Gwen, Tracy. This has been a great conversation. I learned a ton. Learned a ton about decision-making specifically. You've helped me become a better M &A scientist today.

1:08:54Thank you. Well, we learn a ton from your ongoing conversations with other practitioners. Always a pleasure. Pleasure is all mine. and fellow M &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 &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 get some of that, which I welcome. That's how I learn to get better. Until next time, here's to the deal.

1:09:41Thank you for taking the time to explore the world of M &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 &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, at mascience.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.

1:10:26Again, that's mascience.com. Here's to the deal.

1:10:40views and opinions expressed on M &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