Accelerating M&A Integration

Hello M and A Friends. If you're looking to improve your in house training, we have corporate training plans provided through the M and A Science Academy. Give your team members access to the best in class courses, templates and networking opportunities in the industry. Our Academy was designed to lead practitioners with the how to of M and A practices. If you're interested in learning more about individual or team plans, go to mascience.com academy. It's also a great way to show your support for M and A science. Again, that's mascience.com academy. Onto the interview I'm Kisan 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. Welcome to M and A Science where we curate knowledge from the best in M and A to continuously improve. If you're interested in keeping up with the latest from M and A Science, subscribe to our free newsletter@mascience.com Every week we share highlights from our interviews, invitations.

To events, M and A role openings.

And other resources as we build the greatest community of forward thinking M and A practitioners. Again, that's mascience.com I'm your host Kisan Patel, CEO and founder of M&A Science. Joining me today is Carolyn Jones, Senior Director Acquisition Success at Cisco. Cisco is a technology conglomerate that specializes in a bunch of things like Internet of Things, Domain security, video conferencing and energy management with leading products including WebEx, Open DNS, Jabber, Duo Security, Jasper. Let's not forget AppDynamics traded on NASDAQ under CSCO. Today we're going to talk about accelerating M and A integration. Carolyn, how's it going?

Great, great. Thank you for having me.

Thanks for taking the time.

Yeah, happy to be here.

Can we kick off things with a little bit about your background?

So I've actually been at Cisco 17 years and most of my career was spent in supply chain. So I spent 15 and a half years technically in supply chain in a variety of different roles. So I did some sourcing work manufacturing some NPI launches and then spent some time as well in kind of our transformation area. How do we launch different initiatives that are going to be needed for our business? My last role in supply chain was leading the supply chain integration. So that's how I got into M and A was doing that role in supply chain, fell in love with M and A and so from that role in supply chain ended up rotating in a broader role across operations, which is the role I'm currently in, leading the what we call acquisition success team. It could probably mean a lot of things to people outside of Cisco, but really what that scope entails is the vast majority of all the operating scope for the company when it comes to integration. So everything that comes related to bringing offer and product to market, operationalizing those requirements of the offer of the product, fulfilling it, as well as our customer experience. Integration. It's a pretty broad scope, but it's been really exciting to be able to be part of M and A Cisco.

Yeah. You guys do a lot of deals over there?

We do. We're upwards of 2:30 now. They keep us busy and those are all the ones we've announced. There's been plenty of deals we've worked on and for good reasons have not necessarily moved through. So the number of deals we work on is bigger than that and it keeps us busy.

Your background's interesting because your undergrad you did industrial engineering.

That's correct, yes. I have my bachelor's in science and industrial engineering and then I got my MBA as well.

Then you ran the run through supply chain roles. Now you're M and A integration. Any dots to connect between those experiences?

Industrial engineering. I picked that major for my undergrad because I liked the engineering side of things, like how things work together, how do you solve for problems. But I was also very interested in business and just what matters in business, what really moves the needle and makes a company successful. M and A is really a combination of both as well. I learned a lot about supply. Imagine I got my feet when operations really understood what it takes to run the operations of a company in a critical piece of it and then was able to take that background and apply it more broadly now to how we run operations at the company. So yeah, I think it's maybe unusual background, but it all connects in and makes a lot of sense for M and A as well.

You know how things work.

Yeah, exactly. I know where things can break and implications downstream for sure. And so it's helped to understand like what are the things we need to really keep in mind up front in the process as well.

What does acquisition success mean?

Acquisition success really comes down to when we acquire a company, are we able to successfully harness the value for which we acquired it. And that's obviously a really broad statement, but I think it comes down to that integration's a huge part of that. If we integrate it successfully, that is the goal, that we're able to achieve that value and then that we're able to scale it even beyond what we expected. But that's not a simple task. A lot has to fall in line and there's many challenges along the way for any one deal. And really that's what our teams are working through is to try and figure out how do we get the best value we can out of the deal that we acquired, making sure we don't break the company that we acquired and then that we integrate it into the way that's going to be successful to maintain the value that we acquired and then hopefully scale it beyond that.

How do you accelerate M and A integration?

A lot has to go into accelerating integration. So that's definitely one of the things we're after. Most of the time when we have a deal that comes in, the engineering team that's sponsoring a deal, we'll want to integrate that company in and like tomorrow, right as soon as the deal closes and get them integrated. And so we could scale kind of the business and be able to get some of the value for which we integrated it. But that's not a, that's not a simple task. A lot has to go into that to really be able to do that as quickly as possible, especially in a company the size of Cisco. So a couple things come into that. First and foremost, when we look at accelerating a deal, there's a lot that we try to do in the planning phase of the deal. So as we go through a pre commit and commit phase to determine whether or not we're really going to move forward with a deal, we're trying to really parse out the strategy behind integration. As I mentioned, like what is the value we really want for this, that we're trying to preserve for this deal? And beyond that, what is the strategy around the integration that's going to help us achieve that value? A lot of times I would say historically we would not be extremely clear around like how we were going to do it. We said, well, this is why we want by this company. But the integration plans and solutions were really undefined. And so what would happen is we'd announce a deal and then we'd start to figure it out. And again, that would take us a while. Right. And so what we've tried to do to look at accelerating how quickly we integrate a number of these companies is to try to do a lot of that planning upfront and really scenario plan around if this is the value we're trying to achieve by acquiring a certain company. First of all, do we understand this strategy across all the key stakeholders are we aligned with that strategy. Where do we see risk in the integration? What's going to be the plan to address that risk? What are the different kind of solutions that we anticipate now? We may have a couple that we need to work through and that's okay, but at least getting those kind of solutions and different options on paper so that we understand implications and the requirements as we move forward. And the idea is really that when we get to announce, assuming that we can go ahead and execute right away, we've already done a lot of that work and we kind of can hit the ground running day one and really start that execution right away.

So I got planning the value to preserve, having clarity on that. And then you're shaping the strategy of integration, including mapping out risk. Does any of this happen pre loi?

Yes, quite a bit of it. This is where we have a lot of back and forth with often the engineering teams around. Do they plan to incorporate the company requirement into the existing portfolio that we have? Do we plan to stand up, sell it alone as a standalone? Do we plan to continue to leverage existing route to markets? Are there expected to be changes around that? If we do want to incorporate into our portfolio, how quickly do we think we'll be ready with the technology integration so that our sales teams are really in parallel ready to sell it as well. And so all those things have to work a parallel and to like a joint strategy to make sure that when we're ready to execute, everyone's on the same page around like what we're driving to.

Can we role play that out? Just do I want to make sure I don't screw it up?

Absolutely.

I'll be the head of Corp Dev. I'm always anxious to do deals and we identified this target. You're my point person for integrating this company. I see something I want and I'm eager. So I want to get an offer on the table as quick as possible. There may be some outside pressure. Maybe a bank's running the process and it's competitive. So you know, my motive and drive is to get something to an offer table as quick as possible. But I don't want to look bad. I don't want the board to bring this up next year. And what about that deal? I'm looking for precision in my offer to make sure we got the right consideration about what our synergies are going to be realized in any of those big capital expenditures. I don't want to miss and be talked about next year. How do we work together? Like what does that look like I'm approaching this company. Maybe I've got some of the conversations and now we're getting some information from them. Is that when you typically looped in?

Yeah. As soon as we feel like we're ready to start moving forward with kind of ideals is when typically the integration team will start to get involved. Or anytime Corp dev wants to do some scenario planning or understanding some of the risk as well, they would pull us on. And so I would say kind of step one would be back to the value that we're trying to acquire. Like why are we acquiring this company? Is it because of the talents, the IP synergies with our products? Really understanding like what is the reason? Maybe there's more than one. Right. But really understanding like what are the reasons for acquiring this company? So that's kind of step one and making sure that there's clarity there that also helps us to understand what are the pieces we want to preserve and not break then tied to that. How do we plan to really integrate that company? Is it something that we're going to leave standalone? Is it something that maybe plays into our existing portfolio? So we plan to have some type of product and technology integration as well. Also trying to vet out some of the timelines, how quickly we're trying to do this. Are we ready?

We're still pre loi. Right. I just want to make sure.

Yes. And some of this can move in parallel. There's some back and forth and can move in parallel. But this is all prior to announce. Well ahead of announce for sure.

Yeah. I still want to get an offer to the table as quick as possible.

We're talking at high level. Right. So that what are the big items that you're going after? And we've obviously done a number of deals at Cisco, so a lot of this we know the plays that we would run and then we know where some of the risk lies. So just understanding what kind of what's the nature of the deal? We know where we're going to have some of the challenges and what are some of the considerations we're going to have to account for right away?

Well, let's say in this situation it's a product play. I'm selling our deal room business line because it's some unique security offering they don't have in their portfolio. They realize that. How does that extend into shaping your integration strategy? In just that example, does it cascade to. Here's a templated plan that we already have that's focused on this strategy. Is it more of here I have A good sense of what stakeholders I should get involved now?

Yeah, absolutely. Kind of the nature of the deal will dictate which stakeholders need to be involved and which ones really need to sign off. And it's part of what we'll do. Right. Once we get a sense for what's the value we're preserving, what's the strategy we want to leverage for this and what's potential solutions that we think are going to be viable for this integration, then we'll need some of the execs as well to sign off on it. And again, we'll do this a lot, lot of times in parallel with our commit process leading up to announce. But we'll make sure that part of what our team does is trying to make sure that we pull in specific execs that have a stake in making this deal successful. If we feel like there's a really big component, maybe for example our IT systems, we're going to need certain capabilities to really make this integration successful. We'll pull in our CIO and make sure he's aware of what's coming, that we have his blessing kind of support to make this happen with the timelines and milestones that we're committing to doing it by. And this is all prior to announce as well. So that again, day one post announce that execution really can move fast. We have this team already pre approved to support these requirements and we can start the work on the execution right away.

Okay, going back to head of Corp Dev trying to get right to LOI and then get into confirmatory any deliverables I'm getting from you to help make my offer with full confidence?

Yeah, absolutely. A lot of times we'll do some type of like risk assessment right across the whole company so that there's an understanding of where do we anticipate to be, what are going to be the functions that are going to be really heavily impacted by this deal and where do we feel like there's going to be some risk based on the nature of the deal that exists and what's the level of risk. And so that's a lot of what goes into our commit processes really highlighting the biggest risk areas so that there's an understanding of what would be the trade offs we're willing to make and that we go into negotiation knowing all the risks areas as well. That is very much something that integration team pulls together is a whole risk analysis across the entire company and then.

The part about feeding into synergy model capital expenditures, where does that come in?

So we'll look at all that as.

Well still pre loi or is that.

Yes, it's all through our commit process as well. So prior to agreeing before with a deal, this iterates over time. Right. So we start out with a big picture and then we refine it and iterate as we get more information. But we'll look for areas of synergies. We have a pretty big team at Cisco, Right. That supports integration and everyone is experts in the areas. So we can run very quickly across the whole company because everyone knows like what they have to do and how they have to assess a deal across the company as well.

How long does that take? If I were to put a stopwatch in time, it is that we're talking like zero to a week.

It could vary drastically and a lot of deals have different speeds that they move at. So we've had deals where we get a couple days to do this if.

That before they announce IPO or something.

Yeah, exactly. So that really sensitive deals where we just don't have and very few people are involved. And so those are obviously more challenging because you can only have a couple people involved. So you really pick your experts and who are the people who can run really quickly on their own on these. And then we have deals that tend to take a drag out for a long time so that we have a lot of time to iterate on it. It could be months that we're in the status of figuring out what's the best strategy opportunity around integrating those companies as well.

So you got your internal commit, then you get the offer to the other side, the approvals you talk through. There's a number, it sounds like you have a specific committee.

Yeah, so in my role I'm helping to represent a lot of the operational requirements. And so what we do, our main commit process is what we call our CFO commit process. So it's really goes to a CFO for a final sign off. But in that meeting we have key execs included as well, depending on the nature of the deal. Again. And so when my team invest and we run kind of in parallel and leading up to CFO commit, we run a COO commit process. So this is where we're looking across all of operations, including customer and we review with our CEO what are going to be all the different implications of a deal to operations and customer success and customer excellence and really understand what's going to be the impact and what's going to be required. Again, what are the risk areas and make sure that we have alignment within all of operations. To support that deal that's upcoming. Right. This then all gets funneled up and summarized into the CFO commit. So it's almost like you have a CEO commit and then leading up to the CFO commit. And that's one way that across operations we can make sure we have IT supply chain security. I mentioned customer excellence and really also some of the teams driving different initiatives. All the requirements are accounted for and signed off for that commit.

What does it look like when you deliver it? Is it like a 10 page PowerPoint or are you sending them a whole bible?

It's to the point, here's what the deal is. Here is again the value that we see behind acquiring this company that we want to preserve. And here's what's required of the the COO community. What are the functions that are going to be required to support this deal successfully? It's a T shirt sizing around. We expect this team to have like high level of impact, medium or small for each of the functions within the operations. And then based on that we look through the COO commit to have their sign off that yes, they will prioritize the resources required to do this successfully by the milestones that we're committing back as well.

Okay, then you take that once you get approved, get your offer out there. Well, negotiation with the deal signed. Confirmatory diligence. Yeah, exactly, signed. What goes on there? I'm always curious about the balancing act because it sounds like you already got some integration thinking there. The sense of the strategy and think what it's going to take and operational impacts, how does that progress in diligence?

We're really focused on anything that would cause us to not do the deal. So we're not going through discovery yet obviously, but still really trying to understand out of the risk areas we identified or maybe some of the areas that we don't have any visibility to that could potentially have us walk away from the deal. Are there certain areas that we want to double click on and that's really what we end up spending our time and diligence and then assuming that things check out, there's that final sign off with the CFO and then we assume we're proceeding to announce and an execution.

I had two questions. One was around the integration planning. Is a lot of that stuff going on, does it happen continuously or is that sort of saved up between announcing and close?

No, a lot of that starts as soon as we get engaged. So as soon as we get any of the my team gets engaged or I think any of the other Functional leads get engaged, the planning starts right away. We start to really start to kind of scenario, plan, understand the different implications of the deal. So as soon as anyone's under NDA, that's typically where the planning starts. Now obviously we're limited in what information we can gather and the access we can have to the potential company that we're looking to acquire. But the planning starts as soon as we get under NDA.

Okay, what about with the target company? What can I learn from you to make sure that doesn't get screwed up?

We have to tread carefully when we engage with the target company. First of all, Cisco, again as I mentioned, it's a big company. We tend to sometimes overwhelm a company with disar size. So we want to be very mindful of like how even diligence, we don't want to show up with 50 people to diligence when they have four people in a room. So we're very mindful about how to kind of approach any of the interactions with the targets. And we do a lot of one sided planning. Corp dev ends up sharing a lot of the information they have with kind of the central integration team and that gets kind of dispersed out to different functions. And then we're very careful about if there's going to be an engagement, who really needs to be there, what is the purpose of the engagements, what are we really trying to solve for? Is this the right time to solve for that? Do we think it could create risk in the deal negotiations? And we're really careful about who's involved in those engagements and how that's managed. I'd say there's a lot of behind the scenes work that happens. There is often an army behind the people who end up engaging with the targets. But a lot of cross sharing information. We have webex teams and so we have webex team rooms that are set up for a specific deal where everyone's collaborating on kind of information they know. So that really cross sharing across all the teams that are involved versus having multiple people ask the same questions multiple times. That's something that's worked for us very well, but it's something that has to be managed carefully.

Can you tell me a little more of like structures of those teams? I guess that's a whole other element.

We've gone through evolutions over time. The way that we're structured now more recently is we call it a kind of a pillar model. And so the way that we're set up, you have instead of functional teams, you have broad organizations, you have a team that's looking at kind of operational requirements. You have a team that's looking at the customer excellence requirements. You have another team that's looking at legal, tax and finance. You have an HR team and you have a go to market team that's looking more at sales, marketing and our partner motion.

That's not 17, 18 functions I counted there.

Yeah, exactly. It's five or six pillars, depending how you're counting. And then you have the horizontal one that ties all those together. But that's the intent is that we've simplified our functional model to really align to some of these bodies of work that all companies will have so that when we engage with them, it's easier for them to understand. Like this is what these five functions do. It's all under HR, it's all under operations, versus having 17, 18, 20 functions reach out to them all at once. And it's nuanced pieces of how they're set up. So that has simplified our engagement significantly. And then what we do on the back end of that again is on our side, we know who's who within that big pillar and we know who's leading the effort for the pillar and how do we all engage within the functions and across the functions to make sure that we're accounting for all the requirements.

Still, when I hear from integration leaders that follow the traditional model of functional based work streams, I often hear the negative consequences is a lot of redundant work, a lot of redundant requests to the target company. Sometimes it has to be manually managed to help them. What value do you see when you move to that fewer cross functional team modeled around those drivers? I'm wondering. The other thing besides redundant requests is mapping dependencies. And I'm assuming that because you're tying more groups together, they should be talking about it a lot more. You don't have the throwing stuff over the wall all over the place.

The example that comes to mind for me is around procurements. If you look at how we're functionally organized when it comes to procurements at Cisco, you have about five teams that will touch direct and indirect procurement. Five functional teams. If we were to acquire company and it's a smaller size company, often you have a couple people who are running procurement on their side. They would have to engage if we were in the functional model with five different teams. And these are like big organizations on their own. So it's just overwhelming. And again, if you're talking about indirect, it's probably one of those functions. But direct has four or five different functions that are Doing kind of pieces of the work, it just becomes really overwhelming. This pillar model has really helped us simplify the engagements so that we understand who's really on point overall. It's also helped us step back as functions and say really, at the end of the day, what matters. If we look at procurement integration, we're trying to get to a point where we can really commission the legacy systems, obviously make sure that we're moving over the process into our standard systems and tools, and then that we can decommission the legacy procurement processes and systems. And so that's the goal that we're all after when we're integrating procurements. And so that's what everyone needs to keep in mind. And then how we work through it is something the functions are more used to doing on their own on Cisco. But again, it could be very overwhelming for anyone that's coming into Cisco to have to deal with all the nuances of what function does what and how they work together. So it's a lot easier for us to manage it in terms internally and have that engagement be to the acquired.

Have you seen the difference doing it the other way versus this way? People don't acknowledge the difference unless they. Because most people haven't lived in it.

I was in a role leading supply chain integration. That's when we were scoring through the shift. And change can be hard, right? So initially I think everyone had. It was hard to go through the change at first because it was. In a way it was easier to say, well, I'm just responsible for what my function does, period. And if it's my function, I'm responsible. If it's not my function, I'm not it. And so that was easier in some ways as we've evolved and people got over the change curve, I think there's an understanding for again, the bigger picture and how unless the teams are really working together, we can't get to the same end goal. There's an appreciation too for how much simpler it is for an acquirer to work with us when we keep it simple. We're still working through it. There's still a couple areas that we.

Need to improve a bit there any big value outcomes? Did you feel you moved through integration faster, more efficient?

The things that became very apparent quickly were one, around engagement with acquirer just seemed to be much simpler. Two, I think you just didn't have an army of people for every meeting anymore. This is going to be an HR meeting. You didn't have to have all the functions involved in every single call Anymore. Those were some of the quick like telltale signs right away. I think what took us a little bit longer to work through was who's going to represent the bigger umbrella. And that took some kind of negotiating and working through. But over time as we've done a number of deals, that's become more apparent as to who can play that umbrella role across functions.

Do you also get involved in pre diligence to inform your integration plans which we talked about? How do you go about this when not a whole lot of info is disclosed?

Prior to loi Sometimes you don't know everything, right. Sometimes you're still trying to figure out and sometimes there's things you can't know. Obviously what we try to do is we do scenario planning. We try to understand what are the different implications, different solutions based on the things we don't know. So we do that scenario planning and then based on different scenarios, we try to plan out the different solutions that could be required and we keep those scenarios upfront and ready and sometimes we even vet them out with the exec so that they know, hey, it could go these different ways and this is what's going to be required if this is the assumption that gets confirmed. It could be very different, very different timelines, very different milestones if this assumption is flips the other way. So we try to do that to help us navigate through when we don't know for sure all the information we would need.

Big gap in the industry. There's not a lot of standardization on programs and how to really think through some of this stuff. And prior to loi, that's like the big mistakes are the oversights. When you sign for something and it's like buying a house, you kind of, yeah. Contract and then yeah, you got to replace that roof and it's going to cost you a hundred thousand dollars.

Yeah. And I guess you learn from past experiences too. We've obviously learned over the years with all the different deals we've done and we do a lot of incorporating best practices into our playbooks and so forth. I think one area that we've learned as well, we've gotten much better at is around just kind of data quality. Historically that was maybe not as much of a focus area for us, but we're spending a lot of time not really understand how are we capturing some of the data is going to be critical for the assumptions that we're acquiring the company for. Right. So if we're projecting certain revenue synergies, do we have line of sight to some of those numbers? And some of that data. How are we keeping customer information? What's the way that the companies are capturing that data? We've had some surprises in the past and so I think that's one area that we're definitely keeping an eye on as well. And it's part of our due diligence. Not necessarily looking at data, but understanding like the quality of the data.

There's a lot of knobs to turn and change.

Yes.

Pure execution of integration. How do you accelerate that, the actual execution?

When we get to the other side of the announcer and we're ready to execute, it's really important to have is everyone clear on what the plan is, what the strategy is? Is everyone running in the same direction? Understanding, making sure that the people that are running the execution know how to do it, that we understand what are going to be the different maybe roadblocks along the way, that we're staying ahead of those roadblocks. That's where the leadership is required to really help remove those roadblocks as we get close to them, but that we anticipate them first and foremost. Right. And try to address them as quickly as possible. The integration piece too. It's one thing to accelerate the integration and again in operations and my team, a lot of the work that we do is around enabling the offers to make sure that we're ready to sell a product that we acquired through Cisco. However, that's only one part of the success I would say that enables obviously required. But you also have to make sure that sales is actually ready to sell the product as well. That the right incentives are in place for sales to sell it. Unless the go to market teams are kind of in parallel ready and geared towards the same milestones, it doesn't really matter how quickly we accelerate the execution. On our side. We could have offers ready and product ready to be sold, but it really takes the go to market teams being ready as well for integration to be.

Successful overall, big time. Having strong leadership there. Look around the corner, removing the roadblocks ahead and then thinking through this whole go to market. Because ultimately team's gotta be aligned around this combined customer experience.

Exactly.

Given the pace of acquisition, what does Cisco look at through integration? Equity value or enterprise value?

It depends. We have a lot of different types of deals. It could vary. The strategy could be really different on the number of deals that we acquire as well. Again, that's where Corp Dev is working to figure out exactly what's the intention. And that's where we'll push Corp Dev as well around what's the value we're trying to gain?

Absolutely. Might be in a similar vein too about integration model of merger measuring revenue synergies and cost synergies.

How do we measure those? A number of different ways. When it comes to the revenue synergies, we try to project out like we look at what's the existing company's revenue we look at if we intend to incorporate that into our existing portfolio. Where do we see the synergies connect in and what's going to be the revenue plan beyond that, do we feel like that's realistic? We have our sales leadership really closely involved to vet out that they feel like that is something they're confident around, that they feel like they can scale. Do we feel like there's going to be any kind of attrition issues with the existing with the acquired sales team? Those are all things that are required for that revenue synergy to work on the cost energy. We try to understand where they lie. When I was in the supply chain integration side, we had a couple of deals where I was approached and saying hey, if we do this deal, I think we can get some great cost synergies on supply chain front. And there was potentially some cost synergies but that would especially like on the pyramid front. And there's definitely opportunities to leverage some synergies there. But that is rarely the reason we would do a deal. It wouldn't be because of the cost synergies. And so it's more around vetting out what those numbers are. But really also be mindful not just the cost synergies, but also of the cost cost of integration that is typically significant as well. We have a really deep supply chain and it's not a simple task to integrate them into supply chain, for example. So again a lot goes into that analysis and we try to really vet out the numbers. If there's cost synergies around, where do we expect to get them and are those valid as well and do we have again, if they are significant cost synergies, making sure we have the stakeholders who are experts in those areas vetting out those numbers prior to announce.

Sounds like that'd be a great class for our academy. If you or anybody wants to teach a whole course about it.

Yeah, it's fascinating. It's so numbers based, right? Again, like it's my engineering background that that gets excited about it probably. But I think it's fascinating and it's interesting. I think sometimes those assumptions are incorrect. Definitely come across a couple deals where the assumptions were flawed and as we pushed into the details and we really analyzed it. There were missing pieces that were not accounted for. And some of the cost benefits that were thought of were not as significant as I think the team initially expected.

That's where it gets so tricky. How do you do that level of diligence to make sure you're accurate on your bid? Steering committees, do you use steering committees? How do you keep them from being an extra step that slows things down?

We do have steering committees, especially for our bigger deals. Our central integration teams really runs most of those. The big ones are on recurring cadence because it's needed, but it's really around what is the conversation that's required at hand. Where do we have issues that need to be discussed? And that's the reason we have the steering committees. It's less of a check the box item. It's more of a we need the leadership to align around these roadblocks and make a decision to be able to move forward. So that ends up being what we focus most of the steering committees on. They vary in size and I'd say like membership. The steering committee, it's really geared around who are the key decision makers for any one deal, who are the key stakeholders required to continue with the integration successfully. And that's really who's involved in that steering committee. And it could vary depending on the discussion at hand as well.

Roughly, like how many people would you have been there? How often would they meet up?

It depends a lot on the nature of the deal. Again, because you could have anything from like a tech talent, we do have a really small to like a major platform deal. For us, the bigger deals we have, you probably have 40 people, maybe 30, 40 people on a steering committee. And those would meet maybe quarterly, but that would be the really large deals. You could have something as small as like a handful of people because that's all you need to for a smaller deal. So it could vary drastically.

How often would you check in on a like a typical smaller deal?

Probably quarterly, because you're talking about that, the big strategy decisions. But again, unless you need it more frequently. But typically that tends to be more or less the cadence.

What's the agenda like on those meetings?

A lot of times we'll take a look at what we call our value drivers. Right. Remember, this is the reason why we bought this company. These are the things that we committed to achieving and kind of staticing where we are from that because that's again, source of like why we want to integrate them and what we want to do successfully. A lot of times we start with that and then it goes through understanding where we have the risk or where we feel like there's needed alignment to move forward. That tends to be how the steering committees are run.

How does accountability work in your organization?

Accountability starts with kind of your functional ownership, where you're accountable for. In addition to that, I would say through the CFO commit process, each function that had a component of that value that we acquired. Right. They make commitments in that CFO commit around. For example, if there's some revenue targets, the sales leader at Cisco will also step in and say, yep, I commit to achieving these revenue targets as well. From a sales perspective, same thing. On the maybe product portfolio side, you'll have engineering who commit to integrating the product by strength, timeline and milestone. On the operations front will commit some of the requirements that are needed as well to make sure that we have an offer enabled to be sold through Cisco Barrister. And maybe we have some of the infrastructure requirements also ready as needed. And so those commitments are made in that kind of by the functional leaders. I think that's when the accountability is created for that specific deal and those commitments, we revisit it over time. It's a big company, we have changes in leadership at times as well. So we want to make sure when that happens that whatever new leader who maybe didn't commit in the first place, but who's now on board as a functionally owner, understands what was committed in the past and continues to support it for what's required going forward. Forward.

When you say commit, what does that look like? Is it a document on paper with your signature on it? Is it verbal?

A lot of Times It's a PowerPoint. Right. And you have like, this is what we're asking you to commit for the name of the leader who's committing to it. But that's a final sign off leading up to that. There's a lot of working with those leaders to make sure they understand what's being asked of them, what are the implications of their organization. Does it mean that we're going to need resources? Does it mean we're going to need funding? Does it mean do we see risk associated with these areas? Right. And so there's a lot of prep work that goes into that final commit. But then yes, we actually have a formal slide. We capture those commits and that gets archived. And we have a internal tool as well called M and a hub that you can log into any one deal and you could see what were all the commitments made, who signed off on all of them. And that's captured across all of our deals.

They don't like raise their right hand.

And take a note not quite that it's assumed.

It's assumed on the commit to get to close. What's the big difference between the first commit and then the latter commit before you close?

If you look at the way our process works, we have the pre commitment commits, it's called CFO pre commits. Then you have the COO commits and then you have the CFO commit which is the final commit once we move forward with the deal. That's kind of how those are geared, the pre commit. A lot of times we don't have a lot of information yet. It's more kind of directional. We try to capture some of the big strategy items, we try to call out some of the things that we need to figure out, but we don't know quite yet. And so the idea is that we get somewhat more like directional alignment around this. Is this something directionally we think we want to do? And if so, then let's keep moving forward. We'll do the COO commit when we're ready to have the alignment across operations and then that all funnels into that CFO commit. The CFO commit is our main agreement to go ahead and move forward with a deal or not. And so that's what dictates the final milestone before we, we decide to close out a deal.

Does he sign something?

The check, it gets recorded whether or not the CFO commit was approved. But I don't know if it's a formal sign off and some of depending on the size of the deal. Again, it may have to go to our board or not. It just depends. But there is, it's very clear whether or not the CFO commit was approved or not. And that's something that does get captured.

Just looking to see if red ink rubber stamp approved and it's a virtual stamp I think. But integration in terms of the broad strategy to fully integrate or not to fully integrate, what's the philosophy over at Cisco?

I've been there 17 years. I'd say it's evolved over time. There's been times where like the pendulum has swung one way or another. There's always been an intent to integrate. There's been decisions made to maybe not fully integrate at certain times for whatever reason. Sometimes we didn't integrate right away because we didn't have the capabilities that were required to do it successfully. As I mentioned, we are very mindful of trying not to break a business that we acquired. If we're not able to do an integration that's really going to help support that business going forward and integrated successfully. There's been times where we carefully have decided to like not integrate yet, but I would say that pendulum swings and we do revisit it. So we're very mindful about where we're not integrated, why are we not integrated, what's required for us to get further integrated. And that's something we look at with our leadership as well. And we're revisiting some of the legacy deals that we acquired nine years ago where maybe at the time it didn't make sense for us to integrate it because we couldn't have done it successfully. But now we have different capabilities and so we're moving the needle and further integrate in areas now that we couldn't several years back. So it's something we're constantly keeping an eye on. It also helps to keep the teams, the integration teams busy when if we don't have brand new deals coming in for a while, we have some of these legacy deals that kind of pick up steam again and come back to life and now allow us to actually move the needle where we couldn't in the past. So it's been a win win for the teams working on integration as well.

That's so interesting. I thought after 230 plus deals you would have a pretty defined answer on that. But it's a lot like other things.

At M and A we are definitely moving towards full integration, but again, I think it's. So that's very much the goal and that's very much the intent. I think how we do that and when we do it is something we're very careful about. But that is always the goal and intent.

What are other things I can learn from you so I don't screw this up come time to do a deal.

I think we learned with every deal that we do and in fact we learned with some of the deals, even the deals that we decided not to proceed through for good reasons. Right. We learn a lot from those deals as well. I think that's what part of makes M and A so exciting and fun is that a lot of times you feel like, hey, we've done this a million times, we know how to do this and then every deal is still different. Right. I think that's what makes it exciting. That's, I think why people love this space is because you get to learn something on every deal. Doesn't matter like how many times you've done it.

I agree. I just don't want the first one or two to be the brutally hard, expensive lessons. And yes, there's any immediate do's and don'ts that stick out at you. I'd value that.

Learn from the past. There's been mistakes made in the past. Doesn't mean you have to make them. There's a lot around learning how previous deals were done. Both the ones that were really difficult and people. You'll hear about those right away. Oh, we definitely don't want to do this one again or remember how hard that was. Not just the ones that were really difficult, but also the ones that went really well. And sometimes you don't hear about the ones that went really well. It just doesn't stick out as something maybe like a whirlwind as much for people. But hearing both is really helpful and so actually seeked out some of that feedback from past colleagues who had been through those different deals. And really understanding if something didn't go well, why didn't go well? Do we have the right mechanisms in place to do it correctly now? Or would we still have the same experience if we were to do this again? And really not wanting to be in that position? Right. So how can we do things differently if we have to do a very similar deal again? And for the deals that went really well, what went really well? What made it go so well? Why is it different than other deals? Is this something we can replicate? I found that a lot of the deals that went really well had a big focus focus on the people aspect of it and how you ended up having both the people on Cisco side as well as the acquirer side come together and really have a partnership around the success of the integration that tended to drive the best success overall. When you had kind of joint ownership at the leadership level around what was needed to integrate successfully. And that seemed to cascade down. Then when that worked really well. Something that comes to mind always when I look at important deals and critical deals. How can we recreate some of those things that worked really well?

That's a really good point. You gotta make sure the leadership's aligned and motivated. It's like really making sure that spark is there.

Yeah. And it's important to have it on both sides. I feel like sometimes it's only on one side.

How would you like foster that? You're like, hey, you guys should go grab a drink sometime and talk.

Absolutely. I think you have to build the relationships. I think you have to take the time to understand each other's perspective, especially the concerns as the two companies are coming together. What are people really worried about? I remember on one of the deals we went out there and one of the companies we were acquiring, they had this like special lunch on Thursdays and they were so worried that now that they were going to be part of Cisco, they were not going to be able to have this special lunch on Thursday. And it was such like an emotional thing for them because it was such like a point of connection for that company. And just knowing that was an important, critical thing. We made sure that there was awareness that this is something we want to preserve. But it would have never showed up on diligence or anything like that because it's something that you don't necessarily hear unless you're talking to people and really understand one on one, their concerns. That went a really long way. And once you appease some of concerns, then come to the table willing because you've gotten rid of some of the big heartburn and the emotional piece again, that's tied with integration at times.

That's the real science of M and A, right? Carolyn, what's the craziest thing you've seen in M and A?

When I was not an M and A, when I was in Supply chain, I remember thinking those people doing M and A, like, it's. They tend to stay in M and A. They're not really going to do some of the other roles. They're not rotating maybe as much, I mean, within M and A, but they're not rotating out of M and A as much. And I thought that was very odd because I had rotated quite a bit within my career in different roles. But when I got into M and A, realized why, and now I feel like I'm part of the same group of people who want to stay M and A. I think it's addicting. There's something about M and A to the point we were talking about earlier that gets addicting. The fact that you're constantly learning. And even if you have all the best practices documented, every deal is going to be a little bit different. You're going to learn something new and it's going to be a new challenge. I think that's really unique and I think that's hard to replicate outside of M and A in a lot of different ways. And so I think people do get addicted to that constant learning, the change, the challenge. I think that's why people stay in it, myself included. Maybe not so crazy, but I thought it was crazy before I got into it, and now I see a different perspective.

You judge now. You become one not to judge Exactly. Caroline, thank you so much. I enjoyed this conversation. I learned a lot. You helped me become a better M and A scientist.

Well, thank you very much for having me. It was a pleasure to talk about all this, so thank you.

Hey those of you with us, till next time, cheers. Here's to the deal. Foreign.

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