Improving IMO For Efficiency

We recently launched a new book titled how to Stand up an M and A Function. Even if you're an experienced M and A practitioner, standing up an M and A function is a challenge of its own. That's why my colleague John Moretta and I compiled a series of templates, perspectives and Excerpts from over 50 interviews to help you build your M and A team from scratch. Topics include the order of hiring, establishing your operating model, developing your organization's integration muscle, and more. Find it on Amazon under How to Stand up an M and A Function link is in the show Notes. I'm Kisam Patel and you're listening to M and A Science where we talk with deal professionals and learn valuable lessons from their experience. This podcast focuses on stories, strategies and what actually happened during M and A deals.

Hello M and A Scientists. This is John Morata, Chief Operating Officer at M and A Science. Guess what? Today I'm taking over the podcast because my good friend and colleague Kiswan Patel is actually away from his desk. So today our interview is going to be with Wendy Nicholson. Wendy is a VP of Technology and Product for M and a integration@salesforce.com Salesforce is a customer relationship management software and application focused on sales, customer service, marketing, automation, analytics and application development. It is traded on the New York Stock Exchange under CRM. So today Wendy and I are going to talk about how to improve your IMO for efficiency. We'll go through some of our best practices, our our experiences and it's going to be a great ride. Hang on tight, we're about to get started. Ladies and gentlemen, I am so pleased to be here today with Wendy Nicholson. She's an amazing woman with a very expansive career. But before we jump into all of that wonderful detail, Wendy, would you like to give us a little bit of introduction about yourself?

Thank you so much John. I really appreciate being here and the opportunity to talk about what I do and who I am. So, Wendy Nicholson and I'm Vice President of Mergers and Acquisitions in the tech and product area for Salesforce course where we do due diligence and integration for all acquisitions here. In the past I started off as a developer. My career spanned more technology focused areas. Leading development teams, leading squads, getting into agile, doing all of that and then kind of moved into consulting and then learning more about governance and program management and project management and really fell into sort of more of the PMO leadership space. And from that I graduated and had the opportunity to move into actually leading a planning and execution area for a company for M and A and that was like, right, not in my sweet spot because I didn't really know M and A, but M and A was so interesting to me. I'm such a geek and I like to study things, I like to tinker with things. And so I just jumped in and first thing I did was we're an agile shop and you know what? I should look at what that means and what about Agile M and A? So that's how I first got introduced to Agile M and A and really kind of read that cover to cover and started thinking about ways that should be implemented in our environment and how we could do things differently. From that point. I kind of really got into it and got my teeth into a few acquisitions and then being able to see some things that were repeatable and being able to do more things there, that really prepared me and landed me to this job at Salesforce to lead the entire integration team here. So I'm here today and I'm loving it.

Wendy, you're touching my heart with the whole Agile M and A thing. So thank you so much. Being ex Salesforce as well, there's a lot that we learn from a company where things are moving so fast, they're just constantly moving forward. But with that, Wendy, there's just so much going on. Sometimes we forget to look at how do we make the next thing better. We forget to look at hindsight. But it sounds like in your career you prefer to do that. So with the title of today's podcast being all about IMO efficiency, what are some of your, let's call it, lessons learned for the audience today around how you structured a look back to help make sure that you have the next generation of IMO efficiency.

Every acquisition is very different. With me having a very high performing team that was executing already, the next layer was really about how do I get structure, how do I get repeatability, how do I make sure that we can improve as we move forward? So then it was just more of how to start talking more about our playbooks and what's our definition of dawn and how do we kind of make that something that helps us down the road so we're not creating the wheel every time and we're really being more agile ourselves, using our tools, being able to look at every acquisition with some starting point. And we know, like I said, every acquisition will have its own nuance, its own difference. And then for us it's just how do we implement that, how do we look at that change, how do we make sure that we can maybe see it in the future and handle it later. So I think that those are some things that work with my team over the last year to really look at repeatability, to really look at a starting point, to really look at refining those points as we kind of move forward.

This idea of repeatability I love because it creates this wonderful structure that those who are coming up behind us, they have a guide, if you will, they have the guide rails to operate in. And that's sometimes just a great way to establish a good culture within the company. But sometimes, as you duly noted, the changes in the way that we do integration tends to change and mold itself in a way that the company that we're acquiring or the technology we're acquiring, but that's going through change, it is pushing us constantly, ever forward. Do you find that those technology changes challenge you and how you look at efficiency in building your IMO for the next transaction?

Yes. And I got an example actually today where we're changing the way that we're looking at our rosters, really and more of our orgs and what that looks like, then that means, oh, that's going to have to change my playbook that we have. So having a playbook for those things and saying, okay, that will change. We need to be included. We're not normally involved with the run of the day to day business as usual from an engineering perspective, but for us it's okay. I just heard about this getting in the know and understanding what's happening. I just realized that thing is going to change. So what does that mean for us? That means that we have to change. That means that our playbooks are living documents. That means that our playbooks are also going to have to adjust to that and we're going to have to work with our supporting teams to say, okay, engineering, let's talk a little bit more about what that's going to look like in the future and also look at when is that going to happen, because that could also impact our timeline for our integrations, for acquisitions that we have. So things that are in flight versus things that may be new, that may start from the beginning and so what might happen in the interim? If I've already started down a path and that wait a minute, that's going to change somewhere between before we can get finished with an integration, then I'm going to need to know what that is and what our plan needs to be going forward. Do we let them finish? Do we pause and sort of reset for the new technology or do we just wait? That is some of the things that we can get thrown as well. And sometimes you can't predict things like security, you can't predict all the things that are going to fall out. And though we don't own security, we work really closely with our security partners and basically they're leading that. But we're kind of driving to sort of say, is this done as part of one of our checklist items? From a technology and product perspective, this includes security. And so security, did they get all their vulnerabilities done, make sure that those things are also happening and that we are included on the plan and the decision making that goes with it.

I hardly believe in everything that you're doing around definition of done. Sometimes that's a moving target. For those of us who've been in integration for a long time, we understand that there are quite a bit of flexibility when it comes to our roles and the definition of done. One of the challenges that I found in just past experiences, which is when do I apply the definition of done? We have the first hundred days and is that done? And is that done against what? How do you look at the definition of done not only as an executive in the imo, but as you govern and manage your work streams, how do you instantiate that definition and done for them?

Every acquisition should have that same definition of done. There may be bits and pieces that don't apply. This may not apply to this took in, but it might apply to a very large new cloud acquisition. For me it is if I can measure each one of them side by side with that definition of done. You've got to get the security done, you've got to get your application monitoring done. You've got to get those things check, check, check. And I can also say I have target times, right? Maybe I want to get these things done in the first 30 days. You need a network, I need that in the first 30 days you need to have. Everybody should have laptop. When does that happen? Trying to establish some of those one are like very concrete versus ones that are like, you know what, this is a healthcare acquisition and you know what, it's sign up time. So I'm not going to be able to do any kind of changes between that October to like March time frame. So we know that some of those things may have to get pushed further out. Those are the kinds of things that you have to look at. And even though everything has a definition of done and if I can look at every acquisition side by side and just check off the ones that are applicable and then be able to say is how well, I'm doing or not doing and when this will probably happen. So then that becomes that timeline of figuring out. Now, I'm going to talk to my stakeholders, I'm going to talk to the leaders. I'm going to talk to the decision makers and decide, hey, you know what? They can't really make this change right now. We're going to have to alter maybe your product schedule. Maybe we're going to have to do some other things. Here's the ideal world, sort of our happy path. And in this case, we're going to have to detour a little bit and go this way and push that out to a few more quarters, getting everybody aligned and making sure that they're all in the know. We produce reporting on a monthly basis for all of our active acquisitions that are in integration, and we also produce the report out to our board on a quarterly basis. And so those have to be very consistent, and we have to have very consistent and same sort of methodology side by side for each of the acquisitions. And again, some things may not be applicable in that definition of done. So those kind of come out of play. We just say, na, right, not applicable. These are the things that we're working on. Maybe you don't need services, maybe you don't need to do a DNS change. Some of those things may not need to happen. So then those kind of automatically come out and we say it upfront, and then we just say, here are the things that are coming up in the milestones, and this is what it looks like. What's left. This is what's left now to make this done.

I love it. One of the things I was going through my head as you're explaining this definition of done is updating this definition in your playbooks. Do you do that for the team or how do you collectively decide when to update the playbook with this definition of done?

Yeah, so we don't want to make it an administrative nightmare, but what we do is that after every integration, so we already have, like, checkpoints along the way. But once we're done, we feel like that we're definition of done. And we've done a, what we call like a handoff between us and a supporting team that's going to support going forward. We're done. Here you go. This is now your baby. Take them home and you can continue to grow them. We basically will then look at that, and then we say, okay, we're going to do some lessons learned now and let's get together as a group. So the acquired Team and us. And we do a lessons learned, and we talk about ways that we. Things we could have done better. What things we can innovate, which things that are gonna optimize some of this or things that we just didn't know about. Hey, we did that really badly. Let's figure out how we can do this better for the next one. And then from there, we can take that information. We can one, I call it our knowledge base to say, you know what? We incurred this scenario in acquisition A, and this is how we handled it. And so at least we have it in our knowledge base. But then it also allows us to basically go back and look at our playbooks. And again, that's why we don't want to make it an administrative nightmare, is when I get done with one, we get done with an integration and handoff. That's when we go back and take a look at all of those things that we said and then said, what can we improve? And then go back and make those adjustments to our playbooks and then publish them. We publish our playbooks to all of our stakeholders internally and our leadership so that at any point in time, they can look at that and they can say, hey, here's our roles and responsibilities. Here's our Daisy. Here's who's our driver, who's accountable, who's informed, who's contributing, and basically give them that opportunity to see it as well and add input.

I want to ask you about this Daisy thing because I went through my own career of going from racy to Daisy. Let me close out on this idea of done first, which is. Is it fair to say that once you complete the retrospective that is the instantiation of done and completeness? Yeah.

Okay. Yes. Really? Our handoff is our sort of. We're no longer doing anything right. We're like, we talked through it. But I will say that you're right, like, in terms of going backwards. And let's say we do meet with my business technology team who says, you know what? I'm not real comfortable with the application monitoring piece right now. I think we need to do a couple more things. So we may have to go back and fix that. Then after that, it's our lessons learned. And actually just having conversations today with some of my leadership. We want to go back now and revisit some of the past ones and talk a little bit more. How are you doing today? So that was a year ago. How does it look today? Anything you think we could improve on and what we could have done better, we're actually going to go back again and sort of pull our past acquisitions that we've closed out or completed and get some more information on how they're doing today.

I think that is a great best practice for audience to follow. There's just so much that you will learn more, whether it be a week after or even a month after. There are things that tend to bubble up even after you wrap things up. But I will say, though, for the audience today, one of the important things that you should consider is do not force being done. It has to be a natural progression from all the individuals in the work stream, all your stakeholders, that, yes, it's time to instantiate that retrospective in order to get us done. Don't force it. Where there. There are things that are lingering, there are unchecked boxes. That really isn't truly the definition of done at that point.

And I'll add a couple of things to that. There are two pieces that are more soft skills. One is culture and the other is having empathy. And when you realize that these are individuals who are now new employees of your company and it's going to take them a minute to adjust, remove their cheese, they're doing something different. They're being told that this is what you're going to have to do going forward. So working with them and coming up with a combined plan is super important. And being able to connect with them, meet with them, talk about the whys of what we're going to do from an integration perspective, get their feedback, maybe they do something better and really get input. And so that it's a team effort, so that it's not a because we told you so, because we bought you, it's more empathetic. And we think about how that fits with their culture and how their culture is going to have to fit with ours. So for that as well, in terms of being able to work with the required teams and their technology teams, we can be a little egotistical because when we are really good at technology, you know, you think that all of everything that you do is great. And so sometimes you have to be open to look at innovation. You have to be open and look at how things are being done differently. And I think that's the other things that I'm really key to talking to my team about is like, when we acquire a team, just be a little human, have a little empathy. We do have a job to do, but let's do it together. And I think that we can. By doing so, I'm going to jump.

Into this whole people centric M and a thing with you. But I want to stop myself because I want to go back to my prior deviation, which is this change from racy to dacy. So I'll admit, Wendy, I am probably a late transformer to the Daisy movement and once I was there, like I was totally into it. I really liked how it abstracted just that hard set roles, responsibilities, which tends to be a little bit too, may I say, just it's just it puts everybody like it to a level of anxiety. Whereas driver, contributor, informed. It's more interesting in the way that people engage because it's not so hard set. But from your career and your experience, Wendy, when did you start transitioning over to Daisy and how has that been for your career as well?

More recent we had a really healthy debate about Raci versus daci. Because of the seat that we're in, we work with a lot of our M and A partner teams. So whether that's legal or that's employer services, but just like our hr, whether that's our supplier or the procurement area, security, like all of those areas that we don't own, but we need to drive to make sure that we have those things done. Employer services is doing surveys and making sure that we understand where they're coming from and where they're at, what they're feeling, whether that is supplier team or procurement team, making sure their suppliers become our suppliers and or adjust to whatever supplier that we have for that service or licensing or what have you, whether that security then doing their part. So for us, it's like the driver. That's why the D became more important to us, because we're driving it and we're not really responsible for it. So they still have their job to do. There's still an M and A team associated with that integration. But for us, it's just more of a we're the ones that are reporting, we're the ones that are responsible for putting it all together and saying here's our we're done and handing it off. So that's why we chose. We went down the dacie path. Believe me, there was a very healthy debate along those lines. And some of it is about terminology, what people know and understand, what that looks like. But in every one of our playbooks, we have a DACI for each of the areas and we talk about who's responsible, we talk about all the players, we talk about what the outcomes are. We talk about basically here are all the steps to get to being done for that piece of work. Each one of those that makes it so great for in our playbooks that we have that. And then I can hand that to any executive and I can say, here you go, here's how we look at suppliers, here's how we look at the licensing, here's how we look at security, here's how we look at all of those things. And then like I said, some of them are easy, like easy peasy. This team can just rock and roll and it's not that hard. Some of it could be hard depending on the maturity of the acquired company. But for the most part we have those down and we work with them and we just keep close ties with them and work through our checklist or our definition of done. So far, I think it's great. I think we're maturing depending on the size of the acquisition and what the complications that go with it. And so those kinds of things are ones that we are perfecting and trying to get better at as we look at the larger acquisitions and the timeline. Because some of those we could be from nine months to something that's small, a tuck in type, or we could be two years to three years based on some of the larger acquisitions. So that also helps us determine what this looks like, but also gives us an opportunity to show the acquiring company here's what this looks like as well. To say, here's what the scope of this work is, here's who's responsible, here's how we're going to work together, here's our plan, and then we go from there. And then again we come back and say, how do we do to that? How do we compare? We do that. Lessons learned. How do we compare to what we started with versus where we ended and what changed in between.

I want to parlay off of this idea of the changes that you've been keeping current and up to date in your playbooks, because I think that's a really important point given that the we just heard from you, there's so much that you are updating over time. Could you give us an idea of how you're governing those changes? Is it such that you're doing it? You're empowering the teams to do it more iteratively, or are you waiting until the end when you're done? And then how do you just make sure that those updates are in fact valid and something that you want to carry forward?

So again, not to have an administrative nightmare because I want them to focus on integration and so keeping track of it as we are providing status again, we have a monthly update so all of our data is in one place so that we can go back and say these are things that happened along the way and we can at least have that historical record as well. But then we want to also go back at the end and then have that lessons learned and then we can go back. Because I don't want them to get into that cycle of I got to get a status and now I need you to update the paybook. I want them to focus a bit there and think a little bit more about it. But then we work with our partners who need to be informed, who are contributing, who are potentially responsible, and we work with them to say, okay, is this solid? Does this make sense? Do we actually have sessions with them? And we walk through the documents, we walk through the playbooks and we say to them, any thoughts? So it becomes collaborative. We actually share with them our documents. They can write and add comments and such. Playbooks were like, in light, like over the. Probably the last couple of years. So people had bits and pieces and parts that they added to it. But over this last year, we really solidified it and published. We said, this is the one playbook with everything. And now we're like saying, okay, what's next? When we get ready to do a V1.2 or 2.0 or whatever have you. But we're working through that with our partners to say, contribute. Like, we want you to look at it. So it's an open doc for all of those partners that we have internal. And then we start to share also with ones that we may have worked with maybe as an acquisition and give them an opportunity that to see and look at it as well. So I think it's collaborative. I love that part. We own it, we publish it, but make it collaborative with all those that we work with so that it is not just a view from M and A integration, whether that's corp dev, whether that's security, and any of the other teams that we work with that contribute as well. And that becomes our cycle of collaborative improvement. And. Or saying, okay, this is the next version. Publish that again, saying, here we go. But it's always a living document that they can all get to at any time.

The idea of it being a living document, that should be one of the steadfast learnings I think, for integration people is things change over time. Yes, a living document is a perfect analogy to that. And I also feel you've created your own Daisy accountable and the driver to get changes done. You have lots of contributors feeding into it. So now you have Your own version of a daisy. In order to keep things current as human beings and also as integration practitioners, we tend to add a lot. The playbooks get bigger and bigger, but over time they might get too big. Do you apply maybe like laws of subtraction to know when to take things out of your playbook so that your definition of done, instead of being too bloated, comes back to its normal form?

Two things that come to mind as well. One is the fact that if I laid out this whole playbook like our whole definition of done, all the things that can be very overwhelming for a new acquisition. And the other piece is that typically when you have an acquisition, you probably have a few people that do this tech job. And so then you may have multiple ones of Salesforce team buying for their time. So being able to think through that too, in terms of how we kind of impact them. Second is just showing them what that looks like and trying to really hold their hands through it in a way to say, here's what this looks like, but let's talk through what that really means for you. And back to our why. Let's start with why we need to do these things. And then we start to say, you know what, maybe you don't have to worry about this DNS thing, so let's pull that out. Hey, you know what, maybe you already are on this version of Slack, right? Maybe we don't have to do that. Like, maybe you're so all of those things that like, already, they're like, oh, we're already doing that, or it's a quick win or it's an easy plug in or what have you. Then we can say, let's take those out. Let's not one get caught up on the process and let's be logical about it. Let's look at this and say, you know what, we shouldn't do that. And that was also back to my example of timing. If you've got acquired company that has commitments to their customers, customers, we have to think about that too and factor that into not causing change or chaos in the middle of that. Unless that product strategy is different, we need to make sure that we stick with that and help them how we get to that place. So maybe it is a, you know what, we're not going to do that. We're going to pause that and that may not happen until we're going to take that on after integration. Your supporting team is going to own that going forward and we'll be like, okay, decision, let's make sure we got all the right people that made the decision and call that out as it is and reported that stuff such. And then say, you know what, we're not going to do that piece at all, let's just pull that out. Or that doesn't make sense for them right now. So that's the way we subtract. That's the way that we are able to go back and look at it and say, let's pull that out, not right now, or let's get them through this piece. They got to move forward. You're going to move forward. Their supporting team, their business technology, their cloud team is going to actually own the rest of that as a part of their strategy and product plan. And so we'll go that route really becomes more decision making. What's the right thing to do for the business and then just being logical about the timing and what happens.

Logical is a premium in some cases.

But honestly, on our, on our dashboard that we report out, there are pieces that we just have not applicable. Like we just pull those out and say these are side by side. Again, if you look at all of them, it's like these things are not applicable. So we just pull those out automatically. That it's not so overwhelming and we don't expect them to do more things.

When you're working with company that's just recently been acquired, when you say NA here or NA there, do they have input as to when it's na?

Yes. So one of the things is trying to get in front of it and saying here's all the things. And then when we say, you know what, this is not applicable to you because you don't have X. This doesn't make sense for you because you don't do that. So maybe they outsource something. Maybe there was. We don't have to do that. And so that becomes a piece of the. Let's be combined. Let's do a combined effort on what that plan looks like and what sensible.

Like the sensible part?

Yeah.

Logical and sensible. Two key words Today, everybody.

And I am all about brevity. I'm all about if you can get things done faster, if I can have a meeting faster and we can quickly get that done. And you concentrate on your work, you concentrate on the things that you're good at. I want to keep you out of meetings. That's my whole mindset. As someone said to me once, to be brief, be bright and be gone. And so I just want to make that happen. I think the faster you do it, the faster you do integration. I Think the more money you save, you're better off by doing the best you can to speed up most of this stuff. And that's something else that we're working towards. As we look at scale, we're also going to look at speed. We're going to try to get things and as we improve, so we got to be able to show some improvement over time, not be stuck in the same thing you've been doing for the last 10 years. And I'm very competitive and my team knows this. So we are. I'm like, how are we doing metrics? Let's talk about metrics. Let's talk about what that looks like.

May we go over to this idea of scale for a moment? Because I think that is a really interesting topic for practitioners like ourselves. Having done integration for many years, I find that sometimes the definition of scale is get done what you can with the people and resources that you have. And that's fine given, you know, I probably set my budget at the beginning of the year and that's the budget I get. But over time, we grow and we build our own organization. For yourself and Wendy Nicholson's organization, what does scale look like? Especially since you hold the reins around tech and product, which tend to be the longer tale of a comet, what does scale mean to you and how are you addressing those challenges with scale?

Obviously, I have a set number of people on my team, set things that different people do. One of the things that I thought about was capacity and I think about the number of deals that we might have, the types of deal we may have, the number of people it may take to do some of these things. And how does that look? So one of the first things I did with my team and I was like, I'd like to create our own Kanban board and WIP limits. So I can say in due diligence, how many tuck ins can I have going at the same time? How many adjacencies can I have at the same time? How many new cloud items can I have at the same time? But basically be logical to say I've only got this many people that can do due diligence. So really I'm going to go to corp dev and say, it's going to be hard on me to scale without bringing people on, without really staffing up my team. I don't want to build up a team that it doesn't make sense to have that many people staffed. Let's be focused. There's opportunity for me to bring in incremental. I would rather the incremental be arms and legs being people who can do more work there. But I let my subject matter experts be on the front and then I can talk about how do I scale. Then if I get to a place and say like that m and a engine like just cranks up and starts moving really fast, that's where I want to be. I want to be able to scale my team that way versus trying to say, okay, I'm going to overwork. Everybody's got to work so many more hours. Everybody's got work every weekend. You know, we're definitely all about balance. And so for me it is, I'm already, I'm going to be screaming like, I want to make sure that my team is taken care of and that we're doing the right thing and it's the right focus. For me, the scale means more about as we get bigger deals, what does my team look like, what does that ebb and flow look like? And then be able to say yay or nay. Or we basically go back and say, okay, you know what, this may take longer. Let's be realistic. If you think about agile and you think about how long it might take, here's my team, here's my we have limits. Here's really our velocity of what we can really get done and let's be logical about. So for me, that is there. And if I can forecast, which typically it's not, I'm not going to get that much time. How many acquisitions may be coming my way. That's my happy path. If I'm able to get that and then I can back up as I need to. But I would prefer to do it incrementally and make more sense about it so that we can support the business and we want to be able to do that. That's how we grow. That's another part of how we grow our business is through acquisition. So that's where I look for when I think about scaling, is being able to do those things. And if I can take away some of those things with incremental headcount, let my subject matter experts and the trusted advisors that I have do the jobs that they do, they do it well. That would be my idea of how I can help support the business in that way.

I'm going to ask you something about something I've experienced in my past career as well, around scale. Every once in a while when I'm going through integration, I'm looking out for the next best possible talent that I could bring over to my team. The idea Being good integration people are hard to come by. Do you subscribe to that same philosophy yourself and has it worked for you?

Given that I didn't grow up in M and A, I came to it later. So it wasn't like I had this long history of a Big four consulting type role.

Now you're just picking on me.

I'm a studious person too and learning is one of my other superpowers. Competition. I'm competitive and I like to learn. For me, it's like a lot of the folks on my team do have that kind of expertise and I think when I need that on the front end, that's where I'm going to go to. Alternatively, I have been looking at opportunities to say, you know what, I'd love to have my team having a little bit more stagger, like a little bit more steps of opportunities into M and A. So people don't get introduced into M and A. Most of the times when I was in meetings, never saw many people that looked like me. For me it's like, why don't we start with some interns, let's do some coordinators, let's do some kind of project coordinator types. And that would give people at least an idea, an opportunity to learn it and understand it earlier on and grow into it. So I would love to have some opportunity to have people grow into M and A leadership type roles and educate yourself, get where you need to be, you can get to that place. But definitely it takes some work. Learning more about valuations, learning more about due diligence. What do I look at? How do I study this? What kind of things I should know when I think about an acquisition? So front end, back end, whether that's on the due diligence side or the integration side, really understand it holistically and that will help you grow. It also gives, like I said, well, rounds my team so that we're not all at the very same level like we have people and that we give people an opportunity to grow as leaders as well. So that's where I want to really take my team to, that's my future hopes and dreams, is to be able to really stagger my team a little bit more in terms of experience and levels.

That's great.

But when I need the lead, when I need that core lead person that really is going to understand it can help and drive and help me as well, then that's where I'm going to go for the most part.

I think that's fantastic. It's so delightful and refreshing to hear that you're watching out for, building a team with well rounded experience, well rounded knowledge. Many times when we get moving incredibly fast inside integration, we're just pigeonholed into what we think we know or what others think we know. And so that's all we ever end up doing. But let me tell you, there are side conversations that people have to say, what are you doing over there? And is that exciting? And maybe can I intern with you a little bit? Or can I shadow you like unofficially? And it creates this nice network of folks wanting to learn from each other.

Oh, absolutely, yeah.

If we could continue to instill that in any organization that has integration teams, I think that is just so much better for everybody.

I think it takes away the mystery because I think that there are a lot of times people really don't understand what it takes to integrate an acquisition. I am evangelizing as much as I can internally and sometimes externally. If someone says, oh, it's a two person company that you just bought, that should be easy. And it's like, not really. We still have to go through some of the same checks and balances for a two person team versus a 600 person team. You still got security. So some of those things may be even worse because you only got two people. They may be even worse because they do the bill paying and all the bills are on the corporate card like licenses and such. And so you have to really tell people, oh, that should be quick. And I was like, no, it still takes a little time to do some of these things. It may be a little bit faster because it's two people. Sure. But there are a lot of things when it comes to systems and, or tools and, or cloud or on prem or what have you that we need to think through and what that looks like, whether that's a server on somebody's desk, which I'm sure we won't do that. But in terms of being able to acquire that technology and be able to make sure that it's on our platform.

You and I, we're going to go on a roadshow.

Okay.

We're going to go out there and be like, everybody needs to grow their IMO teams by 15%. Do it now. Start scaling.

Right.

Are there any thoughts about the future integrators out there, the integration practitioners? What would you give them as words of advice or words of wisdom?

My words of wisdom is I think I told you a little bit about having empathy, understanding a culture. And I think that relationship management is super important with those acquired team members. So get your stuff together. You got to have your plans together and be able to talk with them about the why and then work together as a team to make it happen. So for me I think that goes a lot easier. I think it may go a little faster, that the relationship is great and then it's just more of a we're working together, we're improving together and it happens a lot faster. So for me those are things that are huge. Obviously we need to be technically savvy to be able to handle some of that and get the right people in the room. But I really put my eggs in that basket of having that repeatable process, having those playbooks and then just showing that empathy as you work through your integration plans.

Lovely for Wendy Nicholson. And you did mention that you didn't come to M and A in a traditional path, but now that you are in M and A, tell me about like the craziest thing that you've seen in M and A so far in your career.

Sometimes in your head you think that should be a no brainer and something as simple as licenses. Let's say the craziest thing I've seen is not paying an electric bill even though we dump back to being driving like say the supplier and or accounts payable, accounts receivable areas. We don't own that but let's say we didn't pay a bill, say utility bill and let's say that it turned off all of the power in a building that had on prem servers and telephones and printers and Internet and all of that. So the craziest thing I've ever seen was that having power turned off into a building that had on prem and network and such and yeah impacting lots of people at work as well as potentially revenue because of the on prem service. So that was the craziest thing that I never would have thought I had to deal with something like that. Would that be my responsibility? No. But I need to drive that. I need to make sure that that's happening. For any of those type of things. I always go back to what do we ask? And due diligence and is there anything we could have done to prevent that from happening? Everything from knowing the maturity of a team and how well the processes are documented and or in flight and then being able to make sure that those kind of things don't fall to cracks your mind kind of switches a little bit to try to figure out how do we deal with that? What should we do? What should I ask? I do that with even with the agility of a company, ask those questions. Like if you tell me you're an agile shop, like what's the maturity of your agile shop? And so that we know how much more work we might have to do to get them aligned. So the same thing with things like suppliers, same thing with legal licenses and such. All of those things that we have to think about in diligence to say, is it going to take us more? Do we need to be more involved? Do we need to jump in? What does that look like? So for me, it's that realization that that is something else you need to think about from an M and A perspective. Again, because I didn't grow up in.

It, there is so much that IMO's pick up over time. We're kind of like the bucket for a lot of things that just tumble through an acquisition. For example, I've been an interim CIO just because somebody wasn't there to go resolve like data center problem. I've also been the staff psychiatrist many times as well.

I understand that one. I understand that one.

For the audience today, I would say there's just a lot that goes on integration and having heard a lot of what Wendy's talked about around IMO efficiencies, hopefully many of you take that with you as the next conversation, if you will, to evolve your department. Wendy, you've been a delight. Thank you so much for your time today. So much information from logical, the sensible, the empathetic. A lot that everybody can take away from today's podcast. Thank you so much. We really appreciate your time today. Everyone. Please join me. Thank you. Winnie Nicholson at Salesforce out of Atlanta, Georgia.

Thank you so much.

Thank you for taking the time to explore the world of M and A with our podcast. We love hearing feedback. Tag us on a LinkedIn post, add a review on Apple Podcasts. We'd love to hear from you. If you need help standing up an M and a function or optimizing one that you already have, we're here to help. And if we can't help you, we probably know someone that can. You can reach out to me by email Kison K I S o n a science.com or you can text me directly at 312-857-3711. If you just want to keep learning at your own pace, visit mascience.com for a lot more content and resources. That's where you can also subscribe to our newsletter. Again, that's mascience.com here's to the deal. Views and opinions expressed on M and a science, reflect only those individuals and do not reflect the views of any company or entity mentioned or affiliated with any individual. This podcast is purely educational and is not intended to serve as a basis for any investment or financial decisions.