How to Evolve Your M&A Workflow Using Agile Principles

Hello M and A Friends. This podcast is brought to you by dealdoo. M&A is coming back. Would you like to avoid wasting hundreds of hours managing Excel Trackers and building PowerPoint reports? Do you want to make your process more efficient? Well, I have great news for you. Deal Room is MNA management software to save you time headaches and improves collaboration so you realize value faster. Learn more@dealroom.net here's to the deal. Hello M and A Friends. Our holiday summit is coming up on December 9th and 10th.

Join us in learning and sharing the cheer with speakers from AstraZeneca, Microsoft, Cisco and many others.

Visit our really cool website to learn more@mascience.com register today and join the party.

Nice job. So are you really gonna host this conference yourself?

Yeah, of course. Why wouldn't I?

Well, what am I gonna do?

You can make some eggnog.

I like that idea. I'm Kisan Patel and you're listening to M and A Science, where we talk with deal professionals and learn valuable lessons from their experience. This podcast focuses on stories, strategies and what actually happened during M and A deals. Welcome to M and A Science. Putting together companies is complicated and taking them apart is even more complicated. We take lessons from real practitioners and enable them through education and technology. In this podcast series, we interview leading M and A practitioners to learn lessons from their experience. Learning proven techniques is key to optimizing your M and A practice. If you're interested in learning more, connect with us at our networking events and access our educational resources at mascience. Com. I'm your host, Kisan Patel, CEO and founder of Deal Room. Today I'm here with Gina Sandin, Director of Corporate development, Mergers and Acquisitions, synergy and integration at IBM. Gina's been at IBM for over 10 years. Today we're going to discuss how to evolve your M and A workflow using Agile principles. If you wouldn't mind kicking off with a brief description of your role and experience at IBM.

Sure, happy to do that. Thanks to everyone who's listening. Hopefully you'll be able to take away a couple nuggets from my experience and the IBM team's experience in M and A. I came to IBM through acquisition of a company called Initiate Systems, Chicago based. Right there with Khsan. Have been at IBM, as you said, a little over 10 years. My career in IBM has been a winding and interesting career from leading a industry marketing function globally to working on a very large client team. So client facing and then moving into a couple of entrepreneurial pilot kickoff programs. In the IBM company where we tested some new adventures and transformation and then working in M and A. And I found my way back to M and A because of my passion for the acquired employee experience and the opportunity to help other acquired teams come into IBM, have a great experience and energize increase IBM's growth and market presence. I have a passion for the people and I hopefully will share some of that with you as we talk through today.

I always find that interesting how practitioners latch on to the integration process because even I've met corporate development leaders that end up focusing more on integration. I'm curious, what is it about integration that really draws you in?

Well, let me start off and we'll talk about this a little bit more. But we actually are moving away from the term integration. Integration has this connotation of doing it to you, not doing it with you. What we've found over the years is that when you bring a acquisition into IBM, you really want to embrace all that's unique and special about that acquisition and co create with that acquisition's leadership and team members the potential bring to bear the greatest value creation you can. And integration. Doing it to them is not probably the right approach. It's embracing that co creation, doing it with them. So we've moved to the term implementation, implementation of the business as usual state. We are trying to achieve and doing it together with that acquired team.

Right. And 10 years at IBM. How has IBM evolved since you started?

IBM's been on a transformational journey both from a market perspective and our focus around hybrid, multi cloud and data and AI which is what we are uniquely bringing to the market today. So our focus has transformed, but also our internal organizations have transformed and have moved from hierarchical type approaches to things checklist driven, lots of individual silos to a much more forward thinking approach on how do we become business outcome oriented, add agility, agile transformation into our ways of working across the entire business. What's been interesting is different areas of the IBM company have moved at different paces on this agile transformation journey. I feel very fortunate to be in our finance and operations organization under the leadership of Jim Cavanaugh and he's really embraced, promoted and enabled individuals and teams to develop transforming our workflows and the way that we operate in agile ways. So it's been a great experience and we've taken that to the next level in corporate development to try to leverage the transformation in finance and operations into our corporate development approaches as well. So it's change, it's ongoing, it's iterative, all Strong concepts of Agile and agile ways of working and we continue that journey every single day.

That nicely frames me to ask you how have you seen Agile principles improve workflow and the integration process of IBM's acquisitions?

We embarked probably a little over a year and a half ago on something we called Acquisition Agile Accelerate. It really was to take our thinking from checklist driven implementations to something that was more flexible, that enabled us to move more quickly, that enabled us to innovate along the way. So I just shared this overview with you. We start with what probably all corporate development and M and A team start with the strategy around the portfolios that they're looking at and how do they build inorganic growth into that and then moving to the alignment and on to deal enablement and transition to operate. Really what we focused our acquisition Agile Accelerate work on is in this deal enablement and transition to operate phase we really looked hard at how are we going to think about the deal rationale, think about it in a different way, how are we going to develop due diligence in a approach that both gives flexibility but also gets to the business value quickly? How are we going to then do the discovery of what it takes to establish an acquired organization into IBM's operating models and business as usual structures. And each of these things are reliant on understanding what the post close operating model might be. Is it a tuck in? Is it a hybrid model? Is it a standalone business? Potentially. Are there spinoffs and divestitures across this as well that we might look at? So this is the high level picture of what we focused on for Agile Accelerate and we unpacked each of these areas and built sub workflows to go through. How do we work together? How do we bring teams and individuals functions into each of these stages in a way that really minimizes the resource use or the resource required to. When we're completely focused on what is the business outcome for that iteration. We then looked at it in three areas of critical importance. The offerings as you bring in an acquisition, the go to market so building synergies and the operating model and then we built the implementation plan according to that. Now there was a lot of debate internally on when do you start building the implementation plan. And it really does start early. It starts early with a smaller team. It then adds subject matter experts across the workflow as you see here and ultimately builds to how do you get to a operational state? I would call out just a little bit here the operational states. And some of this we learned on the Red Hat acquisition which was acquired and put in as a standalone business. The first and foremost thing is to stabilize the business after close and make sure that we do no harm. And I think all of you probably have that same approach. Then we look for efficiencies. That doesn't mean reductions in force, that doesn't mean looking at how do we reduce redundancies necessarily. It means things like how do we get procurement activities to the benefit of the acquired organization, how do we get things like travel policies with the large scale that we have in IBM, how do we get that benefit for this standalone unit or this business that we've acquired? And then finally we look at how do we optimize the interactions and workflows. All focused on value creation, all focused on the business case and meeting the business case. This is the core idea behind what we started to develop in Agile Accelerate.

So this is really interesting because it sounds like it's very dynamic that you're tailoring it to the company you're acquiring. One thing that may be helpful, Gina, is if you could contrast the traditional approach with this Agile Accelerate model just to maybe give somebody that is absorbing this right now to get a sense of how it would be different to their current operating model.

Let me try to give a real life example using Initiate Systems as the acquisition, because I still remember being on that team of disclosed individuals as we were selling the company to IBM and the day the letter of intent was sent, signed, landed on my desk, 1600 due diligence questions. Those 1600 for a smaller company was quite daunting because you have to keep your business running while you go through that process. We then proceeded through that process of 1600 questions and returning them in what seemed to me at the time an unreasonable expectation of when we could populate the data room. And today, if you think about just that piece we have looked at, how do you focus the diligence activities on truly the things that matter? And all of those 1600 questions are important, certainly especially when you get to implementation planning. You really do have to understand the nuances, understand the very detailed levels of things. But in the due diligence process, maybe there are only three questions that really matter. The first one is probably should we do this deal? Should we do this deal? And what do we need to know to do this deal? The second one, can we do this deal? Are there any obstacles or barriers to getting this deal done and getting it to close? And then finally you get to how would we do this deal? What are the things that we're going to need to do to realize the value creation or the business case in order to make it the right decision for the IBM company for any company. So I would encourage all of you to think about it in that way. Should we do this deal first and separate that out into can we do this deal and then how do we do this deal and how do we do it to assure success and achievement of the business case?

How did you come up with this?

Well, I will tell you a full disclosure to the folks listening. This is not my creation. This is working in a co creative way across many, many different teams in IBM to think this through. It starts with our business unit leaders who are thinking about how do they grow their businesses and the business development teams that are looking at what areas do we want to enhance IBM's capability through inorganic growth strategies all the way through to the functional areas that have to make compliance and tax and treasury and accounting and finance and channel ecosystem and customer support and all of those functions that have to be successful. We called on all of those different areas of the business to get feedback and input. There were a lot of brilliant minds that came together to think about this and frankly a lot of lessons learned. IBM has been doing acquisitions for a very long time. We at one point had 15 or 16 going on at the same time. We learned a lot, we may have done a lot of things really well. There was certainly a lot of room for improvement. We actually did some pretty significant data analysis on those prior acquisitions through a couple of focused projects and came up with this. So it's a body of work that was a long time coming to move from a checklist driven set of activities that really focuses on tasks instead of focuses on the business outcome. That really spurred us to push our thinking.

What was the why that was really driving to make this kind of change? Were there enough deals that blew up? That's like, hey, let's build some initiative to change this.

That's a great question. Probably a combination of things coming together, pushing from our executive leadership all the way up to the CEO and CFO level of how do we continue to innovate in IBM and innovate for growth that pushed us to think in new and different ways. Ginny Rametti and now Arvind Krishna certainly continue to push that mindset to us. I think it wasn't deals that blew up, it was also resources. How do you best take advantage and the skills and resources that you put in a scalable model because there are different timing things. I'll also say that Red Hat, when you do a $34 billion acquisition and you have to think about it at that level and scale. It really forced some new and different thinking. How are we going to set this up as a standalone business with independence and neutrality in the market? Because of the way that the market is and the way that we needed to bring forward both IBM and Red Hat and you know, it pushed our thinking and that spurred us to develop this. Now I think it's a journey that we're still on. We're finding new in different ways. In the last couple weeks we've announced two new acquisitions and we're continuing to push toward this agile way of working. It's certainly not perfect and I wouldn't, I think you could talk to anyone in IBM, in our teams that would say this isn't perfect. We've still got room to iterate, improve, look at different ways of doing things. But we believe that this gives us a more flexible approach to acquisitions and also a more innovative approach to acquisitions.

Very nice. I'm curious to get into the little bit of the how. I know I got a good explanation of the model, but how does it actually come in play in the real world going from when you have the deal rationale you're developing, are some of those steps still the same where you're developing your valuation model and you're pulling in assumptions from various resources that are going to be involved with implementation phase of the deal, how does that end up moving through the stages of the deal? And I know you mentioned you're taking a more dynamic approach in who you get involved. How does that end up happening as well?

We have put a significant focus on the deal rationale and thinking through the deal rationale in a number of different ways. We have implemented, if you will, a new role that is an engagement manager role to really tie together the investment thesis, the value drivers, the risks and activities, the business case modeling, looking at go to market route to market capabilities and offerings, and then tying that all together in a deal thesis that helps all the members of the team that need to come in at various elements look at this and say, okay, here's what we're trying to achieve. Here's where we think we need to focus our energies. The questions, if you will, then we start to look at each deal like that and we pull in the resources, the skills, the experience sets. If we think there are particular tax risks, they might be first to the table. If we think there are particular go to market challenges, we bring seasoned experts to the table for go to market. We partner and Design each deal and this engagement manager, along with the business development leader come together with a transaction specialist, so the negotiator, if you will. And we have what we call a core deal team. And that core deal team is really made up of a handful of people. They work together to identify squads of people underneath them with the right kind of subject matter expertise that we need to take forward two of the roles that we newly defined. So we newly defined this engagement manager. We've always had a project manager. I'm sure that everyone has had a project manager. But this engagement manager is really to look across the strategic pieces of it. We also have added into this early stage a go to market leader from the M and a team with go to market experience in acquisitions. And we've added an offering technology leader to that core deal team. They will then identify the resources that are needed with the specialized subject matter expertise to bring forward that deal and take it through the process. That doesn't mean that those are the only people involved by any means, but they help drive the strategy with the business unit in support of the deal thesis.

That's so interesting because you're bringing this core team that's cross functional really early in the process, so they can probably start iterating on plans and what they're going to do when it comes to the implementation part of the deal. The engagement manager is interesting too because you're now having a specific role that's focused on the goals and making sure that's articulated. But it sounds like they're the ones responsible for thinking about the people that need to get involved and really steering away from basically a cookie cutter approach where you're supplying things off a list like you typically would. It sounds like that person is more of, okay, based on these goals that we're trying to achieve, we should bring these particular people in this order. Does that sound right?

That does sound right. There's a lot of other things they do and they certainly bring a wealth of expertise because then you bring in to this core deal team what we used to call an integration executive. These would be the people that would own the success of the business case. They come into the core deal team as it moves through the deal process and then as it gets to final approval and you have to start to look at what is the operating model. Now all of a sudden you start to bring in functional expertise around the operating model and then as you define the to be state more thoroughly, then you start to understand, okay, what does the implementation plan actually look like? And one thing I'd call out is in this new way of thinking and working, what we are calling discovery is taking, let's say in due diligence. Maybe you only answer 400 or the 1600 questions and you get to final approval because you've answered the should we do this deal? Can we do this deal? Now you get to how will we do this deal? That's discovery. Then we have to start really going underneath the covers, understanding the rest of those questions in a thoughtful approach where we don't dump it on a target team all in one shot, but we do it in a way that is digestible, in a way that continues to be iterative and in a way that develops a go to market route to market plan that can meet the business case. So the discovery phase is frankly new to us because we previously did it with the 1600 due diligence questions. We're continuing to evolve how we do that. So I wouldn't say we have it all stitched together, but I will say we have a couple of good examples and we have some strong lessons learned and outcomes from the couple of examples where we really deployed this fully and are making progress on deals in the pipeline that we're applying this approach to it. So talk to me in a year from now when we have a bit more data to be able to say here's what worked, here's what didn't. So far we believe this more agile approach reduces the number of resources called upon up front until you get to that point where you really know how are we going to do this deal? Then you bring more resources to bear and then more resources as the implementation planning goes further and you hit the stabilization, efficiency and optimization phases.

What happens to the Playbooks in this new model?

The Playbooks are iterative in nature as well. They're not static documents. We do have an internal tool or an external tool that is used to manage audit trails and the project itself from a compliance perspective. But we've also tuned that tool to be able to do it in a more agile approach with iterative milestones that are business outcome focused.

It's really interesting to switch things up and given the current environment where everything's gone virtual, how does that impact how you do things?

It's clearly impacted a lot of things. We like many companies out there and we've probably all been watching the deals that are going through during this Covid environment, most of which are probably all working in virtual due diligence environments, virtual valuation environments, et cetera. I think if someone would have said In January, before we all knew what this year would look like, that we were going to do all our due diligence activity and all our implementation activity virtually, we probably collectively would have said, ah, I don't think that's possible, that'll never work. We have found that it can work and it does work. And in fact, from a capacity perspective, and I just mean moving multiple transactions through a process, it sure saves one heck of a lot of time. When people aren't flying all over the place, spending hours of multiple days of the week on airplanes and in transit, you can actually get a lot more work done now. There are downsides to it for sure. Downsides like building those interpersonal relationships with executive leadership, building the dynamic, the working dynamic, the ways of working culturally. How do we engage with individuals and teams across different time zones, across different cultural barriers and norms. You can't make up for that interpersonal dynamic that you get in a face to face environment where you're building the camaraderie, the momentum, the enthusiasm together for a deal and for the implementation. We have done a lot of things, tried new ways of engaging using mural and other web based tools rather than just straight Zoom WebEx teams, whatever the tool of your choice is. So we are trying to build in those types of collaboration environments and add some things to the sessions. I wouldn't say it's perfect, but all of us are learning to work in that new and different virtual way.

You're absolutely right. I think it's a big change for everybody and it's interesting how it's prompting you to take that initiative to even drive more change by trying these new tools and approaches. Wanted to switch it up a little bit and get more into it. Driving change particularly interesting, especially in a larger organization where the stereotype is the glacier. Speed of change. I'm curious to hear about how's the implementation and adoption of new practices been received.

So let me start at the individual level. I started on my own agile journey probably 15 years ago. I was almost by force the development executive in Initiate Systems was driving to change initiates development from waterfall development to iterative releases that we all are becoming familiar with that happen over and over and over again in my world. As a marketing executive I was used to two releases a year. I could plan a launch around each of those releases, I could plan a sales enablement session around each of those releases and a whole bunch of other things, promotional events, the whole nine yards. Suddenly I was faced with as a marketing leader, constant iterations and releases of new features. New functionality, new capabilities. So I went to this executive and his name was Dave and I said, Dave, you got to help me here. You keep sending me. We got this new feature, we got this new functionality. How am I going to bring that to market? I can't every two weeks have a launch, it doesn't work. He gave me this book and it was the Agile Manifesto. And he said, go read this. I said, really? And so I did. And I started to think about that in terms of, okay, well how would you actually twist a marketing function that is really focused on twice a year launches in all aspects to something that could be more dynamic and more engaging and ongoing? And I challenged the team to begin to think about it that way. And did we do it perfectly? And did we institute scrums and stand ups and iterations and showcases and retrospectives? No, we did not. We tried. We waited our way into it as a marketing function to try to match our engineering organization. Fast forward 15 years, I've continued to study that and got lucky in IBM because we hired a tremendous marketing leader, Michelle Peluso, who also believed in this approach in this new way and she drove change in the marketing function in IBM over the last several years. And other parts of IBM started to develop that, including the finance and operations organization. So it's been a huge transformation for IBM. Now, specific to your question, as individuals, everybody's on their own journey. Everybody is able to absorb, adapt, adopt and think about Agile and how it might apply to their way of working in a new and different way and at a certain rate and pace that they're comfortable with. One of the interesting phenomenons that we've been working through over the last probably 18 months is that just because corporate development is moving towards these agile ways of working and these new workflows that enable that, these new team structures, squads with iterations, daily standups, retrospective showcases, doesn't mean our peers around the company are all where we are and in fact some of them are far ahead. CIO for an example. Those teams have been working this way for a lot longer than corporate development. So we're all at a different stage. I think methodology wise, we all believe and we all think this is going to benefit our business, no question. But it is a interesting dynamic when one team is used to running daily standups with cross functional, not who do they report to, but cross functional diverse expertise in their squad and another team is still silo oriented. I got my checklist, I got my team members, I go up, then I go over, then I go down it's been an interesting adventure and we continue to work through that. But individuals have their own rate and pace, teams have their own rate and pace of understanding adoption. And I've observed, I wish I could put data to this, but one of the things I anecdotally observed across many different teams that are trying to go this direction is that first project that you try to implement, this new way of working on it goes like this, Jagged. Yep. We think agile, then we slide back, then we go forward, then we slide back, then we go forward. And you have to just be willing to have that happen. You have to open your mind and have that. The other thing that we've done, and I think this is reasonably standard practice across many companies, is we put in these roles agile coaches. So as we're going through these jagged fits and starts to really change the way that we're working, these agile coaches come to our rescue. And sometimes they're psychologists, psychoanalysts and they help the team figure out how to get through a particularly rough patch. And sometimes they just say, you gotta just set that aside. This, this is the way we're going to do it. So come on, get on board. These agile coaches have made a real difference. We pulled on them from other parts of the IBM business. A lot of them have very strong design thinking backgrounds and have taught a number of us how to think using design thinking practices which facilitate agile ways of working. It's a journey. I can't say that enough. It's a journey and I too continue on it because I have personally implemented Trello as my agile tool of choice. And so I run an individual Trello board that has my working activities, my cards, my completions, my own retrospectives, my own pieces of work that I'm responsible for and accountable to the business that has helped me both institutionalize for me and for my teams, how to work in a new and different way.

That's really cool. And I remember managing a team on Trello for about two and a half years. So it's definitely a fun and enjoy the simplicity of the product. It sounds like when you mentioned too the jagged in terms of the evolution, it sounds a lot of that's experiments that you are trying different things and really seeing what works, what sticks and what doesn't. Does that sound right?

Yeah, I would say that there is experimentation, try it, fail fast and move on. I would say that's absolutely true. That's not to say that everything is an experiment because we have a ton of experience and so we have some very Tried and true things that we know. If you do this, this is the result. And yet as the market changes, as the business dynamic changes, as things like global pandemics hit, you have to be able to build that in and experiment how you're going to do things differently to adjust for those dynamics.

Have you seen age make an influence in terms of adoption rate to new practices and technology?

I don't think I would call it age and in fact I think I would label it mindset. The individuals that have the most success are those that have a natural intellectual curiosity, that have established in their own Persona a growth mindset, a continuous learner mindset. Those are the individuals that have the highest propensity to look at this, think about it, internalize it, understand it, and start to see how it can really benefit them, their work and their contribution, frankly, to the business area that they're in. And that is a statement that is probably much broader than corporate development and M and A. That's a statement in general. So I don't think it's an age and I have great examples in my team. It's a mindset I remember.

Are there other traits that are required to adopt agile practices?

I think open mindedness is probably one which may be closely related to continuous learner. It is hard to adopt agile practices if something that worked for you 15 years ago is what you're still relying on. The dynamic nature of this business is so different today than it was 15 years ago. Just a personal pet peeve of mine and my team would tell you this is the first person that says to me, that's not my job, that's a pet peeve of mine. It's all of our job to make sure that we're contributing every day to our company's innovation, growth and the initiatives our leadership has set out for us. I look at that and when I start to hear or even sense that people are pushing back, I got my checklist and this is what I'm going to do. And it's in this box I start to try to coach and develop and bring out the benefits of thinking potentially outside of that box for individuals and teams. And that's part of agile transformation too. There's a lot of specialists in IBM that focus on that change management. I've been fortunate enough to work with some of those really talented change management people. I would highly recommend for those people listening to this. If you haven't engaged change management specialists as part of your M and A, both process and transformation, they are critical to the success of that is there.

Anything particular they do that just works really well?

Those teams really demonstrate an incredible amount of empathy from the lens at which each individual or function comes at a particular issue, problem situation. They have the ability to bring out that lens, synthesize it and bring people along on a timeline or on a thought process in a way that doesn't shut people down. That's a really important piece because people will jump in, they'll buy in, they'll engage if you can bring them along, what's in it for them? What's in it for their annual review, what's in it for their accomplishments, what's in it for their career, all of those kinds of things. People have to really see it from their lens. And why does this improve their ability to contribute their piece to what we all know is a very complex workflow with a lot of dynamic things going on. And every function has a role to play, every function has a piece to contribute to the success of achieving that business Case there is no one. If sales blows out the number, but the back end's falling apart, can't do it, it's not going to be successful. So those change management folks really help. The co creation with an acquired team, the implementation team, bringing that together, helping to bring everybody along a path on a particular project or a particular deal and they make a huge difference. Employee engagement, regardless of whether you're an IBMer, an acquired IBMer, a target, those engagements principles, frankly they don't change. We all are humans in the end.

I like that when you mentioned empathy. I think that ultimately is the most powerful skill when it comes to driving change. It reminds me of working with a client. I published a book doing research about agile and seeing it as a trend, but didn't foresee that I was going to be asked to help organizations or share some ideas around how they can actually drive the change. So that was a whole learning curve and the one thing I found that emergency. We're just curious on your thoughts around this that actually worked the best was I didn't know what I was doing so I came in and would do a lot of discovery interviews. So let's map out the process and understand who the key people are involved. And I would do these similar type of interviews, like these podcast interviews, but really focused on what are the pain points and challenges. And I did this with a company where I ended up bringing all those Personas together and just had a whole list of everything I gathered of the pain points and challenges and just letting them have an open conversation around it and my proposition was to have them prioritize those pain points and challenges. I just, hey, this is what it is. Probably typical of any type of consultant approach, but just watching the interactions and I felt like that was that level up moment where people really started understanding what are the challenges that the different roles are facing. And that's what prompted more of that. Yeah, let's try something different. So let's go ahead and try this different approach and see how it works.

I think as we started on this journey and we did a lot of those, I won't call them brainstorming because they really were design thinking facilitated sessions starting around the user and the user experience and what we needed the user to be able to do in each of the different Personas that we identified as critical. Some of it was Personas across the business development, corporate development, shared services community. Some of it was across the acquired company and what would their experiences be as the user. But there were a lot of realizations and I personally had many by the way, through that process I lacked appreciation of certain areas, the criticality, whether it was compliance or audit or tax or treasury, because my personal lens was how do we drive growth, Sales, marketing channel, ecosystem, those kinds of external facing measures and objectives. It was a great experience for me. Maybe I didn't build enough empathy, but it certainly built a much better appreciation for and understanding of those areas. I think that for teams that might be thinking about how did they transform to a different way of working, this is a great starting point that you've just brought up. It's a great way to get a started and broaden the understanding across an organization from the different lenses of the critical stakeholders and functions involved in this very complex workflow.

Yeah, I agree. Because ultimately it leaves you with this compelling reason to change, where you really have that to anchor in and drive everyone and rally them around. We're going to solve these imminent issues and at least having that understanding or common goal. I need some advice. Give me some lessons learned, some advice that other practitioners would benefit to their own M and A practice.

I would say first of all, read Kasan's book. I did that and found a tremendous amount of thoughtfulness in there. What was interesting is much of it I had been thinking about. I shared this with him in one of our prior conversations. I said this is all the stuff I'd been thinking about four months before that. I needed the book before it actually launched because I was like, oh, this is the recipe, this is great. Start with that. Ground yourself in some design thinking. Understanding. Use that to help facilitate the conversations in your organizations to get to how might you move toward this? And then just keep iterating, keep the momentum of the transformation, use the showcases, leverage retrospectives to document the lessons learned and drive the improvements in the next sprint, the next project, the next piece of work that you're going to undertake. You should not skip the retrospectives. And sometimes it seems like you can just race past that onto the next thing because we're all so busy. But there is such value in doing those documenting those sharing it broadly. I'll finish with this. Develop a culture of transparency. We all work in a space that is highly confidential in many ways, non disclosure agreements, limited access to people on very especially for publicly traded companies, very highly guarded growth initiatives. And you really need to build trust and transparency in those core teams. You need to think about how you manage the information flow in a way that is transparent but still protects the disclosure requirements. But the more that you can enable the teams that are currently disclosed in a very transparent way, using collaboration tools, using Box and Slack and teams and all those kinds of tools, it makes it so much easier because when someone new comes into the team, into the squad, starts running the sprint, if all of that information is already set up in a transparent way, they can go through it quickly. If you have to rely on our old standby of sending in volumes of information via email, wow. You're never going to be able to move as fast as you want to. So start to think about how you build that transparency in early with the right permissions and controls around it of course, but enable it to think further down the road because you're going to have to onboard subject matter experts, skills and talent along the implementation plan. If you start up front and you organize it in such a way and you build the permissions and the role based rules around that transparency, growing that to a wider and broader group fast can really help you move in a way that improves performance.

That's awesome. Those are great takeaways. From design thinking to retrospectives transparency. Reading my book, These are all great. I just got one last question. What's the craziest thing you've seen in M and A?

I got to just tell you, the craziest thing that I see in M and A right now today are the valuations of companies. Given the environment, given the economy, given where we're at, that is the craziest thing that I see today in M and A. What's the craziest thing over working in M and A?

You can say it. Just don't name names and dates. You'll be fine.

The car that a founder buys on the day that you do a deal, that's the craziest.

Oh, I like that. That sounds like me, that what's the craziest car you've seen purchased on that.

Day of closing upwards of the Bentley Investment. One founder I saw by on the day of a deal and I use the term investment, I probably shouldn't, but those are pretty expensive cars and they've worked hard. But sometimes I think that might not send quite the right message.

That's true. That is pretty crazy. Gina, thank you so much for spending the time and giving me a walkthrough and and education today.

Well, I hope it's useful. I look forward to continuing to learn and share from this group. Thank you for doing what you do.

My pleasure. Thank you so much. And here's to the deal.

Here's to the deal. Bye.

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 n ealroom.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. Views and opinions expressed on M and A Science reflect only those individuals and do not reflect the views of any company or entity mentioned or affiliated with any individual. This podcast is purely educational and is not intended to serve as a basis for any investment or financial decisions.