An Agile Gorilla’s Approach to Mergers and Acquisitions

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 MA deals. Agile Gorilla, a boutique advisory firm founded by David and BEN in 2017, enables industry practitioners to conduct more successful, sustainable and equitable merger and acquisitions. David Boyd and Ben Haldivang have been managing, executing and advising on complex MA deals throughout the entire life cycle for decades. How's it going gentlemen?

Good, thanks very much Kisan. Very good. Hi there.

Glad to have both of you online. To start off, can you tell me a bit about your backgrounds and how you came to creating Agile Gorilla?

Sure, let me start and then David can jump in as well. I'll try not to go on for hours. I spent 10 years or so in the executive search world and it was very obvious to me that these deals were destroying value with the ease with which I was extracting important people out of organizations that were going through M and A. And there seemed to be a very obvious correlation between my ability to pull those people out and when I talked to them about why they were leaving, their answers were almost always not related to retention bonuses and organizational design, but a lot around culture and the ways of working and sort of behavioral issues within the business that had driven them to make that decision. So that's where my initial idea around building an M and A practice came from, with a sort of strong focus on the human capital side of things and a strong focus on the program management side of it, recognizing quite early on that the traditional methods weren't going to work. And we'll talk about Agile a bit later on. Agile Gorilla, I suppose for me is an attempt to disrupt and to think about M and A in a different way, to think of the sort of core unwritten rules that people have made about doing deals, particularly the post deal side of life, which we think are there to be challenged and questioned. And when we do that we find all sorts of interesting different avenues of trying to address the balance that is still pretty poor from the point of view of delivering success in the world of M and A. David, for me.

I fell into mergers and acquisitions a bit similar to Ben in starting as an engineer and really kind of integrating a business in France very early on and then 20 years later I found that that's been the focus throughout, has been integrating firms. Ben and I came together at a consulting firm, worked together for about four years and we both had that view as to the way things were Being done really wasn't adding the value for clients. It was a kind of process built on fear and a process that was thought 10, 20 years before that just wasn't really adding value and working for the clients. So when we got back together again a couple of years ago, we thought, now is the right time to have a new approach.

You're great. It definitely sounds like things align for both of you. I'd love to start and sort of preface this interview by asking you about the significance of Gorilla in your name. What made you choose this reference? How does it connect to the industry?

We had a moment together where we thought about what we were going to call ourselves and it was a bit of a sort of thought experiment exercise. It's one of those names that everyone reacts really well to and it certainly stands out. I think for me specifically, the Gorilla part of the name refers to the sort of innate irrational human in us all that tends to drive a lot of the behavior world of M and A. And so I'm attracted to it from that point of view because it takes us back to a sort of more fundamental part of the way that we behave and how that influences the way we go about M and A. Yeah.

And I'd add the Agile name in terms of when we kind of got together and said, this is what we're doing, this is how we do things and it's different. Agile really was one of the ways of describing to people how we approach things differently. Rather than go for planned strategies, we were using emergent learning strategies. A lot of the things that you now associate with Agile projects, management, agile software development were things that we found ourselves doing with clients on the M and A side. So really it helped us actually give a language to how we were approaching the delivery of the deal in a different way.

I love the branding. Can you tell me how are you rethinking M and A?

It's really turning everything on its head. I mean, it starts with us as consultants, so we're going in loving integrations because it's this opportunity where you are looking at the market strategy, the brand positioning, the sales approach, commercial policies, all the way through the operations and performance improvement and then the back end and the finances. You literally get a view of the whole business. And we'd ask ourselves, why on earth do we get as consultants to come in and work on all this exciting project with a company and then leave with the knowledge and great insights? Why aren't they giving these amazing projects and roles to the people in their organization? But if you want to design a kind of strategy for promoting and training and developing your internal talent. You couldn't get anything better than integration post M and A. So that was really the starting to say, okay, can you do it without us? Well, M and A integration is a skill. It is something different. It's not something that most people through their careers will pick up. So there is something to be learnt. But actually if we could give those people in the organization the skills and the coaching and the oversight that they need to be able to do it themselves, actually that would really change how they could get around the integration. So everything you could look at the focus of consultants is on cost, because that's what the consultants understand. It's very hard for consultants to come in and understand your marketing strategy, understand your clients, understand your pricing, and really help them in a meaningful way in a short period of time. So it focuses because you're using consultants, you end up focusing on the cost side rather than the revenue. You've got internal people. Actually, you can start focusing instead on the revenue growth from the start in terms of who you're working with. Consultants tend to work with the acquirer. They'll work on them, they understand them, they build relationships, which means that the target management are excluded from a lot of that decision making and those networks and actually the target management are the people in the organization who understand the clients, understand their growth strategy, and why not use them for the integration and get them to help understand how they can best fit in with the inquirer and then you start turning everything else on its head. So integrations are usually organized by function, hr, it, finance, front office. And the way you deliver value through the integration is always through opportunity. It's through the combination of each of those siloed functions working together to generate more revenue, to generate profit, to reduce cost. So organizing things by opportunity around the revenue. So we kind of put all of this together and said, yeah, this is the most coherent, completely opposite approach to how you deal with the post deal.

Great. So when you mentioned alternatively organizing your integration where it's typically by functions, but instead organizing it by opportunity, could you tell me a little bit more about that? How does that actually come in play?

In my 20 years of doing this, I've tended to find that the opportunities for growth sit between functions, not actually in functions. It's rare that finance or HR or tech, maybe it's a bit in tech, but most functions do their own job really well. But actually, when you start to look at things, growth opportunities, they sit between those functions. So it becomes a dependency management exercise of some, you know, horrific nature, which is down to the project managers try and coordinate and coalesce people to deal with things that don't naturally fit within their own space. But when you actually start to do something, project I'm working on currently is a good example of it where, which I know, and this will sound utterly ridiculous, but the reality is that for lots of businesses, putting product owners together with client owners is still quite a novel concept. When we started doing that in this environment, what we started to find was a much stronger feed between clients who had identified particular opportunities and needs and product managers who hadn't necessarily heard those before but were now starting to hear those. So the whole interaction between those two sets of people started to drive a very different sort of behavior. It started to look at some of the commercials behind the development of products. It started to look at the concept of partnering across clients to develop things. So not in isolation, but with the clients along that journey. And so not only was that a much more efficient way of operating internally, people started doing things much more more quickly, but they also started producing things that clients actually identified early on that they wanted. Sounds like a really obvious example, but that was a sort of slightly fatter work stream which incorporates a bunch of interested parties where you're bringing those dependencies into that work stream and getting people to realize that they have responsibilities to their colleagues in the stream and they're not just throwing something over the wall to the next stream.

Right. That is interesting. So then that group would be pretty diversified in terms of the different people involved in it.

Absolutely. It's through that different language and that different set of KPIs that they've worked to and a different sense of what's important and how quickly we can operate. It's through those conversations that you start to find incredible opportunities.

It's interesting because you always hear about these cross functional challenges or gaps that happen and it seems like this would be make more sense in terms of alignment between people, between teams.

Yeah, absolutely. You don't have to go through a prioritization exercise anymore. You don't need someone more senior in the organization necessary to jump in and say we're going to do this first and this next. Because it becomes unbelievably obvious what the right thing to do is and in what time frame.

Interesting. Would you say that would help decentralize decision making completely.

And I think that's one of the. It's again a thesis, I suppose that we would look from a cultural perspective is that we find organizations in general internal integration, which is that collaboration across function tends to suffer when you go through an M and A process, because people are not so sure anymore as to whether their network is still as strong as it was and it's still as powerful as it was before, and whether they can still deliver the same thing. So there's a general point to make which is that if that's a really important dynamic for your business when you're going through an M and A process, you need to really support it because it's by its nature going to struggle a bit as you bring new people into the process. But this as an exercise is a very powerful way of reinforcing that.

Again, let's step back and look at evolution of M and A over the last 20 years. What have you seen that's changed?

Oh gosh, Sorry to say that I am old enough to remember data rooms where you'd sit there in the lawyer's office for weeks on end going through different folders trying to understand what was going on with the business. Luckily, I'm glad to say, actually data rooms going online has been something good over the last 20 years. But apart from that, I'd say nothing. I mean, the problem with M and A is actually it is a sector that hasn't been disrupted, that hasn't changed. There are some exceptions to that, I'd say though. One is 20 years ago it really wasn't on the radar. 10 years ago it started to be part of due diligence and thinking. Whereas now I'd say every deal people are looking at the technology as a core question, not just doing due diligence on it, but really thinking about the value that's been created around the technology area and that then follows through into the post deal and also the pre deal thinking and planning with transition service agreements. I mean, people say sometimes people think that it's hard to change people. Actually it's much easier to change people in an organization when you get them to get a post deal. You know, you can get transformative change of people in three to six months. Transition service agreements for software redevelopment, you're looking at at least 18 months at the moment. Redeveloping data centers, migrating software across is tying these organizations together for long periods. Post deal and the negotiation of those agreements is becoming such a real major factor in almost every deal I'm working on at the moment. The final area, I'd say, is that before maybe 20 years ago, the focus on the deal side and the thinking was Very much on tangible assets and thinking about people as commodities. Whereas now, particularly as the private equity has moved into business services, more people focused business people are starting to adapt to intangible assets and how they think about the impact of deal on people and retaining them and motivating them going forward.

What are the fallbacks of Playbooks and what should deal teams follow in their absence?

I've been involved in development of lots of Playbooks and I know David has as well. And in itself they're not bad things to do. I suppose where we have an issue with them is that the value in a playbook is in the development of the playbook, it's not in the playbook itself. The process that you go through in building what might look like best practice from all the previous deal experiences is a very iterative, highly interactive process with those people who are key stakeholders that are involved in the exercise and those implementers that are sort of tasked with the challenge of delivering it. And that I think is a very powerful and useful exercise to do. And it's a safe place and organizations to have a proper post mortem about what went well and what went badly. I think where I have an issue with Playbooks is it becomes this sort of fail safe that everyone starts to use for any deal going forward. And the reality is that each deal, even if it's in the same sector, same geography, same scale, each deal is going to be fundamentally different because it's run by different people and it's run a different way. And the dynamics of those businesses and the dynamics of the client base and the dynamics of the pull up mix and the dynamics of the operational platform are all quite different. And so to expect a playbook and some of the ones I've worked on in terms of the development have been to the most ridiculously deep detailed level. To expect that to work in a different environment, it almost removes the sort of thinking part of the brain and expects some sort of automaton process to work. And I think that's a mistake. And I suppose we're trying to encourage people to go that lots of companies I've worked with have got a very clear vision and a very clear direction of what's critical and what's not critical, what are the absolute must haves and what are the things that we will absolutely not do in the process. And that is a very valuable set of guidelines. But when you start getting into task based activities at that granular minutiae, I think that's when it starts to fall apart for me.

I Helped create a playbook with a go to market strategy for digital kind of media and advertising sector. And it was just looking back on it, it was that team we developed, we had a team of 30 people that really understood how we were going to go to market, what the customers wanted, how are we going to deliver it. And that tea was immensely valuable. It was not the document afterwards that we had.

That's a good point. One of the things that really resonated with me when you mentioned having that development of the actual plan be iterative. Can you tell me a little bit more in terms of what that means and how that breaks away from the traditional approach of doing it.

It sort of goes into the question of why we think agile is a sensible way of operating. For lots of people who've worked in businesses for a long time, the way that they operate within those businesses is almost as intuitive as the process you use to get dressed in the morning. And if you ask people to describe that process, they won't be able to tell you the order in which it worked. Left, top, first, right. I mean, who knows, right? That's not a process that you sort of think about. And it's the same for people who've worked in a functional environment for a long time. It's very hard for them to describe in an objective, rational way what it is they do on a day to day basis. So when you're starting to investigate opportunities for people to work together and think about and develop things together, and engage with clients together and think about new products together or services together, it is equally iterative because you know, it's not a process that you've thought about in the past. So that sort of leads to this very fast moving, quite small change driven set of activities that. Let's see how that works. Let's try that again. Let's move that forward. And that's where I get excited because what you see is you see that very sort of positive energy coming out of that exercise. You get people very comfortable with rejecting things that are not going to work in a very quick space of time. And so the decision making process speeds up and people are comfortable with that. People are comfortable with the concept of not solving everything to the 100%, but solving things to a percentage which feels right for each individual. So we're not dealing with the tiny, tiny things, but we're dealing with the bigger issues and we're just moving forward and creating that momentum through the process. So I think that's where I come from, from an iterative perspective My individual.

Background was in manufacturing on the steel side. And so some of the early things that I worked on were kind of technology exchanges between Europe and Japan and just looking at lean manufacturing was changing the Japanese way of doing things. And actually what we could learn here, and that has always stuck with me through my career, is that kind of developing systems which deal with complexity and uncertainty, that are iterative, that are learning, that are emergent, that you can plan and you can come up with a strategy at the start, but you really need to think of as you go along. And that really is how we approach the integration. It's what we found works because in a pre deal environment you've got limited time, you've got very limited information and access to people and coming up with plans and you need them to accept that actually when you get post deal a lot of the things you assumed are going to be wrong and a lot of the things have got dependencies you hadn't imagined and you hadn't envisaged. So that ability and that willingness to learn and evolve as you go through the integration is the core factor for success for me.

Yeah.

And it's very fundamental to being agile. Speaking about agile, tell me how you learned about Agile and why you thought it would be valuable to M and.

A. I had a small client, European based, they had an ad tech platform being used actually by clients like Google and Facebook and Nike to deliver campaigns. They had this challenge where they were mainly on creative production, but they had some software as well. And so I was really helping them think about how acquirers would value the different types of business and how they should structure themselves and the value they had hidden within this ad tech side of the business. That meant that even though it was maybe a third of the revenue of the business, it was actually worth three to four times what they were generating on the creative production side, just the way the acquirer would see them. And they had a failing software development program, they were kind of migrating software over and it wasn't working. They were trying to outsource. And so I kind of rolled up my sleeves and said this looks like a really interesting challenge, let's build a team in London next to the people who are using the platform so they really understand the customer requirements. We build a team of six people based in London and turned around the program and developed the new platform. And that was my kind of hands on learning around agile software development. Had a great team, had an agile coach who really kind of took me through it. And it was through that process that I saw that everything they were doing about how we were organizing the team, how we organize the structure of the the project, how we learned as we went on, how it was, that kind of self organizing approach was right at the heart of exactly what I've been doing for the previous 20 years on the deal side which got me into looking at the principles of Agile software development and Agile Manifesto. And as I said with production system you kind of get it all goes around in a circle. This is all based on the same kind of thinking and it's exactly at the heart of what described. It's about what you're doing with MLA integration is you are getting people to change. Yes, the systems and process change, but they're changed by people and it's about changing people's behaviors post deal as you deliver the value. And that's why self organizing teams about the opportunity where you recognize that the value is getting people to work together in a collaborative way. At the heart of Agile is exactly what works well post deal.

It's interesting how you were able to find these essentially correlate these opportunities with Agile from the software side into M and A. You both have a history of conducting project management, various large complex deal processes with an emphasis on post closes integration. How have you introduced Agile to your approach to these complicated processes?

I think the way that I've done it in the past that was probably part of a sort of challenging exercise, the organization anyway was to give people what perhaps seemed like an impossible task, which is, you know, I would in several situations I've isolated a small group of people who sit within a particular function, an area that has lots of potential added value. And I've sat the two groups together and said you've got a time frame which is wholly ridiculous in the context of the time frame that you've had in the past to develop something together. And I want to see how that works and how that goes forward. And once they get past the shock of what perhaps might have taken a year in the past is now going to take 100 days, it's very interesting how that almost naturally leads to a much more iterative, effectively agile approach to building something. And it obviously provides the other added benefit, which is it distracts from the mundane aspects of the integration process. It's a very good way of bringing people together and you get something great out of it. We did that quite recently in the development of a roadmap across two different businesses which again would have been quite difficult to do. There were lots, you might have been lots of Politics involved in that conversation. Lots of PET projects that were people might have wanted to bring into that process. But again, by changing the parameter, which is you haven't got this much time. You've got this much time and it's going to be done in a very open forum and it's going to be done in a very iterative sort of way, and we're going to see results every week. We're going to see where you're getting to and how you're driving that forward, and we're going to try and build that sort of capability. It's amazing how quickly people adjusted to that and enjoy that process once they get past the sort of you've got to be doing type scenario.

One of the things that really caught my interest in what you just said is how you're taking the context of Agile's application and new products. But then also in terms of integration, it doesn't seem like there's big distinguishing differences between the two. Does that sound right or are there differences when you're looking at applying Agile for new product development versus an actual integration of a function?

I don't think there are enormous differences. I tend, probably because I've not got the same level of sort of experience as David has in this area. I don't tend to use the language, the Agile language and methodology language, very much because I think people just get more confused by that than it necessarily helps, especially people who are not used to that method. So I take the principles, we talk through the principles very closely and they understand those very closely. So that's, I think, a bit of a difference, but certainly because the basic premise that again, something that I think integration suffers from is that business cases are written six, nine months, maybe a year, before the deal actually gets completed by people who often sit outside of the two organizations and who have a purely external perspective on what the market may or may not be able to, or, you know, what opportunities there might be in the marketplace with limited or no access to the individuals who are going to make it happen, and with no real sense of what the integration is going to look like. So to some extent, the first challenge for me is to say, okay, we've got a bunch of synergies that we need to achieve, but we're going to put those in a bucket over there, which is ignore them for the time being. And what we're going to do is sit down and talk about how we can create the right environment and start to do things together in a really fast way that people perhaps won't be expecting it and it sets the tone of the integration process going forward. That's the starting point for me is to acknowledge the fact that there are some targets that we're working towards which we will need to achieve against. But those targets are not the limitation factor. They're not the factor that's going to stop us from doing other things. They're not going to define exactly what we do and how we do it, because they're based on a set of assumptions that were drawn up a long time ago and with limited knowledge. I would love to see and find that crystal ball that those strategy consultants look at on a regular basis, because I just, I haven't found it yet.

It's interesting. I like how you emphasize the operating framework for the teams to work together early and put the other things aside. How if we shift a little bit and get more specific in terms of how you're using Agile to improve your clients deal workflow.

If you look at the tools we're using, they're extremely simple. We always go with the most basic simple lists, simple approaches to doing everything. It's the most basic form and a part of that is we're dealing with a wide number of people and we want everybody who's in the team, across all the different functions to be able to work with us in the same way, collaborate with us, access everything we're doing. So it's got to be a very simple, basic tool that everybody can understand with very limited training and everyone has access to using those tools. Then we're about working together as a team, collaboratively. I'm doing the same. Exactly as what Ben said earlier is we're avoiding the language of Agile because there's a lot of baggage that comes with it. And the people we're tending to work with across the organization may have a superficial knowledge or expectations around Scrum or Kanban or different pieces of software. And actually we need to cut through that and say, no, your expectations might be wrong. Let's establish something which we all can understand, they're all on the same page and then work together. They are very comparable to different techniques in terms of how we organize team meetings. There's a very kind of Scrum, short meetings, time, boxing regular dumbbeats, bringing people together. There's a lot of similarity about how we take ownership and as a team we get the requirements and then we own those requirements and then we deliver them and then we work with two product owners and stakeholders for getting understanding client requirements and delivering the project. But it's Just the way we talk about it is keep things in a very simple layer that everybody can understand.

It's interesting. I agree with you about the terms of Agile can be intimidating I think especially taking into aspects of the finance industry. So I do understand your approach in terms of not getting so much in the weeds of the jargon and so forth. And some of the things you mentioned too where you're actually using the techniques when you're for example in terms of meetings and having shorter time box meetings, are you doing a similar stand up type of approach where they're daily meetings or is this stuff, is it getting modified in terms of application for M and A or is it really the same?

It depends so much on the client situation. So often we'll be working on projects where the team is dispersed across. Last year we had the delivery team, San Francisco, New York, Toronto, London, Taipei and Hong Kong and Tokyo and all those time zones all needed to work together. So finding a time of day that they're all able to dial in and work just isn't going to come together. So verbally we might be able to find, you know, get people up in the middle of the night to do that once a week, but you have to find alternative ways of structuring the team. Alternatively you could be come and climb with at the moment actually everybody's on the same site. Contractors are coming in in different times, days a week. So really I'd say in the M and A space it's more of a weekly drumbeat than a daily drumbeat. But that does vary through the stages. So through the final stages of the deal, as you come up to day one, you are on a daily basis talking to everyone, getting everyone together, making sure everything's in sync. And that typically follows through for the first week or two post deal. But then when you start to work on the real longer term projects, you then hive off. And yes, the team that are working on the software migration, they'll be working together on a daily basis whereas the team over here working on branding, actually quite quickly it resolves to almost their business as usual processes and you're catching up on a monthly basis. So varies a lot by time through the deal process and also it varies a lot according to the situation of the client.

That's interesting. You're being agile about it. Yes, I think too that's part of it is there's these different methodologies and techniques that are part or associated with agile but that they're flexible, you can tweak and adjust them. I don't think anybody follows everything by the tee.

Yeah, definitely. It's that flexibility all the way through. And I think that almost that's the hardest thing for a lot of people we work with to understand is they think they've done their planning and they think they've got the deal. And all you need is somebody who. There you go. Deliver that. And there's so much that needs to flex as you go through that. As soon as they can understand that and adapt to that, they're on the right path. Path to success.

Are there other techniques that you're leveraging as well? I know earlier you mentioned postmortems, which I would associate with doing retrospectives in terms of looking back at the end of the deal and what went good and what didn't go well. Is that something that you're doing?

I like the idea of pre mortems. We do a bit of that because it takes some of the fear out of the process. I've seen lots of people use that in lots of different environments. And it's good because it helps people deal with things that they don't necessarily want to deal with or haven't dealt with in the past. And once you uncork that, you get to a much stronger sort of approach towards mitigation and also towards early identification of an issue. It also goes to the sort of inherent false optimism that people have about the success that they're going to have in their projects. One of the most fun things that I do regularly with clients is to ask them, I look at the sort of slate of activity with regard to integration and say, you know, I remember one recently which, which I worked on in Malaysia where, you know, they had something like 45 really sort of medium to large size projects as part of the integration process. And ask them, so, you know, in your normal business as usual situation, how many of these would you expect to deliver in a year? And the answer was seven. You know, so that's interesting because you start to challenge their sense of what's actually possible in the context of the deal. And that forces a degree of prioritisation around the exercise.

One thing I really learned from Ben is this concept of psychological safety. And so it's almost as though that willingness of where you get the team together every time you're willing to be really honest and frank and say what you're thinking, that often I've been in businesses or environments where it's only with a port post mortem, everyone then suddenly says, oh, this is what was going on and this is what's frustrated about and this is what's happening and that actually being able to do that on a regular weekly basis and creating a team that is willing to be that open and honest with each other means that there is no need to have such a lengthy kind of post mortem process at the end because you're doing it as you go through the plan.

That makes a lot of sense. Can you talk about the cultural journey teams and organizations must take in order to adapt more efficient technologies and project management methodologies?

Yeah, I think cultural change is one of those brilliant things about M and A is that it's one of those points in time where people are expecting change and people are open to change. The challenge is often getting the management team to realise that their behaviors are being, you know, through their status and through authentic kind of communication those things are having such an impact on the organisation. The cultural change and behavioural change or behaviours have, can be an amazing tool for changing the organisation. But also their risk as if it goes bad and they're not aware of how their behaviour is affecting the organisation can really take the organisation in the wrong direction for quite a long period of time. I suppose what I find a lot is when I go into a client I need to take my own values. So my belief in agile, my belief in emergent learning and self organizing teams, each time you have to go in with your own values and say this is actually how I think for you as a client, you can best go about things and try and demonstrate those through my behavior and then encourage everybody else to behave the same way and then try and reinforce it from there.

The leadership often thinks that cultural alignment is people getting on with each other and it's really not that. It's a much more challenging and different way of operating. And the worst thing that can happen that happens, unfortunately quite a lot is that leaders from two businesses come together and they seem to get on and therefore they suggest to the organization that there are cultural barriers between them because they've got a reasonable relationship at 60,000 foot level. And so when the two organizations get together at a much more granular level they discover actually there are fundamental differences between the way that they operate and it becomes very easy to forget quite pejorative your ways worse than my way, whatever, which is clearly not the case. But more importantly than that it destroys some of the trust in the leadership. Because my observation of what's happening in this business is completely different from what I've been told the case is. And so therefore some of that trust that I have in my leaders evaporates to the full. So that's the first thing I think the second thing is that is interesting around culture and it's obviously been a subject that people have talked about a lot the last 15, 20 years and even probably further back than that in academic circles, is that it seems to stop at the end of the cultural assessment process, which is completely nuts. Now I think cultural assessment is really valuable and if you can talk about each other's businesses and the way that you operate and the way you work in an open and coherent way and in a non pejorative way, then that's a really powerful thing and it starts to create some language across the two different businesses which gets over some of those hurdles. But to leave at that point and not to use what you've learned as a way of trying to understand how we need to go, what we might need to change, or what we can agree on and how we operate going forward is a real shame. And I think actually the integration team for me is the spearhead of that change.

Can you tell me more about your people focused approach and how it's making M and A more successful and equitable?

So my approach to people is to give them as much space as they possibly can. I have my expectations of the people who work with me in M and A is that everyone's a communicator. And so if you're involved in an M and A team, you need to have as much breadth of knowledge as you possibly can around what's going on elsewhere because inevitably you will become a source of knowledge for the rest of the business. And therefore your ability to understand and communicate at a reasonably detailed level what's happening elsewhere is critical to prevent those sort of silo type based activities. I think the second thing is that the way you structure your teams and the way that you communicate with your teams and the way you expect your teams to deliver stuff is down to your personality. So I'm not going to try and influence you in doing things in a certain way. But my expectations of the team are that they deliver things in certain times and timeframes in a smart and intelligent and empathetic sort of way. And our expectations the same thing to happen further down the business. I am incredibly open about my own failings and weaknesses in terms of activities and things that I just have no understanding of. And I think that feeds to an openness and a willingness to admit those or deal with those things from a project team perspective as well. So the team becomes very Clear and very open about things that they're struggling with.

Yeah, that's true, Ben. You're definitely open. I think that's what I mean by psychological safety. By showing your vulnerability and being open to your mistakes as a leader, that allows everybody else to feel the same. That's a safe environment for them to do it, too.

I agree. That's a really strong point, and I've heard that before in other interviews. In terms of the aspect of psychological safety, other thing I really admired was the aspect around accountability, but at the same time balancing it with freedom to create. I think that's when you meant stepping away from the detailed managing aspect of it and just aligning what needs to get done. But giving team members that freedom to do things their way and then also breaking down those barriers and silos were other really strong points in terms of taking those approaches. How do you approach evaluating the capacity, capabilities and even compatibilities of the combined teams?

Pre deal do I have. Look, I suppose I spent 10 years in executive search world, so know how to do that, and I've done that for a number of years. And what's interesting about search is that you're obviously doing it not just for yourself, but you're doing it for the client. So that's interesting as well, because you're starting to evaluate what a stakeholder might perceive as being relevant or not relevant. However, I suppose I tend to respond very quickly to things that are not working, and I will make decisions based on that relatively quickly. I'll give people lots and lots of space. But if I feel that there's a lack of compatibility there, then we need to make a decision about that quite quickly. And I think that's important for them and for me in terms of capacity. Busy people are always busy and the fact that the more busy you are, the more you can do. I have some sympathy for people saying I'm operating 100%, but I don't have that much sympathy for it because it tends to suggest that delegation is not happening as much as it needs to happen. And in terms of capability, I did some interviews in Asia a while ago when I was living out there and I was asking people about Asian leaders, about whether what they valued most, whether it was the capability of the individual or the sort of honesty and the degree of loyalty to each other. Without exception, every leader that I spoke to talked to the loyalty and the trust that slips between. So I think you can teach people pretty much anything if they've got a brain. And I'm much more willing to invest in people if they're starting up on an M and A journey and show them and spend huge amounts of time with them to build up their capability rather than bringing in people with the capability, but perhaps not with the right approach and the right attitude.

When you go through this and you start thinking about cost synergies and revenue synergies, how do you determine where you're going to put your emphasis on?

It depends. It's deal by deal based. I suppose our thesis is that starting with cost creates a cultural barrier to revenue which is very difficult to get over. So our instinct is to say let's see if we can create something and let's see what opportunities there are for operational improvement and for products and services and new ways of doing things that will add from a revenue perspective on the basis that we can come back to a cost synergy target at any stage in the process and we could still achieve that target. Now there are some obvious places obviously where you don't. You can start with costs and it's logical and sensible to do that. But I suppose my instinct is to do the former first and then the latter next.

Yeah, I think I agree with that. It's about being customer centric. So sometimes that means actually there's new products, new people that will benefit from working with you. Sometimes that means your existing customers actually you've got an ability to provide them much better service at lower cost. So very much depends on the situation. But the status quo at the moment is it is cost, cost first. You just see that in Kraft Heinz, the headlines, we've stripped out all the cost and now we've lifted our heads up, we said, oh shit, there's no way we're going to be able to increase the revenue here. If you strip out the cost without understanding where you're going as a company in the longer term or what the opportunities are. Longer term, how on earth do you know what the right costs are to cut? What are the things you need? What are the things you don't need? You need that balanced view that Ben's describing about what the longer term opportunity is. So you're cutting in the right areas.

It makes a lot of sense. I like that perspective, especially when you mentioned being customer centric. I think that's a key thing and important when really thinking where your opportunities are and alignment falls. What is the future of M and A? Project management and how does Agile fit in?

I suppose it's about not having an end state. Project management is so much about. We're at point A, we're going to take you to point B and then it's, it's the end. You envision where you want to go, you get that project done. And so when you approach M and A in that way, you're saying we're designing an end state of the organization in terms of systems and processes and people and we're going to get you there. Whether that's an iterative process or a waterfall process. The reality of today for me is such that you never achieve that end state. And if you try and get there, actually the situation and the environment will evolve so quickly that end state is no longer where you want to be. So instead what you do is you take where we are now as organizations and you quite often say where do we want to move to? Which is neither where the target is nor the acquirer is, it's somewhere new. And equally you may never get there. And as you get through the project and process, ideally with an agile, so you'll be delivering value as you go, then you start adapting and changing your goalposts. So I'd like to see project management move from being, you know, I'm going to get you to that place which we've predefined to. I'm going to work with you on a continual basis to try and get to the best place you can be delivering value at each step of the way.

Companies will need to continue to transform for the rest of their existence and that is not going to change whether it's an M and A process or it's a transformation process or it's some sort of geographical expansion or it's or some other disruption that's taking place. So the ability to learning how to learn that skill set is a fundamental thing for a business to be successful going forward. And the more it's incorporated in the sort of DNA and the culture of the business, the better the business will be.

I like both of your perspectives on it. I really enjoyed hearing about the definition of the end state but keeping it iterative because I find that very true within our own organization is that by the time you get there it's a whole new slew of goals and things have really changed. So I like that concept and completely agree. One of the biggest big things I've heard throughout this interview in terms of Agile and how it comes in play with M and A, it seems like there's more emphasis and getting the teams working together, but even more so about the opportunities post close and really pursuing them. And it just seems like there's More focus, there's more capabilities and bandwidth around achieving these new goals, which could be those perceived as more challenging revenue synergies. Are there any certain closing thoughts around that that you have in terms of how this really comes in play when we're looking at implementing agile in the M and A context and what the real driving benefits will be for the companies involved?

I suppose I'd start with Agile and revenue synergies. My mind goes straight to the idea that so many companies we take for granted, we know what the customer wants and what I loved. I love a project when we're actually doing research, talking to the customers and the customers are talking to us and telling us what they perceive as the opportunities, what they perceive in the business and the brand, how we can add value to them rather than purely looking internal and saying what do we think the customer wants? And that kind of is agile in a kind of, I suppose in a slightly different way, but it's right through to the external customer thinking about what they need, understanding their needs, developing something for them and then seeing how it.

Works and then adapting the concept of smashing organizational structures which are becoming barriers to processes by creating that sort of cross functional, highly iterative, very fast decision making capability that exists within business that sort of forces that decentralization across the organization and bringing that skill set and that capability and that experience, that learning experience. Because what happens when people get involved in those teams is they rave about them, they enjoy them, they get excited and want that to continue their other lives, their lives outside the integration process. So I think that's when you start to really infect an organization with not necessarily what you might describe as an agile methodology, but a sort of agile set of values around how of business are going to work going forward. That's I think where the ultimate opportunity lies.

Wow, that sounds really exciting. It's the right way of thinking about integration and turning it around instead of a major chore or task to do, but a slew of different opportunities to pursue. So one question I like asking for fun is what is the craziest thing that you've seen in M?

And a good question. Some pretty crazy things.

You don't have to name any names.

Or dates, but I'm not going to name any Bates, although people who know me might know the story and David certainly does. I've seen a situation where everyone with a C in his job title in a medium sized organization spent three hours discussing the number of car parking spaces that were acquired in the new head office building. That was pretty mad wow.

This is one Ben loves to talk about as well, is an organization that bought bought a business that wasn't really doing what they were doing at the core. It was slightly different. It was more software data than what they're actually doing. And they forecast revenue synergies, overall synergies. Five years post deal to the nearest dollar. And that's crazy as well. Just thinking that forecasting five years for any business is hard, but actually taking that uncertainty pre deal and that due diligence and then saying actually we're so certain about this, that this is where we're going to be five years later is pretty crazy.

Yeah, those are some interesting ones.

I'll give you one more. I worked with one professional services business partnership and this was terrifying to me as someone who's coming in to help deliver the integration process where they required 100% approval from all the partners that the deal was going to go ahead. That's an extraordinary thing. You just need one person is just feeling a bit grumpy for the deal not to go through. But what was really interesting is that the way that that changed the dynamic of the deal because the people who were proposing the deal had to almost have to segment their partner groups into different groups as to what their motivations were and why they were keen or why they weren't keen and what buttons to press and how to engage with those people and how to think about the implementation of that process. So actually started the process really, really well and did that thing that we talked about early on, which is sort of almost operationalize the capex decision that the organization was about to make.

Sounds like a lot more effort to get to a decision.

True. But the implementation then becomes remarkably quick.

Very interesting. Hey gentlemen, thanks for sharing those stories. Ben, David, thank you very much for spending the time with me today.

It's been fun. It's been a lot of fun. Yeah. Thanks Kisser.

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 Kison K I S o n@dealroom.com M&A Science is sponsored by Deal Room, 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.