Bringing M&A and Business Agility Together

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.

Hi, I'm Toby Tester and you're listening to M and A Science. We talk to deal professionals and learn valuable lessons from their experience. This podcast focused on stories, strategies and what actually happens on M and A Deals. In this podcast, we're shaking the format up a bit. Instead of Kisan Patel talking to M and A professionals about their experience, it's Kisan himself and his thoughts and ideas that we're talking about today. Let me introduce Kisan, but before I do so and about his game changing ideas about M and A, let's get a bit of context. First, the world of M and A as a corporate discipline for the way businesses are bought and sold has been around for several decades. Round hundreds of books have been written on the topic. The subject is widely taught in business schools and around the world. It has become a career path for many aspiring executives and it is easy to know why. Over the last two decades there have been nearly a million deals that have been made with a known value of over $57 trillion. Now that just says one thing. MA is big. It is also important M and A provides the means by which organizations grow and prosperity. Now, Kisan has done something that I think is quite interesting for anybody involved in the business of M and A. He's written a book. The book is called Agile M and A Proven Techniques to Close Deals Faster and Maximize Value. Welcome Kisan.

Thanks for having me, Toby.

That's good, Kisan. I personally think what you've done is both interesting and somewhat provocative. There's a lot of merit to bring the two worlds of M and A and business agility together. But I'd like to ask you some challenging questions to really get into. Perhaps what really drives you, thoughts and ideas and why people working on M and A deals need to stop and take notice. Kisan, just in one or two sentences, explain to the listeners what exactly is Agile M and A?

Agile M and A is a project management framework that emphasizes responsiveness, collaboration and continuous improvement.

Okay, and what made you want to write the book? What sort of like drove you?

It started probably around three years ago, Toby, where I would work with companies, whether investment banks or corporate development teams and saw that there was no standardization. Everybody had their own approach to M and A and I had these ideas. Learning different project management techniques from our own internal software team that I thought would be very much applicable to M and A, particularly the way they use their different agile methodologies. And I started blogging about it initially and really got strong validation when I interviewed companies like Google and Atlassian and really understood that they were actually applying these same agile techniques in their M and A process stemming from their engineering culture with great success. Which really prompted me to push forward and create a framework and drive that into this book so that it could be shared and distributed with other corp dev teams that could benefit by evolving their process and managing M and A.

Okay, that sounds good. Look, it's certainly interesting and look, I have certainly read the book from beginning to end and it's a very good read. So. Yes, but tell me something, obviously having written the book, very good, what do you hope to achieve from this book?

The goal is to really be able to evolve them in a process so that we can deliver better results, enable more of a collaborative, people focused process to deliver better outcomes. I think we both know there's a lot of sad stories out there of companies that start M and A with the grand vision, but by the time day one hits, it becomes total chaos and they're missing out on those initially predicted value drivers and it ends up in a sad story.

Yeah, okay, look, talking about chaos and total chaos, look, I'm sure there's quite a few people listening to this and they'll say, well look, hang on a sec. We do things pretty. Okay look, we've been running deals for quite some time. You know, we've got a discipline, we've got people who know what they're doing and they'll probably say, well look, you know, we got down pat. Why do we need to change? You know, we think we're doing things quite well.

Well, I don't see things getting better. You know, our, our, our market and climate's changing. Companies are becoming more information based and they're requiring more overhead to actually manage those projects. We're still seeing a continuing high fail rate and companies are still missing out on their initial investment thesis. So there's a lot of people in M and A and roles as well that truly aren't qualified. There's not that strong discipline for managing these transactions. So I think there's a lot of room to bring forth more standardization and surface the evidence based approaches so that teams can actually approach M and A more efficiently.

You know, Khsan, I think you're right that there's, you know, there is, you know, reported failure rates and chaos and all that. Sort of thing. But I'm sure if you spoke to organizations individually, they'll say, well, yeah, that happens. But that's nothing. That's not us. I mean, we do things fine. That's all about other people. How would you say to a individual organization who think they're doing things, okay, we know we're doing it. All right, we believe we're doing it. We got a little down pat. Why do we. Why do we need to sort of follow a different approach? I mean, they'll say to you that, you know, look, it's fine. I know, but that's. The other people are doing it all wrong. We're fine. How would you convince them?

Voices need to be heard, Toby. So I see this a lot in companies where the senior corp dev level people really see a pretty picture and things are running smooth. But then when you dive down and talk to the opposite end with people actually executing integration, you hear more. A different light of a story that's more painful and challenging. And what I usually start with when talking to companies about their process is start with mapping the process out. Understand where the corp dev sits, who do they report to, where integration sits, how are they communicating with each other. And from there be able to identify the key Personas. Once these key Personas are identified, have one on one qualitative interviews focused on discovering their pain points and challenges and being able to prioritize and have some kind of understanding of what that weight of pain point challenges are. And then also dig into it, layer some questions, the analogy or approach of asking why five times to get to the root causes, but taking that information and bringing the group together in more of a roundtable format to discuss those challenges. That's when you start getting a lot of eye opens around what actually are the, the underpinning challenges that leadership may not be aware of. So I think there is. Every company has a level of challenges. I've never been to a company where I've had multiple interviews and everybody says things are great. There's always some underpinning challenges there. And you know, the person that may be leading the team may not see it, but it's definitely there. And it takes that bit of time to have that one on one conversation to do the discovery and make that transparent so that there's a clear understanding across the team.

No, I get you there. And I think if there's the opportunity to delve deeper in any organization, there will be challenges. But don't you think that perhaps the biggest challenge is actually for organization to admit they've even got a problem with their M and A process.

Yeah, I agree. I think that's probably with a starting point. Because what the problem is, Toby, we get fixated on the front end of the process. We want to find the deal, we want to value the deal, negotiate and sign a letter of intent. But everything past that ends up in the blind side of the mirror and we're not focused and we're not paying attention. But they're the most critical stages. That level of diligence is required to be able to identify the real risk in the transaction and even some of the underpinning opportunities in the deal as well. And to be able to take that opportunity, organize information so we can develop a comprehensive integration plan so that we have everything aligned so we can execute things well from day one. And that stuff doesn't become a top level of focus. And I think when it does become surface as a problem, it's in that too late stuff.

Okay, let me ask you a slightly different question from your perspective and from the book, what makes Agile so different to the way perhaps organizations are running their M and A at the moment?

The approach. When you look at an agile approach, you're focused on having a process that's adaptive, flexible and responsive. Whereas the traditional approach you're very putting a lot of effort in planning things up front and creating a detailed plan, sort of like building a house. Because it works if you know all the variables and the steps, you know all the steps involved and can plan things out. But when there's a lot of uncertainties in terms of what the end state is, which is happens in M and A, because there's a lot of things that could fluctuate as you go through the different stages of the deal. So those are the main drivers. And we talked about this before, it's a mindset as well. Because to be able to be agile and have a responsive process, it requires a change oriented mindset that is focused on creating an environment that encourages collaboration.

Okay, that's a good one. And it's interesting you talking about the sort of, the big benefits or what's so different about Agile. The last thing you mentioned was mindset. Do you think Agile is more about mindset than it is with process?

It's definitely more focused on the, it's definitely focused on mindset because that's where it starts and ends. So that mindset is what drives agility and the leadership is what's going to enable the practice that follows through with the process.

Now it's interesting because you know, when we talk about mindset, and I think I'd be pretty right in saying this, that I think M and A broadly speaking, as a corporate discipline, it's quite a conservative discipline as well. In other words, it's based upon some very trite and tested sort of approaches in terms of how you come to a deal, how you make a deal, how you close a deal, et cetera. And that mindset is quite entrenched. So in other words, it's quite a conservative approach way of doing things. How do you propose changing that mindset?

Giving a compelling reason to change? I think that's the biggest driver because people are stagnant, they don't want to change their behavior and do things. But the reality is in the top reason what drives change is a compelling reason too, which ties back to taking the time to do the discovery, understand what the pain points are, whether they're very obvious or digging deeper and finding the underpinning challenges.

Now you say a compelling reason and I'd agree with you. Do you think that perhaps agile works when perhaps an organization perhaps is doing a major acquisition or there's some sort of element of crisis? It comes down to this whole notion of a compelling reason because I think a lot of organizations will say, well look, we do things at the moment, we kind of muddle our way through, we don't need to change things. So where would be the compelling reason.

As a deal progresses? Right, we start off with a deal where maybe there's very few people involved. And as we continue, more people get involved in the deal, we get through diligence, more different functions get involved, third parties get involved, third party council gets involved, we go through this to integration or even more people get involved and you're working with a target company. That whole process continues to get more complex as more information comes in and more people are involved. And that's where you see that real reason of creating a process that can be adaptive and, and continue to evolve and respond to this growth of information and participants. So that's a big reason. And it's important to do that early because early on you don't see those problems when you only have a handful of people that know about the deal. But by the time companies often feel the real pressure and pain of an M and A process, they're at that state where it's very difficult to change things.

Yeah, no, I agree with you. Now it's interesting you mentioned a couple of times there the word adaptive. Everybody would agree with you. We all need to be adaptive, responding to whatever the circumstances. But obviously I kind of sense that when you talk about adaptive, it has a kind of particular meaning. So when you say adaptive, what do you actually mean?

Being able to just change and pick up how those variables are changing in the process? Because you may do a deal and as things occur, there's just a lot of unknowns. When we start a deal and we look to acquire a company, we have a little bit of information and we start developing our financial models and building the case for doing the deal. But as you go through and get more information, we're going to learn new things which change constantly, change course and how we need to approach things. And we may find out they're not using Salesforce for their CRM, they're using a totally different proprietary tool. And we need to completely rethink how we're going to integrate that tool into the company's process, or maybe we don't and so forth. So there's that requirement of being adapted because as the resources and requirements are going to continuously change, it's important.

Okay, so what does adaptive actually look like? I appreciate that and I know there's a lot of things that will be changing, discovery, et cetera. But let's picture this one. So here we are, we've got an organization, they're going down, they're applying the Agile M and a process here. They will be adaptive. So they're going to respond to change, which is quite appropriate. What does that actually look like to an organization? What do they actually see? What's different?

Okay, so let's take the traditional company. They typically start off where they don't have a clearly defined project management framework to follow. They're usually using emails, Excel spreadsheets, a virtual data room, the very default common tools. And they're going to start a deal with a checklist. They're going to pick up a templated checklist for due diligence so that there's a starting point and they can run through the process. And then as more people get involved, different functional is going to get involved. They're going to have their own checklists and these lists are going to get bigger. And when we go through this, we're going to start tagging items as priority because obviously we can't work on all these things at once. And we're going to start tagging more and more items as high priority until a third of the list, half the list, becomes high priority and there is no clarity on the priority. And then now we have all these lists, that becomes confusing and we're using weekly meetings as our check in points where everybody's checking in and they're very much focused on what they're going to update the group with instead of listening. And then from there, because we have these long extensive lists that don't have clarity in the priorities, we're creating additional overhead to manage and track the dependencies, which can become a full time role for somebody. Then as we continue and we're going through the integration process post close, there becomes this lack of communication between different functional work streams, which can cause redundant work. So that now we're bombarding the target company with duplicative requests and they're getting inundated, they're getting frustrated, and everybody's scrambling around their checklist to meet milestones and nobody really knows or forgets what the original deal thesis is and truly lose sight of that big picture. When we reshift this whole model and take that same process and agile approach, it's different because one, the first thing we're going to do is not use Excel sheets and send them back and forth and deal with this issue of the prioritization because it is a big challenge to keep your teams focused on the highest priority tasks throughout the transaction. So one agile technique they use is a backlog approach where you consolidate your list as much as you can and keep your list in a descending order of priority so that there's clear visibility in what the highest priority items are. And from there this list is usually on a project management tool, so it's very easy to drag and drop things and adjust this priority. And it does create a little bit of overhead because you gotta assign somebody responsibility to periodically groom the list as things get continuously shifted around. But it does create this very clear depiction of what the highest priority item is and allows us to move in a shorter cycle because we're not gonna email 300 responses to A list all at the same time. We can do a short daily iteration of the top 15 most important items and be able to get responses of those in much shorter cycle, which actually moves that deal process along a lot faster because everybody's laser focused on the highest priority items. And instead of those extensive weekly meetings where everybody's grouping their findings and porting them in, we're replacing it with short standups. So as the process continues, we're creating status update meetings that are short last 20 minutes and everybody huddles together. They give each other an update on what their past activity is, what they're going to be doing till the next meeting, and then Any blockers or showstoppers. And this creates this very dynamic interactive way of working together because you're having more frequent touch points, you're holding yourself accountable of what's going to get done and you're able to quickly identify any problems and issues. And this helps with a lot of those dependency issues that come up. The structure, I think is another point too. Instead of having large groups, particularly in integration, that are designated as functional work streams, instead you're creating smaller cross functional teams that are focused on a specific goal so that the first step is to prioritize your value drivers of the deal and extend it with goals around achieving those value drivers and building cross functional teams. And this is something from the software world where traditionally they would have all their backend programmers and team front end QA so forth and it was highly inefficient, very expensive and unproductive to develop software. But as they moved to the Agile model, they would have a person or two from each group able to form a cross functional group that actually executes on a specific feature or value of that software and then they're able to go about on their own and deliver on it with independently. So the idea is to bring that same model to M and A so that you can create a series of cross functional teams that deliver. And so it's a very different approach when we look at that because now we're creating from the beginning to end process that's very responsive in the way we prioritize things, the way the meetings are conducted because they're coming short, more frequent, faster meetings, the way the information is getting distributed, distributed by using chat, project management tools. So there's a continuous flow of new information as it comes in and people can respond to it. And if there's a need to trigger a change in goals because of new information that comes in, it becomes much easier to quickly realign your teams around these new goals and that these cross functional teams create an organization, allow teams to better execute.

Now there's a lot there and let me just go back just so that people listening, you know, let me sort of recast what you just said and sort of put it back to you. The big change with Agile M and A is it brings the practices that we've seen in Agile being used and say in software or product development. There's a few things you mentioned. First of all, I think bring in the notion of a product backlog. In other words, that's something that works in the software industry. Bring that notion into M and A. That's one part, have fast meetings which is like your stand ups. Ramp up on accountability so that people are accountable and they're made to be accountable. Then we talked about having value drivers. In other words, don't organize your teams according to the company divisions, I.e. marketing, Finance, Legal. It instead organize your teams according to the value that you're delivering which is cross functional. And the last thing you mentioned is this whole notion of transparency. So everything that you do is through the tools we use. It's open, straight up. Everybody gets to see the whole story. There's no cover up.

Yeah, but it's very different. Toby. What I'm seeing in all these companies I work with, I mean the exception are a handful of tech companies that are absorbing agile from their, their engineering teams. And I, and I've seen that that trickle in where it starts off with integration and there are some engineers that are responsible for integrating tech components and one of them eventually gets promoted to leading integration where he's bringing the different work streams together and starts reconfiguring their whole approach around integration to follow an agile approach. And then eventually they get more involved earlier in the process because that naturally gravitates for the integration person to essentially eventually lead diligence and then the whole M and A process becomes very agile based. We're already seeing that happen and I think this is the next step forward for M and A because we look at manufacturing. What propelled manufacturing industry was lean manufacturing and innovation in their process. What propelled the software industry was innovation in their process with Agile. And the next step is for M and A to evolve their process.

Yeah, no, it's good. You know Keesan, I'd like to just go back to just one step though. And it's just something that, you know, it's something you said just a little bit earlier on is this whole notion of accountability. Now we all understand, or at least I think we understand what accountability means. But I think the thing about Agile and it's something you mentioned in book, is that accountability is something that's kind of like becomes rather deeply personable. You know, it's like you really are accountable for what you do and the whole structure, the way it works and sort of thing, it gets that whole accountability done. Don't you think that potentially if you introduce this, people are going to say hey, that's just too confronting. You really are putting me on the spot here. And that doesn't look good in front of other people. I don't like this. I don't want to be made this accountable, what would you say in that particular circumstance?

I think that's a culture, right? Because if you can evolve your culture to have a high level accountability and transparency, that's what Agile is all about. To be able to have a stand up and know what everybody's priorities are and what they're working towards. It really makes you feel part of a productive team that's making a great deal of progress and everybody understands what their contributions equate to. So I think there isn't anything to shy away from it. It does take a bit of getting accustomed to, but in the end of it it creates a much better team working environment just to have that level of transparency and hold a higher level of accountability by making those responsibilities and what the different tasks everyone's working on transparent.

I agree with you. And the funny thing is, and here's the sort of paradox I think is that I think a lot of people talk about accountability and you're not going to get anybody who says, oh, we need, you know, don't need accountability, of course you need accountability. We all need accountability. Everybody will say and say, absolutely, we got to be accountable for everything or whatever we do and make sure we drive it down to the individuals. But it's the difference between what people say and what people do. And I found out in my experience is that people will talk about accountability a lot until they're actually put on the spot. And that's the very issue, it's very confronting to be following this Agile process and be put on the spot to be made accountable. And I think it's, it is a big thing and I often think that that perhaps is might be the biggest resistance that you might get applying this sort of process. I mean, would you agree it is.

It'S a change, right? Because if somebody's used to not having that level of accountability, it's a change and it takes some getting used to. But if we look at some net root causes of problems, 90% of the time it's going to be related to communication accountability.

Yeah, I agree, I agree, I agree. And I think that that's part of the challenge. And I think, and maybe I don't know if you agree or not, but I think when, you know, in a broader sense, if we just not talk about M and A, but if you talk about introducing Agile into any organization, I think this whole notion of accountability is a big thing and people need to be, you know, accept that this is a different way of working. It is quite different to how you've done things in the past. And I think. I still think it's going to be confronting, that's all.

It's different. If it's introduced and executed, it works extremely well.

Yep.

I've introduced. In my household, with my children.

Okay. All right.

And it works because I teach the kids that. Here's a Kanban board, our weekend activities. They're open to suggest what weekend activities they want to do, and then we prioritize it. And then we have clear goals in the weekend of what activities we want to do. And then even their own daily routines. The first thing I work with them on is clarifying what their goals are, whether they're learning how to play piano, certain sports, and even trying to beat certain video games. And then once you identify those goals and prioritize it, then it's. It's allocating time and prioritizing that and then creating that. That daily list of even prioritizing their schedule so that they can work towards achieving those goals on a regular basis.

Right, right. So, you know, in a way, having talked about that and with your family, it sounds like that this is more of a. What do you say, a way of working or it's a kind of a life skill. In other words, this is something that is bigger than M and A in itself. It's something that you could apply, really, to the way you live your own life.

It is. And it's. I bring that example up, Toby, because it fundamentally works. And I think part of what you mentioned with accountability is even with my three kids, and they're young, they're four, six, and nine, it's creating this level of transparency where they can see each other's goals and they see how they're spending their time, and it creates this contribution where they want to be part of that. They want to be part of that momentum, and they want to be able to contribute their ideas and effort to it. And it's worked extremely well versus the traditional. Have these things in silos where you're not going to get that level of energy and that feeling of collaboration that's really going to encourage and motivate you.

Yeah. But, you know, it's interesting as you speak, though, Kirsten. I think it comes down to we haven't mentioned this, not too much yet. We talked about mindset, we talked about culture. But ultimately, isn't this a leadership thing?

I agree. It's definitely a leadership because somebody has to introduce it and somebody has to be the driver of making transformation. If there's an old way of doing things and we're Working towards a new way of doing things.

Yeah, no, it's interesting. I mean, because I think when we talk about leadership, there's a certain amount of boldness or courage needed to say. Because really what you're saying here, Kisan and Ina, is that, look, I know we're doing things in the past, we've done it this particular way, we're going to do it differently. And this is where we're going to do it. And we're going to do it for this particular deal, for these particular reasons. So you're going to introduce or this person say, no, we're going to shake things up a bit. We're going to follow a different way of doing things. This is how we're going to meet this way, we're going to run things. And there's a number of things and all this is explained in the book. I understand that. But still it comes back down to that individual. And I think it's just one person. I don't know who this person is. Maybe it's the CEO or it could be maybe the Chief Operating Officer or the cio. They will say we're going to run things differently and they're putting themselves on the line to say this is the way we're going to work. Guys, I believe this is it. That takes courage.

It does.

Especially if it's a big deal. We might be talking multimillion, maybe a few billion dollar deal. This is big. You can't screw this up.

It's that mindset to keep trying different things, accept failures and keep trying different things until you find something that works better. Better. That leadership has to be there to be able to drive this change, to get that change to expand is really being able to answer the why change? And that comes from leadership to be able to drive it. So somebody has to take ownership of it. And it can't be something that's forced, it's got to be something that's volunteered where that leadership is naturally driven to be able to take ownership all of this change and drive it through that approach of focusing in and really making the clarity on why the change needs to happen and making sure things get facilitated. And what needs to be done is done and what people need is there.

So Kirstan, let me just sort of slightly different question now, but look, there are M and A deals being made around the world, thousands and thousands of deals every year. Now would you say that you would apply this potential agile M and A page could apply to all circumstances or do you think there are situations where Perhaps. No, no, no, no, don't follow this. This wouldn't work for you guys. Are there circumstances where there are deals out there that this, the Agile MNA approach would not work?

It's a good question. So if we broke a deal down into the many small projects that are involved and if we looked at it on a very basic level, a project where you can clearly define the steps that need to be done and there's a very minimal chance of variances happening in those steps to complete the project probably isn't the ideal fit for Agile because Agile is designed to be responsive around changes. And that's where the traditional project management approach would work. Well, that's very plan driven. Plan things up front and execute it.

Okay.

And where Agile makes sense is there's variables in the steps such as when we pursue M and A, we have little information upfront. As we continue to get new information, we identify new risk and opportunities. That that's when we see this good value of using Agile. And what I end up going back to is that I think leading with Agile has a greater benefit because even if a project within Agile is better fitted for a traditional approach, it doesn't do much harm to have that Agile approach from the beginning because then you could still plan things out and execute it in that traditional way, just without fluctuating the variables as much as. So there's still, I think, benefit of just overall having that mindset and approach of Agile, but then letting that oversee and drive, but then still applying a traditional approach where needed.

Okay, so if I summarize what you just said there, Keystone, it's more like saying, well, yes, Agile will work better in some circumstances where there is, say for example, a high degree of uncertainty in a deal in terms of where it's going to go or what, what value it might deliver, then it's Agile works better, probably less so where you're certain. In other words, as a traditional type deal, maybe it's just simply saving some costs or you're in the same industry, you've done these deals plenty of times before, so this is nothing new. So perhaps Agile is probably not so applicable. But what you're saying overall is hey guys, just give it a go, just try it. Just try some of the practices that you mentioned in your book and just say, hey look, you're not going to lose much, but everything to gain, just try it out. Is that your message?

I would prefix that with clearly identifying what the challenges are in your process. And then from there I think that's where you can really see if there's a fit because you can look at various techniques. For example, in the book I outline the model of creating a game plan and encouraging companies to create a game plan. Because time after time I see companies getting overly fixated on Playbooks, which Playbooks are great. They're the long checklist that take an approach or attempt at templating the process. But the reality is we can't template the whole M and A process. Every deal is unique and there's a lot of variables that are unique to each deal. But it's a good starting point to know what are some general things to look for. But when we look beyond that, what I see a lack of is a operating framework that's documented that really spells out how teams are organized, how they communicate with each other, conduct meetings, share information and manage their dependencies and really, really have that laid out so that we can define that as a project management methodology. The idea was encouraging companies to create a game plan and utilizing the framework Agile M and A as a starting point. And within a game plan are these individual plays, which are techniques that represent a way to create efficiency or overcome a specific challenge. And it's designed to be very flexible because you can tailor a series or variety of plays specific to the company and your needs, whether you're a small team working on small deals, a larger company with a large team and have that configuration. So then that's the idea of being able to develop that level of efficiency is encouraging companies to have the operating model because I see big lack of it and I think that's what's really missing.

Let me summarize. Agile M and a focus on the game plan. Get that working focus less on Playbooks with checklists. Is that if I just summarize that. Okay, or have I wrong?

Like I said, if your company doesn't have a documented operating framework, I think that's where a lot of this challenges come from.

Okay, so you're anti Playbook.

I'm not anti playbook. I think it like we get overly fixated that we use a playbook continuously throughout the process where it may be a good.

Like a crutch of some sort of.

Exactly. And it's a good starting point. But the reality there's more value that can be achieved from a game plan that helps align your teams and creates a collaborative environment because that's where you can get that very agile process that'll add the most value when things really get tough. And there's a lot of variables in the deal coming at you.

Okay. And so the book is very much around how you develop those game plans.

Yes. It introduces a basic framework that companies can use to evolve into their methodology.

Okay, all right, that sounds good. Now, key sign just to, you know, look, I've asked you a lot of questions. We've gone through leadership mindset, culture. But just another final thing, we've got a book out. It's out there. I see it's getting a lot of good reviews out there on Amazon, which is good to see in the end. What are your dreams? What are your hopes that maybe a year from now or two years from now, what are your dreams and hopes around the whole notion of Agile and M and A?

I think the industry has tons of opportunities to improve and become more efficient. We're in 2020 now, and there's still companies that are using Excel as the driver of their process.

Right.

And the goal, Toby, is to motivate people to try new techniques, keep trying new things, and develop that mindset of continuously improving their process.

Yes. Okay. Would you say. It's interesting to say that because I mentioned it to you before, but would you agree with me that M and A is a pretty conservative industry?

It's very conservative overall. Very conservative. I think that's why we're behind. We've seen a lot of other industries that adopt Agile from the software world and apply it to business cases, but we've seen that marketing, education, government. But our industry, M and A is behind.

Yeah, I get you, I get you. But let me. But one thing that I'm slightly puzzled about is that when you talk about M and A, it's a very broad process or discipline. We talk about how you might develop a strategy, how you might search for potential matches. There's obviously the negotiation, there's due diligence, there's the legal side and the financing side, there's the closing side. And then finally we get onto what you do after a deal, which the integration type, work to bring the two businesses together. So when we talk about Agile, M and A, are we talking about the entire process or just one particular part?

It impacts the entire process and it's best introduced early, earlier in the process, the better during those kickoff meetings. And even if it's just applying one technique or multiple techniques, but the earlier you introduce, it would ensure that continuity between the different stages, especially when you move from diligence to integration, where often we see that knowledge chasm. So I think there's a tremendous amount of value of bringing it in early so that it creates the greatest impact throughout the stages.

Okay, Kingston, let's just picture this. I got another question for you. Look, I'm a CEO. We're an organization. I'm in charge of an organization that wants to grow and prosper. And we're going to use M and A to effectively bring in some new capabilities into the organization. Now we're about to embark upon what could be a very big deal, maybe like a billion dollar deal. We want to do this right. We want to basically get the value that we believe in this potential acquisition. We want to extract it to the full. Convince me why would I want to follow this approach compared to what my corporate development people say we should follow? Why should I follow what you're saying versus what my internal team is saying?

There's a lot at stake when you're doing a deal that big and everybody knows that they're not easy to do. There's a lot involved and particularly what matters the most is after the deal's announced and everybody's involved and there's a lot of chaos that ends up happening traditionally on these deals. And this is where there's an opportunity to deploy a new, modern approach to managing these large, complex transactions so that the process can be much smoother, resulting in more value creation and achieving those original goals with happy people at the end.

Okay, happy people. No, no, no. I can understand. And happiness is the big thing. We don't want people having lost opportunities or feel that perhaps the deal that they working on or they've done has not produced the results they wanted. Kirstan, look, I think it's great. We've had a lot of questions. I think hopefully the audience understands a lot more about agile, M and A, about the book. Are there any final parting messages before we finish up?

I think it's an opportunity to try something different. If you're a company and you've dealt with any particular challenges in your process, isolate them, get others involved, really understand who are the key people involved in your process and get their voice out there and what the challenges and problems are, because a lot of times we suppress them and they just continue to mound. So identify those challenges and open up if you get a chance. Look into the content we created and some of the plays to see if they could be some value add to help you overcome those challenges. Keep your team collaborating and focused on delivering value throughout your transaction keystone.

Thanks very much. Look, I know I asked quite a few questions, but I do fundamentally believe that the book and what you're doing is bringing M and a into the 21st century. It is an industry that does need to be shaken up. I think there's a lot of disruption occurring out there. People need to change what they do. Not just basically the acquisitions and how they grow, but also the very process they follow when they are doing deals. So it's good talking to you. I think it's very interesting. A lot of people should sit up and take notice and take a look at see what you said in the book and every success because I think things do need shaking up. So thank you very much.

Thanks Toby.

Thank you for taking the time to explore the world of MA 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 n@dealroom.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.