Virtual Summit Recap: Keeping Teams Aligned During M&A Integration

Hello M and A Friends. This podcast episode is brought to you by dealroom. Dealroom is the leading project management software for M and A. Designed for forward thinking M and A practitioners, it replaces Excel trackers and old school virtual data rooms with a modern collaborative information management system. If you're paying per page for a virtual data room then you're getting ripped off. You can save a lot of money while also improving your process. Visit dealroom.net to learn more. Also, if you like this podcast, please tell a friend we're looking to build the largest community of forward thinking M and A practitioners. Now on to 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. This interview is a rewind from our Virtual Summit. Hope you enjoy it. If you want to see the full version with video, visit mascience.com Our last.

Panel discussion of the day we have Gwen Pope Go to Market M and A Lead at Google, James Harris, Principal of Corporate Development Integration at Google and Kasia Hujag, Senior Program Manager at M and A Integration also at Google, here to discuss keeping teams aligned during M and A integration. Yeah, I'll start off with just a quick intro so we can get going to the good stuff. Gwen Pope Good to see everyone. As mentioned, I'm heading up our Go to Market, M and A team. I have had the pleasure and the interesting experience of working in in house and consulting M and A roles at a number of places both in Go to Market and Tech. M and A Prior to Google I was with Microsoft and Apple and Oracle. I have a bit of a background, a bit of a technical background in solution architecture and application integration, building SOA frameworks and solutions and bring that to meld technology and business perspectives and M and A roles. And I think Kash, that's over to you.

All right. Hi everybody, my name is Dash Ahuja. I've been at Google for the last four years focused on mergers and acquisitions specifically from a technology perspective and prior to that I was with Deloitte also on mergers and acquisitions for about five years and in that role I focused largely on financial sector and healthcare sectors and prior to these nine years in M&A I was for 12 years I performed a number of roles that required the technology expertise that included large system rollouts as well as round the clock operations management. James, over to you.

Thanks. Actually I was digging up when was the first deal I ever was exposed to and it was actually 97 and I was an engineer at the time, so that was my first exposure. I've actually been really doing M and A for the last 15 years, probably a little bit more than that. And. And I've done it in three different companies. And the first one being more like every deal was a big deal. We only did a few deals, moved to the next company which was a 10x jump and we did a site we were getting to be a serial acquirers and then moved another 10x to Google, which was firmly a serial acquirers. I think one of the things I like about M and A and what's been interesting about the whole process is that you always get the chance to learn. And I'd say most of the areas I understand finance is probably my greatest weakness. So if anybody has any financial questions, I'm going to hunt immediately. Pivoting to kind of the focus of the meeting and kind of thinking about how to kind of keep teams together. We were kind of talking about it together. We thought it would be interesting to show and talk through how we work as a group. You have kind of three key team members here. You have Gwen, who's focusing on the GTM side of the house. We have Cash, who's been focusing on the technical side of the house and how we kind of get technical integrations together. And then myself who's kind of working on the overall integration. So it's just part of. We're thinking that we could talk through how we interoperate because I think that those three key disciplines are the core of most acquisitions at Google. And also it's an example of how we even run little mini experiments. We're doing an experiment on you. All we're going to see this is a different format in an M and A conference. So this is also core to our process here at Google is that we try things every deal and some things work and some don't. So there is to get your thoughts on that as it goes forward. So I have a quick question for both Gwen and Cash. When you find issues that are going to impact the integration, they never happen. Every deal is perfect. How and when do you know to surface it? To myself as the integration manager. And then how do you know when to bring it up to the sponsors? This gets at the core of how we work as a team.

I guess I'll go first and then turn it over to Gwen. When it comes to issues, I think communication early and often is absolutely critical. I spent 12 years in operations, around the clock systems management and it taught me some important lessons other than, you know, 2am Wake up calls. One of the most important was communicate first and fix next. I bring that into into my role here and we follow it here. So when we come across issues, we try to resolve them obviously as soon as possible, but we communicate early and often as well. It allows us to leverage the collective minds on the deal, which not only generally lead to better and more creative solutions, but also help us truly gauge how critical an issue is. In other words, it's not uncommon for us to find that the issue is not really as high priority or impactful as we might have thought at first, or vice versa. That the issue could have much larger implications than any of us could individually imagine. Having said that, we try to communicate thoughtfully in a nuanced manner. It seems clearly identifying where we are in the issue life cycle per se. Has it been defined and is a true problem statement known? Have the implications been discovered and understood by all key parties? Do we have potential solutions identified? Do we have our recommendations that we want to go forward with as a team and do we have tentative path to execution depending on which way we go? Obviously don't have to have all of these identified on the first day, but we try to communicate as clearly as we can as we navigate the issue through its lifecycle. Anything to add?

Yeah, I think just to add a go to market lens to what Kash mentioned in terms of go to market planning. I found it especially critical to be able to translate the potential impact for go to market and executive leadership. So to me this means being able to frame a risk or a challenge in terms of revenue assumptions, time to market, cost per sale, and customer experience. Are we looking at taking a hit or accelerating something in those respects? So if I'm looking at either raising this for awareness or if I'm looking at proposing options, then I need to make the trade offs clear and again translate it in terms of what does it mean to our core assumptions that were defined at the outset of the deal and also in the evolution of diligence and how you're cycling through and building out and pressure testing those assumptions.

We'd be remiss if we didn't talk about one of the biggest ones that's facing all of us now. So James, over to you. So maybe how do we, how are we doing diligence during the COVID 19 time?

Now that's a great question, one that we're wrestling with fairly permanently. I think it's we're constantly working on how to improve our processes. Give us a bit of a curveball as we realize oftentimes there's that great interactions where you go to target, you visit with them for a period of time. You can either, you know, sometimes you visit on their site. We also oftentimes also invite targets to our local Google offices. It's a great place to kind of build those first personal relations and kind of build a rapport. Doesn't quite work the same way over, you know, electronically over hangouts or zoom meetings. We're still kind of trying to figure that out. So it's just a human interaction there that I think is really important. I think on our end as integration side, it's a little easier because it's a very clear arc of what the work we have to do. And we're kind of working on kind of the due diligence cycle and then the integration work. For my deal compatriots, I actually think it's a little harder because they don't get to build that rapport as part of a negotiation. And so it's as one person once said, it's very easy to be a jerk to somebody on a call versus being in person. And, you know, negotiation are a little stressful sometimes. So I think that's piece. It's a little bit challenging for our partners on the deal team. I do think that there is one interesting windfall though that we've noticed is that it's much easier for CEOs and senior leaders to duck out of the office to take calls with us because when they were normally when we did due diligence, people would start freaking out because they'd like not be in the office because it was hard to have these conversations on conference calls or they literally we'd have them off site. And so now we do them in smaller chunks. So it's not quite as obvious that something maybe is going on, but it is easier to actually get some of those kind of conversations scheduled and get the right people involved without tipping off everybody in the early stages.

All right, so I'm going to pile on this topic somewhat selfishly. I briefly touched on time market as a driver earlier and obviously ramping acquired teams is a key ingredient to doing that. But within the context of COVID James, maybe you can say a few things about how we're working with onboarding specifically.

Yes. And actually this is part of the interaction is that I really do appreciate that both Cash and Gwen are asking me questions and keeping me honest as I keep them Honest. So this is part of that dialogue. Yeah, the COVID onboarding has been interesting. Normally back to the kind of that personal touch. We usually like to bring the new team in and have them actually go through our new goer. Sorry, newcooler is new Googler orientation. And it's nice. We found it to be really helpful as they went through with just a bunch of regular other Googlers. And so they build a lot of. We get a lot of surface area with those new employees from an acquisition versus just people coming in as part of hires. Now we're doing it virtually and that process is working pretty well. It's not quite the same as like bumping into somebody at lunch or sitting next to somebody and asking what did they just say? Or how do you get the laptop to work? So you do miss a little about that. The really interesting thing about this is that, you know, in M and A we really work to be flexible. We work to kind of move very quickly and as part of that and kind of how we serve and onboard employees and oftentimes we're doing very large deals with employees in very remote locations or spread out across across the globe and we can't always bring people into those offices. So we actually had developed a remote onboarding process as part of the M and a process. When COVID 19 hit, our Noogler team came to our team and said now how do you do that and can we borrow it? And we said, certainly. What's nice is now we're using some dividends and that there's some things that were a little rough when we did the remote spots that we now have a whole core team focusing on how to make that easier. When this all kind of comes back and we can kind of go back to normalcy, we actually have to have really robust deep onboarding process.

That's a really good point. It's not uncommon. I've had a couple of other instances where something that we came up with as an M and A team was then leveraged broadly. Switching back to gtm, Gwen, how do you balance go to market launches for a new product versus maintaining legacy products in the market, especially if they're serving the same customers and or needs.

Yeah, that's a great question. And I would quickly argue that that's really not just a go to market question, but I'll answer it anyway. So prioritizing objectives for legacy and new products is a key element really that we face in all of our deals, regardless of what the rationale or the product and go to Market assumptions are underlying. We always have to balance the need to support existing customers, of course, using pre closed products and look at that as well as the value add that we intend to bring to the market for Google Cloud customers via new offerings. I would say that increasingly we're focused on and I'm looking to leverage the lens of a customer experience view for each acquisition. And what that is is looking across products, customer segments, integration phases, and looking at not only what our aspirational objectives are, but also bracing pragmatically for what the integration realities are for each of those phases and across each of those considerations. And what this does is it not only helps us flesh out those baseline integration assumptions, but also acts as a guardrail that is meant to anchor planning around customer needs. What does that give us? That gives us a few considerations that shake out that typically drive key decisions. One is the consideration of the amount of time it'll take and pressure testing how realistically you can bring something to market and reach a measure of feature parity when and how do you expect customers to want to and be able to move to the new offering. And part of what goes into that consideration is that product teams are typically caught and maybe that's too negative of a word, but they are challenged to split their time between maintaining an existing pre closed product line while also readying, meaning remediating and integrating to bring the newly acquired product to market. Whether that's in a standalone form or whether you're integrating and merging it into an existing product line. So features developed on the legacy product while that remains in use and standalone may need to be moved to the new product and products may be at different stages of commercialized readiness. So considering how you intend and how you expect customers to migrate between the two is key and also how you balance product and engineering and other operational teams time between the two is a key consideration. Integration planning across these two is a big prioritization challenge. Going back to the customer experience plan that helps you crystallize when and how you expect customers to move and for what reasons they would be interested in, as well as looking at what materials to prepare to enable teams to support the customer migration. One last thing that I'll mention is that of course there is a scenario where sometimes we determine that the best plan is to focus 100% on a new product or offering to bring to market. So we would be essentially sunsetting an acquired product. And there I should call out important footnote that of course we would support the existing customers on that product until a point where we had a landing spot for them or it was appropriate to incentivize or offer something for them to migrate to. One of the considerations around this scenario is that the risk is that this could leave a bad impression in the market. It could prompt customer churn or even impact partner relationships. And so following this integration strategy requires a careful communications and support plan. You need to be clear with customers that the pre close product will be in maintenance only while the new product is being developed. Yet as I mentioned, their legacy terms would be honored during this time frame. So I think with that just to point back to the importance of the customer experience planning, that's a key that helps not only prioritize time but also keep everyone with clear line of sight on the objectives.

So yeah, and I actually think Gwen, you kind of are part of that voice of reason for the customer in that you know, oftentimes the engineering team wants to go off and work on the new shiny, go work in Google and figure out how everything fits together. And you know, there's this wait, wait, wait, I need to keep the existing product in place. And that's always it's an important voice to have an important part of the conversation and just a little background in Google. Oftentimes a lot of our sponsors are engineering managers or engineering leaders so they're a little focused more that way. There's a little bit of a bias there. So I think it's really important for Gwen to kind of see speak and raise that issue because I think it's just something that engineering will go charging off and wait a minute, we have a bunch of folks that we need to take care of so kind of shifting over to cash because I think for Maddie some of the things that you do and I actually both you and Gwen I have highlighted to other members of my cross functional team as examples of hey, when you have an issue bring it up this way because it's super helpful is you bring up issues, you cover things. But I think one of the things that you have is you're in a technical company. We have very technical questions, we have very technical issues that come up and how do you then make sure that that's in some cases up level because some of our leaders are not in the detail or right level for even some of the non engineers because the engineering team starts talking and the go to market and sales folks are like what does that mean? So if you could kind of give an example or talk a little bit about that would be super helpful.

Yeah, absolutely. Before I go to that add or agree with the comment you last made. So as a technology specialist, it's always exciting to go work on the latest, greatest thing. So yeah, Gwen is great at keeping us all in check when it comes to that, making sure we're thinking about business. I think that's the key, even in answering the question you just asked James and being able to communicate with the different team members on the deal. We're working with product, we're working with sales and marketing, security, privacy, compliance. So I think the key for us is we always try to think of this as a product manager or what in most startups is the CEO. So the goal is to have a broader perspective, not just think of the technology considerations, which are obviously critical and super exciting, but also of other business considerations that I just called out. When it comes to fixing or improving inbound companies technology, we take into account a variety of different factors. Number one, how widely is the technology used, respected and liked by the users.

Customers and our partners? Number two, where is the technology in its life cycle? Is it early stage like in a prototype, proof of concept pilot, alpha beta? Is it mid stage where it's out in the hands of some customers and some users? Or is it a mature product where it's used for production, used by our enterprise customers or for the day to day use by our consumers? Number three, how well does that technology fit into the Google product and the plans we have for that product? And then number four is what are the issues that we need to address and remediate before we can sell that product with the Google stamp on it? So considering all of these factors, they often require a balancing act as it's very likely unfeasible that we can weigh one too heavily without having a detrimental effect on the other. So for example, share a couple of examples. Remediating a security or privacy issue, let's say in a mature product, often requires a lot more careful planning than say.

A product that's in either POC or an alpha beta stage. Another example is the different types of customers. So whether the customer is an enterprise customer or a consumer, in our experience, consumers are far more likely to adapt and adopt new changes. They are quick to move on, they might even encourage it. Something that actually is very much liked by our consumers. But on the other hand, with the enterprise customers that may be running revenue generating products on top of our products, it requires a lot more thoughtful planning and detailed planning to address those issues. So our goal is to work with the different team members that we bring on for all of our deals, both in diligence and integration and the different teams of product, sales, marketing, privacy and compliance to come up with a prioritized list of changes that we want to make to the product while minimizing disruption to our customers and maximizing our speed to market.

Wen one of the things I wanted to cover with you is we've seen this in most of our deals is we announce the deal, we may have a time period before we're closed. The sales team is super eager to start to sell or we start to bring in sales folks as part of the due diligence and they're like, when can I start selling? When can I do this? So how do you manage that? Beginning, start, and then even sometimes I like in sales to crack the spigot and you do a little bit of joint sales and you figure out how it works and then you crack it open a little bit more. So how do you kind of manage that?

Yeah. So just pulling back the curtain pretty much entirely here. I'm super, super big fan of strategizing around communication, whether it's to sales team or otherwise. So. And I thought that I was on the ball as far as, you know, concentrating on, okay, let's communicate what people need to know. Consider your audiences, et cetera. I will admit that every deal is a learning opportunity, obviously, but deals such as Looker have shown that what I thought was clear communication, that even that was not clear enough. And I think I'll even revise the word clear. Pragmatic. You not only need to be clear, but you need to be pragmatic. So having a really clear, crisp communication and enablement strategy for go to market teams is extremely essential for activating it around an intended go to market strategy. Especially because what you need to do is you need to drive momentum and harness that excitement around the acquired product, the solutions that you're bringing into the fold, but also mitigate and guide behavior through the inevitable friction in the sales cycle that will exist in the initial integration phases. I mentioned pragmatic, for instance. You need to get pragmatic and really straightforward. Like, yeah, this is not going to be fun. This is not going to be neat and tidy for a little while, and here's why, and here's how to think about it. And here's pathways that we recommend for contracting, pricing, discounts, support options, anything that's temporarily out of scope that customers are going to either request or presumptuously assume. They're just going to assume that, hey, it's all Google. Why can't I have these terms cover this and have my benefits and my credits apply, et cetera, drawdown on my existing commit, et cetera. So there are certainly interim solutions that we might spin up as soon as possible, bridge that interim period. But teams will inevitably expect that they can immediately hit the ground running. And I love that enthusiasm. But as I mentioned, even in recent deals I have increasingly learned that you not only need to have clear communication, but you need to be realistic and straightforward with teams. Lastly, I forgot one detail in that assortment of key topics comp when it comes to sales teams in particular, right. Legitimately, they're going to be very influenced by what it is that they're incentivized to do, particularly around customer segments, products, solution multipliers, that sort of thing. And that will influence their behavior. And when you divulge those details at what integration milestones and how you advise them of what's still out of scope is really critical. So that's my soapbox.

Well, no, actually I think it's Kash, I'm going to tweak this a little bit as we go into an integration plan. So two things here, Gwen, I completely agree with you. I remember one of my favorite sales VPs that was from an acquired company when we were starting to talk about compensation, he put it very clearly, you're messing with my food bowl, I may bite you. And I thought that was really, I was like, I appreciate that, I appreciate the clarity. But you know, it was, you know, down to the scheme of the sales team will be very focused on that. And so that was something that I agree is something critical to focus on. Cole actually asked a great question. Who is responsible for overseeing the customer migrations, new pricing and packaging recommendations, et cetera? Who owns gtm is the strategy developed by the IMO and then handed to the GTM team. It's a great question.

This will veer into potential soapbox territory as well. But at least within Google Cloud and the way that we think about Cloud M and A, we at the outset look at three table legs, right? We have product and engineering sponsors and recently we've had this emerging third table leg. @ least as far as formalization around go to market. My role is to act as proxy, Certainly I like to think that I bring some of my own perspective and expertise to the table. But I act as proxy for our senior leadership across go to market aspects. And I should probably include a quick footnote and say when I say go to market, I don't just mean sales. I mean all of the considerations and sub functions that it Takes to mobilize around bringing something to market so that sales and marketing support, professional services and commercial operations, commercial, legal, finance, et cetera. I'm sure I've missed some important function, but you get the idea. It's an umbrella approach acting as proxy. Then I stand on the shoulders of geniuses. I lean on the expertise across those functions. I bring that into not only diligence analysis and preliminary planning, but then eventually in operationalizing the Go to Market integration plan. To say that I'm responsible doesn't do the effort justice, but hopefully that adds some color there to the question.

All right, so James, I'll give this back to you. So Google is known to be a serial acquirer. Do you run several deals at once and how do you keep them straight?

Coffee and alcohol would be my first quick answer. No, actually, there are a few things to think about. I think timing is a key piece. Not all deals go at once. Hopefully. We have had a few cases where I was engaged in some early stage deals and they all started to close at the same end of August order. Part of that is something we've learned in our integration team is we often will buddy up early stages with two of us working a deal at this early stage and that allows us to both have that critical early context. And then if, you know, we start looking at timing and start looking like, oh gee, you've got two deals that are going to close at the end of the quarter, maybe you give up the third one. That helps us balance it. It also has a fringe benefit that if you want to go out on vacation or you schedule something, that person at the early st of the deal has a lot of that key context so they can drop back in. They don't have to kind of ramp up really fast and you can kind of do a quick handoffs. And yeah, we have had horse trading of deals within our integration team where it's like I give it away and then it comes back and then give it away again because it's just the timing isn't quite right. It's super early. We tend to solidify that once we engage with a term sheet and we're really starting to launch the formal diligence, then we don't tend to like give back the deals. So there's no gives backseats once you hit loi or term sheet. But the idea here is in some cases, if it's fairly large one or we know that there's some that are coming together, we'll be very clear that there's a primary integration lead and the secondary integration lead. And that helps. Another thing to keep in mind is size and complexity. You know, if it's a series of acqui hires, you can do a lot of those at once. It's not as impactful. If you're doing some quick tuck ins, that's another kind of piece here where you can kind of match those better. If you're doing a phased integration approach, then that has a little bit more work. So you may need to just do that or a couple quick aqua hires along the way to balance your workout. If it's a full phased or a standalone, which we have done several of those acquisitions, that starts to get pretty beefy. And then we also kind of think about divestitures and. And actually we kind of think about on our end that we're kind of running about five, four to five deals, maybe six at a time. If you're doing a divestiture, we figure that counts at least for four or five deals. And that kind of thinking because it's just so much more complex. I mean there's just a longer roadmap, there's a lot of pieces that have to be done. So I think that's going to kind of think about kind of what's the workload there. And we actually meet once a week and look at our workload and talk about it as a team. And if we start to kind of feel like we're. We're getting a little antsy, then that's when we kind of as a group even decide, hey, can you take this on? That works out pretty well. Another one that sounds really obvious but is watch code names. I had a period of time where I had three deals that all started with C and they were five letter words. So it was like really hard to kind of keep them straight. It was interesting because the deal they thought it was kind of cute to do these all as a roll up. And it was like no, this is not roll up. And they started to kind of realize that was getting confusing. So think about codenames and thinking about making sure that they're really distinct. I think that is really important because that just just as basic back to some of the things Cash you were talking about communication and clarity when just keeping it super simple. The other one is that we have very broad cross functional team that we can attack and we often have the same cross functional team members working. Maybe all. If you're working four or five deals, maybe three the same. And then the other deal there'll be like two or one. And so it's. There's a mix match and there have been a few times where I've been in cross functional team meetings where cross functional team members raise their hand and say, which deal is this again? Because it's just if it's. They're all moving fairly quickly and that's totally cool and we'd rather correct that early to combat that. I've actually started doing more deal days for deal A. We may be all doing them all on Tuesday. I try to get all my cross functional team meetings, all the sub teams in some one meeting. So it's just kind of like that's day. Deal A day is on Tuesday, deal B is on Wednesday and C is on Thursday. It doesn't always work out, but the idea being that if you kind of anchor the cross functional team and a lot of them subgroup meetings afterwards in the same day, it just kind of helps with people keeping their head wrapped around it. But that's an idea. It doesn't always fit. Kasha, I know you and I were talking about this earlier when we were kind of getting together. You had a couple of good points here.

So I want to actually just go back to one of the things you just mentioned when you were talking about divestitures, counting as three or four deals. Yeah, that gave me a sense of deja vu because I remember when you and I started working together first it was on a divestiture that lasted multiple quarters. Super painful. It was global with 6am meetings, 8pm meetings. So maybe one takeaway for the group is if you want your team to work together, put them on painful deals together. If they can survive that, they'll find a way to work together on other deals. The other thing I'll add is as a serial acquirer, one of the benefits we have is that we're able to innovate and experiment. So we have the healthy pipeline. So when we think of doing things differently, when we learn a lesson on one deal, we can quickly figure out what we want to do differently and then have another deal ready to go. We've experimented quite a bit. As you can tell even from the format of this call, we like to try things differently.

Yeah, I know one thing on the topic of keeping the deal straight. One thing that I experimented with as of a couple of years ago was to put together really early on just one pager, cheat sheets. And then as I brought team members on cross functional leads say, okay, now you're plugging in this project. I would just point them to that and say, okay, we'll have more information soon, but at least that'll help us keep things straight. I'm curious, Kash. We all work to partner with each other and of course we all have our eyes on collective success. But what have you found to be helpful and what's your approach in helping cross functional team members that might be struggling or underwater? Right. What have you done to help them if they're delayed or behind?

Yeah, absolutely. So I'll actually go back to a point that Deborah Bertucci and Kim Jones made in the meeting yesterday from Microsoft. Deborah particularly talked about working together as a team. Even the target that's coming into the company, they're eventually going to become part of the team. I think we take the same approach with our cross functional partners. We might be on different, focusing on different functions, but at the end of the day our success is all tied to the deal being successful, Google being successful. So yeah, so this one's fairly simple and in principle I try to help the cross functional team as often as I can, as best as I can. Sometimes it's good to just be able to talk the issue through or brainstorm possible solutions. I know working on the technology work stream a lot, I've often had brainstorming sessions with other cross functional partners just to get some out of the box thinking. So it's, I think a lot of times it's useful to talk about that and then talk about what the impacts are of whatever the issue is that they're facing. So their impact on my work stream and vice versa. And if you're delayed, my preference is to usually just talk it out and determine what the plan of action is. And if that plan of action generally means escalation, then that's great as well. Escalation, not necessarily a bad thing. The important thing is that we escalate in an informed manner and we escalate oftentimes together. So the issue is raised to multiple functions at the same time and we can come together and find an answer.

I think that's a good point to switch gears and talk even more broadly. I know that there are certain things that we all have in common as far as how we approach the role in general and how we approach M and A work. But how do we think that M and A is different here at Google from other companies? I think that might be a question that our audience would be curious to hear us speak to Cash.

You want to go or I can.

I think this one. I'll give it to you on this one. Dave, give us the 50,000 foot view.

All right, well, I think there's a couple things here. You know, it's, it's an interesting question because I've done deals at different size companies and, you know, each one was definitely, I want to say, a size and volume. I think the big piece here is that Google, we do a lot of deals and I think that helps as far as being able to get a lot of reps and a lot of experience. It also gives us an opportunity to run a lot of experiments, which means that we can figure out and try different things. It was interesting. I was thinking about some of the things that Toby was talking about in the previous session. He was formally calling these plays, we call them experiments or tools in our processes. And we're like, hey, we're going to try out this like little process here and we're going to see if that works. If it works in one deal, then it's like, well, then we may start to institutionalize it and we may tune it a little bit and as it goes forward, it becomes a key process or atomic element that we may shuffle around in the order of a deal. It becomes kind of a play or a runbook, which I think is really helpful. We kind of have a allergic reaction to overall playbooks as a company, but I think these kind of little atomic elements is something that we recognize. It's like something is very. Most of these times there's little programmatic pieces. I think the other piece here is that we really do like to think we do a lot of acquisitions that really focus on. If you kind of look back over history on helping users. I mean, you look at companies like DeepMind, Waymo, YouTube, Jio, Android in ways, those all came in through acquisitions. I mean, those were all started that way. And I think we were willing to take a long view on this. I mean, when we bought Android in 2005, which was now 15 years ago, the early reviews of Android were not that promising. It was not very complimentary. I mean, I actually remember running a very early version of Android at another company and thinking, oh, this is a product designed by engineers for engineers. And there's no way I'm giving this to my mom because it just was just too engineering focused. I think Android is pretty good at this stage, but we had to learn a few things. I think all three of us are spending a lot of time working on cloud and I think the interesting difference for cloud deals are, is that we still want to focus on those customers, but we're actually focusing on customers that are building things for their customers and that's something that's a little different use case. I mean, I think as we look at kind of how we take in products or do innovation or do integration, if you're doing a commercial product, something new or new feature that's delightful and that's interesting. As long as you don't change the UI for a phone too radically, those are all good things. If you do something for somebody that's building core businesses running on top of it, then you have to think about back to some of the comments Gwen made about keeping things stationary, keeping things in motion, how do you support that existing customer base? And then I think the other thing here is we have both long and short term OKRs, which are objective by key results. And that's consciously designed. I mean we actually build our okrs kind of short kind of goals and focuses areas and then we have some that may be multiple years out. And that multiple years out part is part of our roles as integration managers is that we don't roll off a lot of deals. We roll off simple deals quickly, but more complex deals we're around for multiple years. I mean, I joke about my friend who did the Waze acquisition. He never really quite rolled off of it until we folded Waze into part of Google again. So I do think that there's some parts where we just, we stay active and I think that that's just part of the rapport that we build with these leaders as we kind of go forward is that if there's any kind of major changes, we kind of tend to get brought back in to either provide guidance on why did we do it this way or how can we help them make that next step.

I'll ask a bit more of a general question and maybe a general version of this question could be good for the next session too because I always love asking M and A practitioners this question. What excites you most about M and A? And in our case, James, you can also talk about in general or at Google.

Well, the variety. We often say here no deals are the same. Every deal is a snowflake. There are probably some common components of them always and there's theme and variation, but that to me is always interesting. So you're always learning. You know, I think it's particularly as the immigration lead, you know, you get to see things at a very broad level and you get to see a lot of how decisions are made or you can help make decisions greatly partnering with folks like you and Gwen. And that to me has been really interesting and I Joke. It's probably the best functional MBA I've ever seen because you kind of have to get in there and do things. I mean it's a non stop case study or each deal is a case study. So I think that that's the part that really, I think makes it interesting for me is you're always learning.

Yeah, I'll add a couple of points. One of the things that I think you mentioned really quickly is the speed at which the deal moves. Absolutely love the pace of work, the adrenaline inducing moments. Right. Sign announce and then you get into the log slog. That's integration. But there's also product launches and whatnot that are pretty exciting. A couple of other things that I'll call out. One is working for a company that has multiple products with a billion plus users. This was a bit of a shock for me early on is working on a deals that if things work out, if you're successful, then the product will be in front of billions of users in anywhere from a few months to a couple of years, including your family and friends. So you can actually talk about the work that happened some time ago that is now in the product. So that's just rare to find in most jobs. I think the other thing I particularly like about working with our targets is they're mostly relatively young companies who still have their founders and early stage leaders around. So it's fascinating working with folks like that who have brought an idea from just a concept or level of reality where they're getting acquired and oftentimes getting asked about by multiple large companies. So the target leadership we often work with combines some of the best characteristics you would want from your colleagues. They're entrepreneurs, they're self starters, they're biased to action motivated, hard working and highly competent. So I think those are a couple of things that really are positive aspects for me.

I would tack onto that the problem solving, which of course is, you know, you could argue that that's one of the most frustrating or migraine inducing parts of the job. But it's also what I love best because it's an opportunity to make an impact. Not just working with a ton of great people to do the problem solving, but then to make a difference in the market, make a difference to our customer. Experience that for me it's both sides of the coin in one, how many.

Googlers are involved in a deal before announce? And then how do we fight meeting fatigue for employees who may have a day job?

We have to stop ourselves from presuming that MA is the center of the universe. As far as working with functional teams and what we refer to as business as usual functions, we try to make sure that we're framing a request or an ask for an exception because that will happen fairly often. Hey, this is an M and a project is a typical prefix to request, but making sure that the context is there in short form and then to make it clear how your request or how your need ties to business as usual overarching objectives. How does this line up with leadership's interests or OKRs? Right? Either they find it helpful in terms of justifying or backing up or providing air cover your request or your your need, but it also helps them place it into the context of their business as usual operations, business as usual processes. I'm not sure how to speak to the meeting fatigue. There again, you try to really just compress your engagements with business as usual teams into nuggets of hopefully efficient cadences, efficient materials, making it clear what you need from them and also setting expectations. Clearly this is essentially the virtual job description of what we need from you plugging into this deal, depending on of course, what you need from them.

I'll expand the question to meeting fatigue. That happens even for us who have.

An M and A.

We all get tired of it. The way I deal with that is there's two parts to it, right? There's the diligence aspect where we have to move incredibly fast. Timelines are moving, the scope's fluid. So it's for lack of a better term, I've kind of given up on efficiency during diligence. It's just get people together and try and move as fast as we possibly can. I like to think us as different team members, we like to share and sometimes overshare so somebody else who might not have read an artifact that came in through a data room can share that with somebody. Because as you can imagine, there's hundreds if not thousands of artifacts in a data room that just impossible for any one person to sift through. But once we get past integration, I think it's about respecting your colleagues time. I like to use documents, I like to use emails, sometimes long to try and avoid meetings, but sometimes you just have to have the meetings, in which case I'll try to make it as concise as possible, try to outline what I'm trying to get at before we get into the meeting and if I can get the answer over email grade. But if not, then let's get into a meeting, let's hammer through it as quick a time as possible and give time Back or try to be as efficient as possible. So yeah, really focus on speed during diligence and then efficiency during integration. In terms of how many people it takes a lot. Takes a lot of people. It's a village. It takes a village to do a deal.

That's a blessing and a curse here because, I mean, we do have a lot of dedicated M and A folks which does allow us to kind of do things. And. And then that helps for the other part of this question with people that have day jobs. That said, I think there are enough downstream teams. As you kind of look at fanning out an acquisition or integration work. You're always going to be working with some downstream team. That is, you just brought them a bunch of work that was unexpected and in most cases they're going to react that's unwelcomed. I think we have to kind of back to both. I think both what you and Gwen at setcash is that, you know, you have to build on that. And I think part of that is just figuring out, you know, I often think about it as a little bit of a negotiation and how can I soften this? How can I smooth that out? Is there anything I can do up front? We distribute the work into, you know, one of our core cross functional team members so that we can kind of help bridge the gap. I mean, we can't do all that work. And then other times I've kind of done just shamelessly. Okay, I owe you. The next time, the next time we do this, I need to think about this. I will recognize this as far as highlighting to your management that this went above and beyond. That's a big piece for our internal promotion processes. So I think those are all kind of elements there that you can kind of figure out. I think the toughest ones that we have to do. And this is kind of getting to one of the questions we had for each other is what are the hard parts about Google is sometimes you have to tell a team that is really itching to fix something because it makes their life easier? No, because it goes back and it harms the key strategic objectives. It makes it more difficult. And then you are, in my view, in heavy negotiation mode. Because it's like, I hear you, I understand this. I know this is not fitting in with your core objectives and values. But for the deal, this is what's really important. And so oftentimes, you know, to get to that negotiation stage is not now, but it will happen. And I think that gets me a lot of pieces now. You have to Write that check later or people will call shenanigans on you or other things. So I think that's really important. That is one of the challenges sometimes is just integration for integration sake.

So to put you and Kash on the spot in that context, what would you guys call it as the biggest challenge in M and A that you commonly come across? Whether it's specific to Google or not.

It'S a constant struggle. But the key is to establish an environment in which both us as the acquirer and the target can work together to bring about the best possible outcome for the transaction. Our culture at Google is fairly agile even for our size and scale. So when startups join Google, it usually takes a mental adjustment to go from being a startup, regardless of how large, to working to figuring out how to work for such a large company. The challenge for us as M and A team has generally been working with the various teams inside Google to allow for some flexibility, understanding accommodation for acquisitions, at least for the first few quarters, while the acquired team fully ramps up at Google.

Just looping back to the pragmatic communication topic I mentioned earlier, just to put it bluntly, when you're looking for partnership and backing internally, I found that it's really helpful and necessary to ask yourself why should these teams care? Right? Why should they care? What will inspire them to partner with you? That's a key piece that I find myself both up against and also really deriving a lot of rich learnings from. In figuring out the answer to that.

Question, there's a question Bill posted that I want to throw out. Any tips on managing status updates during integrations? I frequently experience status meetings that end up in decision making, brainstorming, problem solving. No, that never happens here, Bill. I think one of the ways I like to think about it is that we have at minimum a core cross functional team meeting. That's an hour a week for some deals. We may actually have two meetings. How I try to focus it is the first half is around status and updates and key things there and hopefully I'm not getting surprised in that meeting as the integration manager, although it does happen there may be some things that are coming up the second half because I've carved out in these people's calendars, an hour in their calendar is for a hot topic. That is where I'll declare it early on. Hey, we got to really work on this customer migration question because it's a big challenge here and so I have all the key players. I've got them cordoned off as part of the they blocked out that time on the calendar. The ownership and possession of the employees is 9/10 of the discussion or the guidance there. So then I can say, hey, if you want to hang around and hear the second part of this conversation, where we get into problem solving, where we get into brainstorming or we get into positioning, okay, how do we talk to the management? That's a key piece there. So that, that's a way to kind of help balance it. But yeah, it is always kind of there's and you also, sometimes times you just have to stop the meeting and say, we'll take that off the line.

Aggressive parking lotting.

Yes.

That's an awesome, awesome topic to dig into. It's over here.

Yeah, yeah, yeah. I mean, I think it's really important for people to feel heard. So I know we're running right up on time, but these have been great questions. It's been. I want to actually, the conference has been amazing. It's the first one I've done virtually, so I have to give Keystone props for getting this set up. I mean it's the new normal in LinkedIn. Feel free to hit me up. Always happy to ask questions, set up time to talk more detail about these. So any other last questions, like two minutes and I think we have a happy hour and frankly, I want to give everybody a little bit of chance to go get their adult beverages if they'd like.

If you have an old beverage.

Thanks so much for listening to this episode of M and A Science. If you want to stay up to date on the podcast and all things M and A Science, including our events, make sure you sign up for our weekly newsletter@mascience.com MA teams that use proven techniques deliver better outcomes. Agile M and A is a science based framework that focuses on responsiveness, adaptability and continuous improvement. You can view the whole book online for free@agilema.com and if you're still using Excel trackers and old school virtual data rooms that charge per page, what a ripoff. I highly recommend taking a look at Deal Room. Deal Room is designed for collaboration with internal and external teams. Visit dealroom.net to learn more. You'll also find lots of free resources, templates, ebooks, guides. Thank you again for listening to M and A Science. See you next time.