How to Implement an Agile Approach into M&A

I'm Kisam Patel and you're listening to M and A Science, where we talk with deal professionals and learn valuable lessons from their experience. This podcast focuses on stories, strategies, and what actually happened during M and A deals. Welcome to M and A Science. Today I'm here with James Harris, principal of Corporate Development Integration at Google. James joined Google's integration team over seven years ago and carries over a decade of experience in business development. On this episode, we will discuss the shortcomings of traditional M and A deal management and how Google uses a modern approach called Agile to generate more efficient and successful M and A deals. James, thanks for taking the time with me. If you wouldn't mind just telling me a little bit about your background.

Yeah, sure. I've been doing M and A probably close to 15 years off and on, definitely solid for about 12, 13. Prior to that, I actually was an engineer, a developer, and then actually became a dev manager. And when we started talking early about using Agile and M and A, it really resonated because it is something that I started in the traditional programming environments where we had waterfall development, learned about this crazy thing called Agile, started applying it in a couple of the teams that I'd worked at and realized that it really works. It's great. A great example of it being something that worked for me early in my career is when I was running the operations team for Classmates.com we actually had our data center vendor give us notice that they were going to have to shut their doors in 30 days. So we had to pick up and move our entire data center in 30 days and we had no plan. And we used Scrum mentality and Scrum Methodology to make that work. And we finished at day 27, which was fantastic, but there was no waterfall, there was no plan. As I started moving into M and A, I'd worked a couple programs and teams where we started with Playbooks, and I think there's a little bit of a progression where everybody, when you start M and A, it just. It's so different. There's so much change, there's so much variety. When I bring new team members in and work with other groups, it's like, I want the Playbook, because then it means you got kind of A. It's providing some order to that chaos around a deal. And after a little while people realize that's helpful. But every deal is different and they kind of start to look for some form of structure that allows it to be flexible. And that's, to me, the prime moment to introduce Agile. And then we can kind of build from it. And so yeah, we use it here quite a lot at Google, we used it a little bit at Amazon and then also a little bit at f5. So I think everywhere I've been we've kind of used the pieces of it. But here we pretty pretty much have just built our culture around it, which is, I think helps us be able to do as many deals as we do.

I'm looking forward to learning more about that. But before we dive deep, could you quickly explain traditional approaches of M and A to our listeners and also what Agile is?

Sure. So traditional M and A is what's often referred to as a playbook and I'd say the high water mark of that. And I think different companies have different cultures and different ways of operating would be some of the playbooks I've seen that IBM uses. And it's a very structured program where it has clear phases, clear deliverables, clear checkpoints. And it's a very step process. And one thing that it does do is make sure that everything gets covered very systematically. It has a pretty clear prediction of beginning and end, all the requirements and kind of the classic engineering piece. You write the description of the product and how that's going to work, you decompose that several layers down, then you build your schedule and then engineers start coding. That does allow for a lot of upfront work and thinking and planning. And so when your engineers are working, they're just writing the code. What that does do is it takes an awful lot of time in today's environments and other places, it doesn't give you an opportunity to flex if you get new inputs. Now, with Agile, you pick a series of goals that you want to cover. In the traditional engineering environment, where you say, I want to develop a prototype to a feature that we think we want to use, you write down roughly what that is. Everybody talks about how it works, how you think it's going to work. You go build a few prototypes of that and then you test and iterate and then you decide whether you want to continue forward or you maybe pivot and try something different because you've got some information. And in my experience of doing software development, it basically quarters the time to get something out to a customer, to get real feedback, because you can guess all you want, but until you put something in people's hands, you don't really know how it exactly will be used. It will resonate. And that to me was just everybody enjoyed working on things that are successful. And to translate that to M and A The things here are, is that with the playbook, you have this long structure in this process that you have everything laid out and you follow the process and you know, kind of the beginning at the end and you know, you kind of push everything into the process to make sure that it fits in M and A. I feel like that you can do that, but there's always external factors. There's a. There's a time factor, often there's the flow of information, doesn't always come in nice and neat. And then there's market pressures. You know, if you're doing large transactions that are with publicly held companies, you can't take forever. You may be in a competitive situation where, you know, you have an exclusivity period of a very short window. So you need to decide that. And if you don't have a good deal or the company that's you're working with doesn't want to go forward, they can go somewhere else. So there was kind of a lot of pressure, just like in software, to kind of get something out earlier. In M and A, there's a lot of pressure to kind of get to, do we have a deal? Do we not have a deal? And then what do we have that's kind of changed that mentality. I also feel like M and A is not a perfect science. I joke repeatedly that the first time I do a perfect deal, I'll consider retirement. I don't think that's in my future. I say that because I think there is this desire to have everything kind of completely buttoned up, and I think it's important to work towards that. But I think the practicalities really get in the way of being able to do it every time. I think there's places you can improve and I think there's places where you can kind of iterate. But, you know, the scope and breadth of companies that I've worked at with across my career there has always been outlier or by nature, M and A is designed to be transformative, it's designed to be disruptive. So therefore it doesn't fit oftentimes in the night's neat bucket that your company is operating in today.

Right. What would you say are the main shortcomings of the traditional approach?

Well, my big one is, is that when you have more of a process and checklists, then people start to follow the checklist and work down the list, which is a fantastic feeling that you're getting things accomplished. But I have seen people get checklist fever for a better term, and basically means that you're not always stepping back and thinking about it and looking at it. Pilots have rigorous checklists, but there's also a stage when a pilot walks around the aircraft. It just generally does a general assessment outside of the checklist to make sure that they're ready to fly. I think the same thing happens with normal kind of processes. A good quote that comes to mind my first career was with the military was Patton, who basically said, if everybody's thinking the same way, then somebody's not thinking. I think that's just a good way to look at a checklist. This is everybody's thinking about the checklist, but somebody's not maybe thinking about what is not on the checklist. I've tried to build comprehensive checklists in my past. In the early days, either the list gets so long that they get so cumbersome that it doesn't work, or you're always missing something. So I feel it's better to step back and make sure you're grounded on what the key objectives are and then build the questions that help you get to that. Answering those key objectives first and then work down them. Because you can iterate as you go forward, but if you don't have the right goal and you're not aligned, you may be checking off, you know, some small components around, you know, compliance or just having clarity around some agreements, but missing that. The possible. I'm going to use example from like a customer agreements that all your key customers could walk on the first day you announce the deal. Well, that's. That could be a problem. You may need to think about that.

Okay, so you got getting your head out of the checklist and think more throughly about the bigger picture and just generally out of the box. Are there other areas that you think would be shortcomings of traditional approach?

A couple of the other ones are checklists and things like that are good for kind of discrete tasks. And we like to think about them as using them in tools. And you can rearrange the tools in the toolbox when you use them, but I think making sure that you have the complete understanding of the goals. And sometimes as the data unfolds, unfolds, or the information unfolds, it allows you to pivot and realize other unexplicit values that you may have not seen before. I can think of a couple cases where we were looking to buy key technologies, and after we started developing and looking into the company and how it was working, we realized that actually they had a manufacturing process that was considerably better than ours. And if we had just been focusing purely on the technology and kind of working down a list, we wouldn't have had some of the opportunity to kind of spend a little bit of time investigating this additional area. And in that case we actually took that additional systems and applied them to the corporate systems and replaced them because they had actually developed something two generations ahead of us. Ours was still a little old and crusty at that point. So it does help you kind of find not only the key values, but what I consider secondary values that you may not have really understood until you kind of look at the whole picture.

I've heard similar things where as you're going through a deal, you're constantly taking in new information. And as you take all these bits of information, it could eventually trigger a shift in your goals, which then becomes a whole aspect of acknowledging that shift and change of goals and realigning your team around it.

I think it's kind of the very nature of the word agile. It allows you to kind of look at a different piece or pivot. I just feel like there are some cases and there are some places where you have a very, very clear, tight goal and you're either addressing a unique niche or a unique issue. And if that's super important, then I think that there are times when, you know, keeping that laser focus is important. But most time acquisitions are to expand growth areas within the company and oftentimes they're not. They're adjacent to the core. So you're going to have an opportunity to look at something that is not the way you did it and that is always very informative. There have been a few times where as we've done acquisitions and talk to new companies, we realized that they tried something different as far as a business process or a sales process and it didn't work out as well. And that's actually a validation that what we're doing is better than what you know. We could have tried that and we didn't realize that we didn't need to because we got the answers here that it doesn't work. So those are kind of the hidden values that I think are really important to make sure you keep an eye for.

So you're adopting an open minded mindset as well?

Yeah, I think there's just an opportunity to learn. There are times when you see something that somebody else has done and it's like, yeah, that's way better than what we're doing. So then you pivot or think about how you can bring that know how or new view into, you know, your Existing organization, maybe identifying risks faster. Oh yes, interesting.

What drives that?

You know, first part of a transaction is let's look for the showstoppers. What are the things that give you pure heartburn? You know, what are those? Oh my goodness. Is that you're going to be. This is either something that's going to take a lot of work or we just can't touch it. I think if you focus on that first, if you surface them and you figure out what they are, sometimes that may mean that you don't have a transaction. That's pretty rare in most cases, but it does allow people then to figure out and give more time to thinking about, okay, this is a challenge. How do we address it? And if you're address looking at it from that perspective, which is the second shift, which is then what are the options? How do we look at it? How do we then maybe modify or optimize the transaction so that we are reducing those risks as we go further so that, you know, what looked like something that was going to be a challenge is less, less of a challenge or you know, is clear on what we're going to do. Which I think then also just by the human nature makes it easier for people to get more comfortable about it.

Gotcha. So going back to the theme about clarity, how does Agile impact process aspects and people aspects of working together?

I do think that there's a little bit of an iterative process around deals and some of it comes with the pace of the flow of the information and the flow of the negotiations in the earlier stages. Sometimes as the information is coming in in larger waves, we have kind of a weekly sprint with different teams as we're kind of working through the information. It gives people time to process it and look at it and develop, follow on questions or do their more research. As the deal progresses and you're getting closer, the tempo picks up because you're all trying to get it done. And so I have seen deals move to three times a week sprints, then in some cases daily sprints and sometimes twice a day sprints just because the nature of the transaction, we're all trying to get it all done together. And it just helps focus the kind of the thinking from long term, almost semi programmatic kind of what do we have, what do we need to do here to the ultimate goal of a deal, which is get it done. And so that kind of shifting that transition over time helps build that cadence up and gets the deal ultimately done. Because at the end of the day this is a transaction that starts and finishes and then starts another process which is my favorite is the integration, which is then how do we make this all work and how do we ensure the success of the deal?

You mentioned Scrum, are there any other agile techniques that you use to really help enhance collaboration?

We definitely think about sprints and we think about goals and we do think about phases around a deal. As I mentioned earlier, I think there's an early phase which is kind of is there a there, there, you know, is there something that, you know, is there something that is a. Oh my goodness, we need to, we really need to think about this. And that's pretty early and pretty fast. And so I really like to try to clear that as quick as I can because then that means we can start shifting to not the if, to how. And then there's I think multiple sprints along those lines as one team starts to figure out how we can do this. And there may be some. This sounds almost trivial, but it can get intertwined. Here is this. You may have a sprint from the philosophy's team saying, you know, we looked at where we want to put these people, but we really don't have space in this office or a nearby office. So we really need to think about building out the existing office. Well, that information now is kind of a one sprint result that now needs to be transferred to another team which is the team that's actually building out the infrastructure. And they're like oh well now we need to rethink what we were thinking because we were assuming we were going to move everybody to the corporate office and now they have to re sprint on that to understand what they can do, how we can make this work. And then what does that mean ultimately back to the people. Because now we need to be really clear that we weren't clear at the beginning where if we're going to have to move you now, we can be clear that yes, you get to stay in your office for a period of time while we're building out new facilities or we have a long term goal here for, you know, integration. So it does allow for these kind of subsprints to work or fracturing off of work work streams. I do think that there's kind of a always a master deal Sprint and that has two big pieces. One is on the transaction and the actual legal process and that has its own cadence. And then there's also then the kind of as we're going through these phases of you know, is there, there, there, what does it mean? And then continually iterating to refine that program to a point where we are at where we have clear understanding of what we think we should be doing and what we think should work as a post close integration.

Are the teams structured different from a traditional versus agile approach?

So for the deal team, you know, we have deal leads and integration folks and we're, we live in the role of agile and then we have a layer of cross functional team support. And this is true for most organizations I've worked with or most companies that are dedicated or largely dedicated M and A professionals that work around transactions. And this is more for companies that are doing more serial acquisitions. I'll pause and come back to companies that don't do as many acquisitions as frequently. And so those teams tend to function a lot more in an iterative sprint kind of fashion too. It's kind of almost a cascade of the deal process. Where those cross functional teams challenge though is that they often are a layer between what I would consider more traditional waterfall teams. And what I mean by that is for some parts of different companies they'll be more structured than others. Most software engineering teams are a little bit more agile as we see different companies. So as a new acquisition comes in, sometimes they look at the integration as a series of sprints as part of the engineering plan. But if you've got kind of infrastructure around, you know, back office components like order to cash or facilities, as I mentioned earlier, those tend to be organizations that are much more waterfall cascade planning. So in those cases I do feel like sometimes that that cross functional team has got the unpleasant job of going and talking to these teams and saying, you know, there's this M and A transaction. I may not be able to tell you all the details, but it's going to throw a spanner in your nicely formed plan. And you know, I'm very conscious of helping those team members out because you know, we have had teams that are like I, you know, we've done a few transactions where, you know, take htc, several thousand people were all of a sudden going to employ in Taiwan. I know that the Taiwan facilities team did not plan on housing 2,000 people in Taiwan next year, three years ago. So that is where you have to sit down and kind of work with them to help them understand the rationale. And then I also feel like in M and A we have a little bit of an opportunity to flex or draw resources or highlight the need for resources to help provide those teams that have got more programmatic challenges to be successful. And oftentimes as I'm looking for really seasoned Integration folks that have come from within an organization. I'm looking for people who know how to get things done, but also know how and how far you can work to bend the rules for those more structured teams. And that may be that. Okay, you know, we'll do is we'll now get you budget for, you know, the next three years to build those facilities out in that case, but in the interim I will also get you budget so that we can figure out a short term interim solution. And I am now part, even though I brought a problem to you, I'm going to be part of your solution. And I think that is really important to recognize that you're shifting from the dynamic world of M and A, then what can you bring to these more functional teams to make their lives easier and not expect them to move to an agile mentality?

You're touching up on a lot of the pain points. I frequently hear about collaboration across functions and work streams. How do you specifically address that?

I think the first one is raising and being conscious of the awareness is the difference and sometimes it is really easy to get swept up in one way of thinking or the other. So I think there's that just consciousness and being mindful of it. I'm clearly in the integration M and A Agile world. One of the things I have encouraged teams to do, if it's in slower talk or just part of a regular transaction, is pick a domain and spend a little bit more time with that domain to understand their processes and how they work. And if it's more structured, why is it structured, how is it structured? And I have asked multiple times for integration managers to spend a period of time just leaning in, you know, on this deal. I want you to spend a little bit more time with the HR team to understand, you know, how we set compensation, how we set levels, how do we set promotion cycles so that they understand that world a little better, so that they are more conscious of if we're going to do something that's impactful, you know, can you raise it to them on a no name basis earlier so you give that team a little bit more lead time or set expectations that this is the way it works, this is the way it has to work and this is how we're going to have to spend time to make sure that it is successful.

How has Agile created more process efficiency.

Within your team allowed us to focus on building really good robust tools? Because there are some components about M and A that are just purely programmatic. Take the example of onboarding employees. You've Got to create offers, you got to get the offers to them, you got to get them accepted. Then you have to think about what office they're going to enroll in and get all the, all the benefits and pieces together. That's a pretty consistent process. So that's a tool or a series of tools that we use from our cross functional team. Now where we choose to put that or have that conversation may vary on how many people are in the know. What's the stage of the deal? You know, is it really a large team? Because clearly, you know, you have to kind of have more depth. If it's a big team, if it's five people and everybody knows about the deal because they're all sitting around in the same office, you can have that conversation super early, which is just helpful because then everybody knows and has good sense for where they're at. Other areas are examples that are very programmatic or have tools around our finance integration and moving everything on our back office to our back office accounting systems. There's a series of questions, what we need to answer, we need to have a series of information about it and then we have a very clear plan. Now, depending on whether or not the CFO or the finance team members are engaged and are in the know in the deal often varies. They're usually engaged certainly very late in the game in most cases. So that process tends to be a little later in the deal. Now if it's a deal where we want to think about revenue or income or revenue streams, or it's a business like retail that may be more upfront. So you may have that, you know, you're shifting these kind of pieces around. So I, I kind of sometimes think about them as LEGO bricks and I kind of think about where we sequence the LEGO bricks in the, in the process as we're building a foundation for the deal.

And that could fluctuate.

Yep, very much.

Have this approach enabled you to close deals faster with more equitable outcomes?

I definitely think it helps close faster. And I think the quality of the deal or the quality of the knowledge is much higher than where I have been, where I've worked more traditional waterfall processes. Because you really have focused on asking and focusing on the questions that are key for the deal. I mean there's always after a deal closes, a certain amount of cleanup work or remediation work or things that you know that you need to do to just get everything lined up nicely and working smoothly. But you know that that has to happen and you know that those are problems that you can solve. If you're spending your time looking at that or figuring out those details and you're not focusing on the strategic intent, you definitely have not used the time wisely. And you know, those are items that do tend to take care of themselves. But if you've kind of not fully understood that, oh, they're using a programming language that we have a small set of team members that work here that know it. So any integration work that's going to work as far as the two teams working together, that's going to require some more training on our side so that we know and understand it and training on their side so they understand our languages. And that's a big thing that you'd want to focus on. And that's something I'd want to make sure gets done first, you know, to pick on. Maybe that they have a different form of standard computer, but it basically everybody works remote and terminal, you know, VCs in to do the development work. Well, that's kind of a hollow, not as important environment or issue. You know, if you're working off of a Chromebook or a Mac, that's a pretty easy thing to kind of figure out or get used to. But yeah, if you spend all your time thinking about that, you may have missed this other piece that could slow down engineering velocity and getting something out to the customer faster.

That's important. You have me sold on Agile. What were the challenges in introducing Agile approach to the deal management?

It's interesting because fortunately at Google we're an engineering culture. So if I say Agile, a decent chunk of the company understands it, but oftentimes you're working with domains that understand coding or don't have to. And you mention agile to a legal team and they're like, what are you talking about? And I think that that's where you have to kind of think about how to oftentimes reframe it to what are, you know, let's focus on the key goals you have to kind of, it's back to that ambassador role of trying to use language that fits for more the process side, but really creating a, an agile process.

Can you give me a little bit insight in terms of how a team should start that process of making a transformation Agile.

One of the big aha moments for most folks is going back and looking at deals that you've done recently or over the past. And I have taken the playbook and tried to apply it to the deal, kind of run it backwards and then if you do that for a few deals it often people realize oh, well, if we'd asked these questions in this format, we probably wouldn't have gotten the information till too late. And because they had the full picture of it, they see that that whole life cycle coming through sooner. And then sometimes, oftentimes people say, well, let's put all those questions up front. And then you realize like you put all the questions in the first half and you just can't. A target can't sustain that. And then there's kind of a conversation that often happens about, okay, then how do we triage them? And then people are like, well, okay, let's triage it for deal X and then let's triage it for deal Y and deal Z. And then people start to realize that the lists were different. And then I think that's your magic moment to start saying, well, what's the goal that we're trying to accomplish for these deals? And that kind of begins to shift the thinking. And I think that that's always the kind of way I like to bring it back. When I'm working with people, I will often say, look, there's a thousand things to worry about in a deal, but I'm a pretty simple person, so I want to know the top three and what are those top three? And that kind of is a way to invite that conversation. Then you say, okay, what are those top three? Then what do we know, what do we not know, and how do we get to knowing more? That almost fundamentally kind of gets people in the thought process of let's answer those questions instead of the list, if that helps.

I like this because it segues into one of the techniques I really like about Agile is the backlog you mentioned not front loading all the questions up front. Yes, I want to talk. This is very personal to me because I came in the industry with a vision of building a better software solution. And that's probably the biggest pain point I've seen where it's a lot of batching done in Excel. I really want to hear your perspective because it seems like you've done both where you've had the list where it's front loaded, you're batching a lot of the questions and you're waiting for a couple people to respond over a number of days versus and maybe you can even explain how the backlog approach works as well.

Yeah, I definitely think there's this understanding of kind of asking a series of questions. And I think it's very important to. Everybody has their, everybody has their questions and everybody's questions are valid. It's Just more which ones do we need to have first that you can understand, will unlock, or I would say clear issues that are, you know, that could be larger. And that's where I think it kind of comes back to this triaging piece. But to your point, as far as like standard lists, I mean, everywhere I've been, everybody has a standard list. And usually you edit it a little bit before you send it over. And then the target goes off and works them. And then you find this process where you've given them maybe 200 questions, 300 questions, and everybody in the back on the cross functional team or all the different domains are like, I need this information. I need this information because I can't do any work yet. And that's where you start realizing these are the questions that we really need to accelerate because these are the people that are really anxious about either for good reasons, why they need to know information. And so I've seen dynamics where, you know, teams have sent over lists and then you follow up a little later on going, yeah, I gave you these hundred questions, but really these top 20 are most important. And if you do that one or two times, then you realize, oh, I really need to spend a few minutes figuring out what those top 20 are. So we get those first. Because then you get into this waterfall process where I've been on both sides of the transaction, and it is maddening to go off and work on the 200 questions and then realize that there were really probably 20 that were really important and you could have gotten those over sooner. And then as soon as you get those 20 over, then there's. They spawn 30 more questions. And then it's like, so I need to go do those 30. Are they more important than the remaining, you know, my math, 160 left over. And most CEOs or executives on the other side will at some point say, okay, I'm happy to answer all these questions, but I really need to note on order. And that's where you kind of start developing a diligence list backlog. And that's. It's uncomfortable because I feel like you've just put a team through a lot of effort and you're getting answers and you're getting information, but is it really going to make a big difference?

So then would you have a dedicated effort to periodically reassess the prioritizations?

Oh, yes, actually, for me, as when I'm working a deal that's twice a day, that's first thing in the morning, and as I'm kind of working through What I think are the issues I need to think about. And then that's in the evening probably, you know, depending on mid afternoon, I start working on, okay, what are the things I need to kind of get back over so that I can have people in different time zones or different teams work it. And part of that revolves around another dynamic that I definitely try to make clear across all the teams is when you're doing a transaction, and this comes from my experience of being on the sell side too, is the team and the company and the CEO all have a day job and that's running the business and they got to keep that going. And if it's, you know, they're trying to keep it super confidential, you know, they can't be in an office and locked up in a room for big chunks of the day for multiple weeks without people freaking out. So you have to work these kind of questions and you have to think about them. And oftentimes early in the morning because sometimes they can come into the office and work it early or late in the evening when they get home and they can work it or they stay late. So, you know, thinking about working with these people and making the process as humane as possible, you know, I really think about what are the top questions because sometimes I'm asking this person to stay up late at night or maybe work a weekend.

This seems like one of the biggest differences between a traditional agile approach is you have this backlog, you're continuously reassessing the prioritization of it, where typically it's an excel sheet, things get tagged high priority until half the list is high priority and nobody really knows what are priority versus here it's traditional backlog. You're keeping a descending order of priority. So it's much clarity in terms of what's the top priority, second and so forth. Does that sound right?

Exactly to your point. When I've seen those long priority lists, I've declared priority bankruptcy and then everything goes away.

I love it.

Because then it forces it back again because yeah, there's just this. There are times when it helps to have a list because you have multiple teams and it's like, yeah, there can be only 10 high priorities. And that forces a conversation right there because yeah, I just feel like if everything, it's classic thing, if everything is priority, then nothing's a priority.

Right, agree. So is there any other techniques that you utilize in terms of getting an agile mindset spread around?

I think the big one is kind of keep going back to every company has its different approval processes but somewhere along the way there's somebody has gone and put together a document or a deck or something and say, this is why we're buying or this is why we need Company X. And those I look to fully understand and boil them down into litmus tests. And I use those. Sometimes teams get a little sick of them and then I will ask the question, does it support blah, blah, blah. And if they go, yes, then okay, then where does it fit? And if they go here again, it's really important, then let's work on it. If they say, well, no, not really, then it gets on the backlog list. It's just a quick way to get everybody to start understanding this is the most important thing we need to solve first. And once we get that, then we can work on the other pieces. But we really need to be making sure that we all understand and we feel very comfortable that we can reach that first strategic objective that came from the deal rationale and that's the North Star we use to test every time. And if it's not well defined, we really try to make sure it is well defined.

I hear this often gets lost in integration. Just as soon as we hit integration post close, all this stuff goes out the window. How do you keep that sort of clarity there with that big picture?

Everywhere I've been, there's either been some form of success metrics that you use to track or OKRs. And those OKRs need to tie back to those key strategic objectives. And there can be what I would consider integration okrs for making sure that the business works fine. But those I make sure are all cat lumped as there's lots of different ways to label them. But usually I prefer functional versus tactical. But I always try to make sure that those three key objectives tie back to and integration objectives tie back to those strategic rationale. Because there is. I totally get where you're coming from. Where there's this integration inertia is the way I like to look at it, where it's like, oh, let's just put it all, wrap it all around and make it all warm and comfy and make it part of us as fast as possible, which I totally get. And that there's a lot of optimizations that can happen that do in the end make sense, but sometimes if it causes harm or can erode attention to those strategic values. That's where as integration folks, we really spend time making sure that everybody understands you have to kind of be traffic cop and defend it a little bit and push it off and say, no. Not now, it will come later. And everybody can live with later as long as they know that you're really willing to deliver on later. If later becomes never, then you've lost your credibility.

Right.

So I do think that's the other part of it is making sure that you do clear the backlog at the end.

What about integration planning?

So I do think that there's kind of a couple things that happen here around integration is that as you're starting the deal and the deal rationale, oftentimes there's an integration hypothesis is the way I like to think about it. And that's where we think we know how this is all going to fit. And we'll start going off and trying to make sure that it does. We're seeing if it does and if it doesn't, then we need to think about that very carefully as you go forward. Usually some point of checkpoint during the process. Is this still a good deal? Is this still what we want to do? That's a point to kind of update that hypothesis to maybe more of a thesis and move towards here's where we think this is going to be or a strawman or a sketch outline. And so that that gives kind of the next layer of clarity and also helps you kind of begin to test at another level the detail of what the integration plan is. In a lot of transactions we also like to have kind of a checkpoint with the target. Either write it pre close, depending on how the deal works, if there's long review periods, certainly during the review periods you can talk about integration but you can't do anything that's a good kind of kind of test and rationalize plans to. Right after close, we often will have a series of detailed deep dive conversations saying, you know, hey, here's what we are thinking about doing. You know, how do you think this fits and how does it work? And that's kind of again testing the thesis more or defining it or formulating a plan.

What about post close? Does that plan continue to iterate?

Yes, we do iterate. When we close the deal, we set the key goals or objectives. We then have a 30 day, 60 and 90 day check ins and the intent there is to tune those goals. If we're resetting them, then there's a big question on why. And there may be good reasons, but that's always risky. It usually means we miss something. And to me that's a big learning opportunity for us to step back and okay, what did we miss? How did we not understand that this was going to take nine Months when we thought it was going to take four weeks.

Now you're leading this integration plan. How do you get feedback from maybe the work streams to sort of see some of the things that they need? That's really particular to that deal.

So we still continue to hold weekly sprints to make sure that everything is kind of moving forward and some transactions that they're bigger. We may actually hold several sprint meetings during a week. Those tend to start to ramp down as we see the supporting teams catching or the integration being more functionalized across the Org. And so there's kind of a natural progression. You know, I. This is the phase where I affectionately like to remind us as integration managers, this is where we get to work ourselves out of a job. And that's where we have to kind of make sure we're ensuring that people are there to catch the information, making sure that there's handoffs. We do have pretty much everywhere I've been. You always have a formal handoff process at some point where it's like, this is where it's at, everybody's got it, or here's the three things that people are still working on, but there's clear owners on it and they're off to go.

Describe a deal you worked on which you feel exemplifies Google's agile approach to M and A.

So we did a series of big bets and this was kind of around the Google X acquisitions and some of our kind of, I would say real greenfield opportunities. And the deal that I can think of is a company called Titan Aerospace, which they build a high altitude solar powered UAV that the idea was is that you can have Internet connectivity coming from satellites and we have Internet connectivity coming from balloons. But balloons have a little bit of a challenge because they're at the whim of the winds. And with the UAV that's flying at that height, you get better bandwidth than you do from a satellite. But you also get what they call station keeping, which is basically you can park it over something and it will stay there and act as kind of like a cell phone tower in the sky or a satellite really, really close. So we and Facebook were both looking at these technologies. Facebook bought one company, we bought another. And I got brought on to do that deal. And it was pure agile because it's not a core business of ours. I mean, we do know a lot about connectivity. We do know some things from the Project Loon, but you know, we don't know anything. We didn't have a. This is a playbook for buying Aircraft companies here at Google, and there's certainly none for solar powered UAVs. So as we started to do the diligence, we created a series of questions that are like, these are things we need to understand and these are things we need to believe to make this deal happen. And they start out very high level from just pure philosophical perspective. And then as we started to do the deal, we started doing more diligence and we started realizing that we needed to bring in more domain experts. And one of the things that is really nice about Google is we have this huge population and we have the ability to kind of search everybody's resumes before they join Google. It's something that you submit when you start here. I was able to work with the HR team to start pulling resumes of people that had worked in aviation, which was the first set. And then I could work on people that had worked on UAVs, which is, hey, there was a subset of that. And then there were some people that I could work with on solar power. So I started figuring out, here's some good people I'd like to bring in. So as I started bringing these people in and they were, I mean, amazing domain experts, they would start asking questions that I'm like, you know, one of them would start asking, you know, like, what's your FAA certification stuff? And I'm like, we haven't asked that question. So that was an FAA sprint. And you know, that was super helpful to kind of have that flexibility to work through the diligence and in that case, integration planning, because the deal moved very quickly. So we, we closed the deal and then we started spent several quarters building up a detailed integration plan because there's, you know, we knew that this was a long shot. We needed to set a bunch of infrastructure up to support it. So yeah, every new domain expert I brought in brought in a whole new set of questions that I, none of us had thought about. So we kind of almost had like mini sprints just because of the questions they brought in. And so that allowed us to be very flexible. We did do very, I think from the, you know, sizing up the deal, I think we did a really good job of getting the right people to understand what it was. We knew it was really high risk. Ultimately it was, I think we pushed. The technology just wasn't there and it didn't pan out. But several of the members of that team were now off on other projects here, so which is a great opportunity for them. And I think we did bring in a lot of interesting talent. But yeah, that was the deal that there would have been a playbook. Wow.

I appreciate that example of using Agile on an M and A deal. Hey James, I enjoy this conversation. I appreciate taking the time with me today.

I really appreciate it too. It's great. I'm a big fan of it and if people have questions, you know I'm always happy to help.

Thank you for taking the time to explore the world of M and A with our podcast. Please subscribe for more content and conversations with industry leaders. If you like our podcast, please support us by leaving a five star review and sharing it. I enjoy hearing feedback and connecting with our listeners. You can reach me by my email. It's Kisan K I s o nealroom.net M&A Science is sponsored by Dealroom, a project management solution for mergers and acquisitions. Additional educational content is available on Deal Room's blog@dealroom.net blog. Thank you again for listening to M and A Science. See you next time.