Architecting Communications for Successful Integration
15 Aug 2022 · 45 min
Kison Patel talks with Emma Barton from AstraZeneca about how to communicate during mergers and acquisitions. They cover kickoff meetings, building relationships across teams, resolving disputes, and keeping employees engaged through culture changes.
Hello M and A friends. If you're looking to improve your in house training, we have corporate training plans provided through the M and A Science Academy. Give your team members access to the best in class courses, templates and networking opportunities in the industry. Our Academy was designed to lead practitioners with the how to of M and A practices. If you're interested in learning more about individual or team plans, go to mascience.com academy. It's also a great way to show your support for M and A science. Again, that's mascience.comacademy onto the interview I'm Kisan Patel and you're listening to M and A Science where we talk with deal professionals and learn valuable lessons from their experience. This podcast focuses on stories, strategies and what actually happened during M and A deals. Welcome to M and A Science where leading M and A practitioners share lessons learned from their experience. Before we kick off, I want to give a quick shout out to Valuation Research Corporation, otherwise known as vrc, for providing our office space in Midtown Manhattan to produce our podcast today. You can definitely use any consulting firm out there for valuation work, but if you want to work with the best, check out VRC and Valuing Intangible Assets Impairments PE Portfolio Public Companies. They got you. If you're interested in keeping up the latest from M and a science, visit mascience.com and subscribe to our free newsletter. Every Monday we share highlights from our interviews and invitations to events events as we build the greatest community of forward thinking M and A practitioners on our website too. We got tons of free content. Again, that's mascience. Com. I'm your host Kisan Patel, CEO and founder of M&A Science. Joining me today is Emma Barton, Director, alliance and integration management at AstraZeneca. AstraZeneca is a global science led biopharmaceutical company that focuses on the discovery, development and commercialization of prescription medications. They also traded on NASDAQ under AZN. Today they're trading around about a mere $189 billion pre pandemic. I don't think anybody in the world knew how to pronounce AstraZeneca. So now we're on the same page about that. Fair to say.
Yeah, I think that's fair to say. I think we're certainly more of a household name now than we have been.
Previously and today we're going to talk about architecting communications for successful integration. Edma, can we start off by learning a little bit about your background?
So I've worked for AstraZeneca for over 20 years now and well over 16 of those have been spent in the business development arena. I'm a chemist by training, but I moved fairly early on from the science side of the organisation into business development and I've had the privilege to work in the earlier stage collaboration phase of the organization, later stage licensing and larger scale commercial deals and cross the various aspects of business development. My current role I've held for the last seven or so years has been in alliance and integration management and that's really important to us as a business because partnerships are one of the strategic focuses for our organization and it's one of the ways as a pharma company that you can really change the shape and make up of your portfolio quite swiftly. So it's something that we do a fair amount of. Unlike many things that the value in these deals that we see, all the big press releases are about really comes out when you actually do the post deal management and you actually bring assets into your organization or you move them out of your organization.
I just want to make sure. Did you mention that you're a PhD chemist by background?
I studied chemistry, yes, to start with and that was the origins of my career.
I just want to make that point in our industry, M and A, you don't have to necessarily have a finance background. It's a very diversified and that's. We're going to get a little bit of that as well. When it comes to communication, what are the areas that you focus on during integration?
You need to make sure that you communicate as well as possible. And I know that's an obvious point, but I think it's one that gets missed because there's so many things to do at the same time and you're really trying to set up lots of work streams at the same time. It's really important that you keep the communication across those with your internal teams really well and make sure everyone has the latest information as you move through those. But of course, speaking to the company that you're working with that is your partner, whether that be you're moving asset integrations in or you're moving a franchise in or you're moving a company in itself, it's really important that you keep the dialogue with that partner as well and that you have quite structured communication so you know where your touch points are and your bases are setting up the touch points and the communication architecture is important there to make sure that you do know who you can contact when you have questions and make sure that the information is cascading in the right way across the organizations.
So I get mapping out the touch points, but it also sounds like there's an element of contact management. So you know who to get hold of when?
Yeah, absolutely. And I think it's important that's well documented. It's very easy when you're first sort of getting to grips with lots of team members and things like that, not to be instantly able to bring those to recall. So actually having that process documented and ensuring that it's clear that you have regular touch points, that you. You have various forms of communication built into the plan is always something that we look to do.
So I want to step back. I remember our prior conversation. We had a couple of key pillars around this, which was employee experience, building relationships, and then addressing culture. I think it'd be fun to go through those because it seems like you have some ideas of things I can learn from.
The relationships is obviously key. If you communicate with clarity, then that's going to help you to build trust. And what you're looking to do is form a working partnership with the people that you're working with in your integration. It's helpful to make sure that not only do you know where your touch points are, but actually that you're making sure that those interactions across all the teams and at each level happen frequently, that you have those regular touch points. And actually the communication is taking place in the right way to build trust. I think in this day of electronics, it's very easy to rely on an email because it's quick and it's easy. But actually we've not really got any excuse not to be reaching out and having much more meaningful interaction with our partners and with our team members. It's really important not just that we're keeping that frequency of communication, but that we're also using the most appropriate form of communication as well. Face to face is the gold standard when you want to get to know someone and build trust. And if you could do face to face and you can add in an element of socialization there so you actually get to know each other as people rather than just in a business context, that really is the gold standard that you want to do. That's not always possible, but we have all these lovely formats and especially I think post pandemic, we've learned how to use those very well. Zoom calls, our team meetings and things like that. So it's much easier, really, the distances to build those relationships as we move forward.
Okay, so unpacking, building relationships, big key is to communicate with clarity with that. We're ultimately trying to build trust. And you mentioned there's different elements in ideally meeting face to face. I'm curious about the who, because I want to. Let's maybe map out the different people that you would interact with internally, potentially externally.
My role is really to coordinate across functions and so the various sort of departments within our organization and ensure that we're providing aligned messages, ensure that we're moving integration forward in a way that we would expect it to be moving and making sure that very early on we're addressing any key issues that are popping up and things that we might need a more senior level conversation to take place. So internally, from my perspective, it involves close contact with a representative from each of the key functions across our organization that are required, depending on what we're integrating and that can come at different stages and different places into our organisation. So really initially identifying where things are actually going to move into the organisation, who the key stakeholders are and who are the key functions that are going to support the asset that's moving in so that we know where we can set up the team and where those touch points should be.
Is it usually the head of the function or does it just completely vary.
Function to function within our organization we have set up people from each function whose specific role it is to move assets between organizations. So for example, we have a head of M and a IT and that team's role is to actually support all the information technology aspects, aspects of moving assets in be that sort of company level, be that product level or somewhere in between. We have similar across the other organizations. So for supply example, we have an established supply organization. We have the same for regulatory, for pharmacovigilance. So all of the key sort of functions that are involved in the manufacture, the development of our products would be involved in that. From an internal perspective. The stakeholders then tend to be either our project sponsors, the people we're actually delivering for, or also the stakeholders to manage are those heads of departments that you mentioned. But that's where we really use our technical leads and use their expertise to influence their stakeholders. So we tend to have quite a large stakeholder pool as well as a diverse group of individuals that are tasked with managing the integration.
But within these different departments you have dedicated M and A resources. Then you got the actual sponsors of this deal and you go across the different functional heads and those different functions. You got a lot of triple digit market cap company problems there.
Size is both a blessing and a challenge. And of course one of the biggest challenges that you have as A large organization with many thousands of individuals working for it is actually the messaging and making sure that's clear, transparent and timely. And I think that's why for us it's listed as one of our most important factors in a successful movement of assets.
Is there in your head a strategy around the approach you take with relationship depending on who they are? Like there are certain real key people. I'm going to make that point to have that face to face. And how does that vary or how does that get engineered in your head?
It's one of making sure, I think depending on the message that you're delivering. So typically we, I would bring cross functional team leads together so we can have have a cross functional forum for discussion, for problem solving and working together. I think when we're updating stakeholders, that tends to be done on the more asset based integrations that would be done more on a monthly basis via a steering committee. Depending on the scale of the integration within our organization, those updates would be done in various different ways and I think with various different frequencies depending on the pace of the integration, depending on the level and size of the integration and obviously how that information was needed across the business. So we tend to be quite flexible in the approach. I wouldn't say that I base the approach on the specific individual. It tends to be more the need for the information flow and the most efficient way to get that across.
Do you do something to get alignment on that? Here's gonna be our approach in communication, the frequency and things like that. Or do you just come in and say look, done this enough times, here's how it's gonna be done.
I think it depends really on the need of the project and it's something that we tend to look at and review and over projects. Also the frequency of updates tends to vary as well because you always go through periods of really intense activity where things are moving very quickly and there's probably a need to be updating stakeholders, teams and communicating much more frequently. Then as you go through to a steady state, you tend to get to a regular cadence of those types of updates. And obviously as you get to the tail end when there's perhaps less activity, that communication frequency would tend to drop off at that point. So it is really more tailoring and it's checking in with the teams and the members to make sure that actually they're getting what they need from the meetings, from the forums, from the updates that we send and just listening to that feedback and adapting appropriately.
How do you get feedback? Do you have a specific technique or.
Approach in general, I like to ask for it face to face and see what happens. If you're managing very big teams, depending on the nature of the collaboration or the integration, there's also tools and platforms and companies that can help you actually carry out those big surveys, those big dynamics and things like that. So again, it comes down to what sort of appropriate at the time. I think there's nothing as quick and easy as actually getting some direct feedback and asking the response from your stakeholders and whether you are meeting their needs. But if you're actually trying to look at the health of the project and how things are going, getting access to a large number of people and their views, you obviously need to take quite a different approach with that.
True. I might be biased here. As a podcast host, Emma, I am convinced that I would rather have a sample of one conversation out of a hundred as opposed to the survey results from a hundred people just saying, tell me what's going on, what's going good, what's going bad, let's talk this out versus I don't know, I could be wrong. I haven't sent a lot of surveys out.
I think where we see value and we tend to use those larger kind of survey platforms, I would say on very big collaborations and things like that, is actually that the responses can help you identify patterns and where there are certain areas that are not performing as well. And obviously the danger of one or two sort of people is you tend to get a personal view as opposed to a general trend. I think they can be very powerful tools for helping you to flush out. Where it may not be obvious, it may be a lower level of things being a little clunky and not working quite right. But actually if you have a number of people reporting that back, that becomes more of a trend than one or two people saying, it's okay, we can live with it. So it can help you drive, I think trends that you and undercover things that perhaps aren't obvious just through asking.
So you've convinced me. I'm going to give it a shot.
Good.
Anybody gets an M and a survey from me, you'll know why.
You'll be expecting me to answer right.
Now, and you're indirectly, by listening to this podcast or interacting with our brand and obligated to complete that survey, because that's a whole other thing. I feel like you get a bias based on who actually answered the survey. Yeah. Make sure you answer a survey when you get it. Let's back up to the very beginning. When do you start thinking about communication.
I think as early as possible we tend to work very closely with the actual deal team and the transactors and as we're doing that communication is obviously thought about throughout. So I think there's an element of have the external comms to the market, but actually internally, how is that going to be messaged and how do you most efficiently get to the people that need to know about what's taken place? What does that deal mean? How are we expecting them to operate? Is there anything we need from them in the short term? When can they expect to hear from us again? And so that tends to be architected whilst the transaction is taking place and we tend to have that. And we're very fortunate as a large organization, we do have a communications department that is masters helping us construct those plans and actually ensuring that they get affected at the most timely points. So that is real bonus to us and that is very helpful. Then of course you need to make sure that sort of you're following through on those plans and those communications continue. So I think very quickly we're thinking about setting up the teams that we need to execute on some of the decisions. And part of the kickoff meeting we hold with those teams is really to engage ways of working to really make sure that we're thinking about how we're going to be engaging, how frequently, frequently we'd like to speak to each other, how frequently we need to update stakeholders and who's taking care of which parts of the business and the communication to those. And then of course there's the agreement to be done with your colleagues in your partner company because of course they may not have exactly the same. Whilst ideally it's much easier to work if they have a very similar team structure to yourselves, because you don't really need to think about things so much then actually that's not always the case. So it's making sure you understand, understand the touch points in that other company and actually you're making sure that you're bringing the right individuals together at the right time point so that that communication is optimized and you keep that going. And so one of the things we do in the kickout meeting is really try and set out the rules of engagement and how often, how frequently we expect to meet what the content and the purpose of those meetings are likely to be. And for me, because the representatives across our organization, they tend to be a single person that represents a function, they have teams of own and so it's the expectation on their teams and how frequently they would be Speaking with their counterpart teams from a functional level within the organization as well.
Give me the framework on doing a kickoff meeting and I'll tell you what I have so far because I think this is fun. Our marketing team loves doing this. On our website we have a thing called Plays and that's our Agile M and A framework, all these artifacts. So kickoff meeting would be a good one where how do we build a how to outline so far I got basically clarify the goal. Hey, this is what brings us all together here.
Yeah.
How often we're going to communicate and then setting of expectations and maybe part of that's what are we trying to achieve by when you got to lay out the framework for me.
There's an element of understanding the deal. So in our organization it's not the same people that have been supporting transaction that will necessarily be supporting the post deal management and the integration, the movement of the assets. So it's helping them understand the vision for the deal, what the purpose is, what the objective is and why it's important not just to us as an organization, but why it's been important and strategically important to the other partner company. We also need to understand a little bit about our partner in terms of who they are, what's their size, where are their focuses, what are their priorities. Because there's all sorts of layers within an organization and the chances are at every layer of that organization there will be different priorities, different strategic pressures, different appetites to risk or challenge. And that sort of feeds into the culture. So actually trying to understand a little bit about each other even to start with, just in terms of scale, size, setup, decision makers that can really help you actually make sure that you're getting the right touch points across that organization. The communication of course and the ways of working is another thing. But then also making sure that everyone's on the same page when it comes to the scope of the deal and any strategic decisions or ways that we've already set out and agreed things are going to be done and timeframes that are things going to be progressed to because we want to make sure that we're all operating towards the same vision in the same direction, with the same understanding. And that's the ultimate aim. The kickoff meeting is all about building relationships and we want to make sure that there's always a social element built into that because we're going to be working with our partners for a long time. We want to make sure that's a great experience. We want people to want to work with us again. We want to have fun along the way. And we want to make sure that we're. Everyone that's involved in that team is comfortable working with their counterparts, that they can pick up the phone. And ultimately the biggest risk in any postdoc management situation is the people involved. And some of that comes from experience or inexperience about what's being done and not quite knowing boundaries and things like that. And sometimes it just becomes because the relationships haven't been properly established or we're not understanding the differences and the drivers for why there's differences between the two organisations. So actually one of the biggest risk mitigations we can do, really, is make sure that people build that relationship with their counterpart as quickly and as strongly as possible. That's key because if there is an issue, the first thing I want people to do is pick up the phone to their counterpart, hit the video call button on their teams meeting and actually get together and talk about the issue. And what we want people to do is actually try and collaboratively solve differences. There has to be a level of trust in order to do that. And that comes from obviously the fact of communication and the transparency and how much that you've communicated and that you stuck to along the way. So trying to build that relationship as part of the kickoff meeting is one of the things that we really want to do and really want to achieve.
I'm going to try to go back on this, make sure I didn't miss anything here because I got my little hearsay version. But now we're going to walk through the Emma Barton's framework on a good kickoff meeting, a great kickoff meeting, starting with vision and purpose, this kind of going and making sure it's what it means for both sides. So not a one way thing, it's what does this mean for each other? And then also who the company is, which allows you to understand the culture. This is for both. Sort of talk about that from both ends.
Absolutely. I think it's important that we understand each other's constraints and each other's pressures and challenges. And there's always differences and you could probably spend two days just talking about those if you wanted to, but just having an early heads up of how we work as an organisation, how the other party works as an organisation. What are the key challenges, what do we think having heard about each other, we think the key challenges are likely to be and what do we need to think about when we're looking at how we're going to work together?
I have that for step two, then step three, actually have basically digging deeper and talking through the communication and the ways of working.
We don't just want to have a good time at the kickoff meeting. Hopefully we will, but we want to make sure that we've got those touch points. We're starting to document where those touch points will be, when we'll be next meeting, what the expectation is, not just for the people in the room, but actually the teams that they represent. So that's really what we're looking to do, to start to think about and establish those communications, those meetings, those touch points that we're going to be having and just have a think about things. And obviously one size doesn't fit all. Some of the partners we work with are a very different size from us. They may not have the same level of FTE resource that we do. So supporting and spending all your time in meetings is not going to be a great use of time. So we just need to tailor how and the frequency of communication so we can make sure that actually we're using our time optimally and not creating a pressure through trying to over communicate. So those are the sort of considerations that we have. Obviously there's drivers on both sides and stakeholders on both sides and we need to be thinking about some of the needs of those stakeholders from both parties and how we actually make sure we're meeting the needs on both sides. So really, that time to just get to know each other's organisation is really key to making sure that we're actually designing how we're going to do that interaction optimally.
For number four, I have agreed on scope. It sounds like that'd be a whole thing of its own.
Hopefully independently, we've done a sort of internal kickoff meetings correctly. There shouldn't be much discrepancy. So we always hope that we have a nice, clear contract, it's agreed upon and it's documented and there isn't really any gray areas and areas that are too open for interpretation. Just starting with the fundamentals and understanding what's in scope. What are we actually trying to achieve? Do we have any time frames that we need to meet? Is there anything that's particularly sensitive to time that we need to be aware of? All of these things can influence the plans we have for actually integrating into the business and how we might or might not do that. Just understanding that scope and what the contract says and making sure that we're all on the same page again, that's really helpful so that we can start discussing our plans and we don't suddenly find that we have Two sets of different assumptions. And so flushing that out early on is a good thing to do. And so we spend a little bit of time doing that. It's usually in a kickoff meeting.
Makes total sense. So number five, build relationship part that everybody understands their drivers from both sides. I liked how you framed the big picture. Goal is make friends with your counterpart and it's why you add the social element to it. What in the UK is the traditional social element you add in your kickoff meeting?
We try and encourage people when we do the lunch break to go and sit with counterparts. We typically would like to break bread with people. So we like to eat and have something to drink with people and just have some time relaxing and informal time to just interact and socialise. So it's always important, I think, when you're in any meeting to make sure that people are fed and watered appropriately. So I think any sort of breaks that you can build in just for some informal socialization over a coffee, over some food is always a good thing to do.
I was waiting for your response. Just gin and tonic.
That's hopefully in the evening afterwards when we finally got through the business of the day for sure.
A little more thoughtful. It's kind of a. Let's kind of get to know each other earlier for lunch, meet a new friend and then it will progress into, hey, let's party and have some fun.
Absolutely.
As we got to make sure that's in the framework. How do you address employee experience?
Do you mean how we staff the team and bring people in there?
I always think about that. I was just reading one of the earning call transcripts about improving the employee onboarding experience and it's one of these serial acquirers. They're doing a big roll up and even the CEOs acknowledge that they need to improve that. Yeah, I'm going to record this so I can send it along to them and be like, hey, here's some advice for you on how do you actually do that in that framing, if that makes sense.
What we try to do following on from that is really to keep the meetings going, keeping the touch points going. But in the background, I think one of the things we do very much is make sure that we use the material we've used in those early days and that we've generated to put forward an onboarding pack. So when we have people join the project and we get project turnover on that project, people may have greater or less experience, it may be a development opportunity for them. We can make sure that the first thing they do is have the pack of all the information. And this is sort of the written form of the kickoff meeting, if you like. Hopefully it doesn't take two days to read. They give a comprehensive set out of playing back those key values around that kickoff meeting. So the joint vision for the team, why the deal is as important as it is all those things a little bit about the partner company. There's something about it, obviously something about ourselves. It's great if we can actually have a joint kickoff onboarding deck that we use with anyone that joins the team. One of the measures of success for me is if actually you can have a stranger or an outsider piloted into one of your joint teams and actually they struggle to tell which company each partner works for. And that to me is one of the measures of success. If it's hard to tell who's on your team and who's not, that's great because that means you're working together as a team. So if you can agree to have a joint onboarding pack that you share with both parties and you've agreed on the messaging, that's even better. But we use that then to make sure when we have the people joining the team that actually we give them that as a reading point. I would typically like to follow up with people joining the teams. Obviously I can't do that for all the teams that support all the teams, but certainly my touch points and contacts that I would be working with regularly and make sure that I do a one to one meeting with them where I can answer their questions and take them through some of the key elements of the deal and just give that support. If it's not someone that I know has had a lot of experience experience or work with me on a lot of previous deals that actually we keep a one to one checkpoint in and we make sure they're supported, they have the information they need. If there's any challenges or difficulties, they feel comfortable that they've got that relationship with me, that they can bring that to me. And I always hope that in our teams and in our meetings we actually have very supportive team members. And I hope people feel comfortable that they can ask questions if they don't understand or if not ask someone behind the scenes and make sure they get the answers to what they want to. There's lots of deals where we do create opportunities for people that haven't had a chance to do it before. And I think just making sure we're aware of that and giving them the support they need as they move through is that pays dividends.
In the end, going back to the kickoff outline, we probably need to add a sidebar note where you reference sending out the written version ahead of time, which makes a lot of sense because people learn in different ways. So if you can give them the pre read and we obviously know that leads to to a more efficient meeting. And then throughout this employee experience, you described a joint onboarding pack using the same themes basically and saying, hey, this is what we're sending out to do, the vision, the goals and whatnot. And then you're sending this out and it seems like a simpler approach. We're sending it out so that you have a written thing and you maybe have a meeting around it as well. It sounds like a good approach, it's like really solidifying it. But also that joint onboarding pack, is there anything around that may be good to just note or think through of what that should look like or include?
Yeah, I think we probably have that as a more comprehensive patch on some of our smaller deals where it's more assets that we're bringing in that tends to be focused around the assets. It gives more detail around the specific processes we use. So there'll be various cross functional work streams that need to be managed and really the processes around those, the tools that we might be using, any particular templates for activity that we're using would have more of that detail. Where we're talking about things where we have a much bigger project, where we have maybe a much longer term collaboration, I think we'd even go to the extent of adding things in such as what's a great hotel to stay at near my partner. So we even go down to that level of detail. We want to make it as easy for people to interact as possible. So we have even more information there. Sometimes we have examples of how decisions are made so we have that flow of information and the gatekeeper in there. If it's particularly big project and you've got a lot of decision making to be done that can be really useful for people. You also can have sort of charters for each individual sort of project grouping. So that's obvious as well. It's always a balance between providing sufficient information and not too much that people are not going to read it. So it depends on the complexity of the project, it depends on the longevity of the project, the scale of the project, trying to give a good flavour and a good level of detail. It's not just a welcome in an introduction packet is also a little bit of a reference sheet as well. It helps people, they don't quite know how to do something. It's actually it's a book they can consult to say this is how I should be doing it and if I'm not quite sure who do I follow up. So making sure that the key contacts are written down in each section as well I think is really useful.
I like the decision making part because that would seemingly be the biggest bottleneck. People waiting to make decisions, especially integration. You have so many to make.
Absolutely. And I think your escalation path as well because things won't always go right. It's nice to talk about the successes. There's always going to be challenges and there's always going to be differences of opinion. And actually we want people to know what's the recommended way that we should be dealing with those. And also people need to know it's okay to have differences. And what we need to do is jointly resolve what the difference differences and work out how we're going to move forward. So giving people some guidance on how to do that.
This is cool stuff and I really want to understand this. What would be an example of both, like here's example of how do you explain decisions being made and then that path to escalation?
Essentially you may have decisions that need to be made as you go along and it's really where do you take that decision to what information is needed? Where is the decision making body? What information needs to be provided? Is there a particular time that body meets to make a decision? Can you just send sort of your pack in for decision making? How do you engage with that body to get a specific decision made? What decisions go to who basically exactly the escalation point. In some ways that can be similar, but actually that's more about issue resolution and it's usually issue resolution versus your contract. So that can actually be a different path. Frequently it's people asking for clarity on the contract and what's the scope and that kind of thing. And occasionally it's gray areas that are not covered in the contract. So you need to actually come to a way to do that. And I think there where you're actually you need a more formal process for escalation because obviously you want to document that and you need to be abiding by the terms of the contract. Again, it's helpful to have that set out and is there a set way that you'd like that to process? The first point is have you spoken to your other party? Have you actually picked up the phone and not just had a torrid exchange of emails? Have you actually talked through what the issue issues are. And then we often try to help people to actually talk through those issues by saying, if this is a decision that you don't feel you can make and it needs to be escalated through the system, can you set out what is each party's position, why do they think that way? And then what are the other options that you've explored and how you can do that? And what are the risks and what are the benefits for each side? Because ultimately what you want to do is find a resolution that is optimal, optimal for both parties. There's always going to be some where it's not quite equal, but actually what we want to do is take the decision for the best overall outcome for the project itself. Helping people to actually put that down in a template. So when it goes to the sort of decision maker at the next level up in the escalation process is really helpful for that decision maker. But it also flushes out and helps people focus and have those conversations in order to fill out the template. In the process of actually trying to write the escalation document, document, it can help you explore more options and more ways to resolve things. So it can be helpful to have that escalation process set out so people can actually have a mechanism that can help them resolve at the same time as starting the process, trying to think.
Of all the things that will go wrong. The first one, I'm just thinking of a dispute and two people breaking down to a fight. Have you dealt with stuff like that where disputes have come up or. Let's talk about disputes first. I'm also thinking about just stakeholder alignment with the whole thing where, like, everybody agrees to something, then nobody gets anything done. Obviously you don't agree with this, you're not getting things done. But the disputes part, do you come across that?
Yeah, I think in any hostel management situation, there's going to be differences in views about how things are done. And that can come from a number of things. So there might be a different interpretation of the contract, there may be a different interpretation of legislation. I've seen that quite a lot. You have one partner that has a different risk tolerance to another. That can cause difficulties. Where you're interpreting law, there can be a very conservative interpretation of that law versus a less conservative interpretation. So what each side believes is permissible is then quite different. So it's actually how you overcome that and looking at different options for how you might reach the same destination. So I think there's always a lot of disputes and the aim is to Make? Well, there's a lot of issues, I should say, and the aim is to stop those becoming disputes. And the best way to do that is really exploring why people have taken the position or drawn the conclusions they have versus what should be done. And if you can understand that, I think that helps you understand what are the particular points you're trying to meet. Is it a matter of comfort about what is allowable and what's not? And if that's the case, do either side have precedent that backs up their position? Have they got experience of where actually this has been an issue? Or have they got experience where actually we've carried out this process a number of times and this hasn't been an issue. So we believe it's permissible. We've not been caught up on it. It's helping to understand what has caused the difference of opinion, why there's a difference of opinion and what's the driver for that. And actually, if you can look at those and find that, then you can start to think about ways you can overcome that. So the objective is always to problem solve in a collaborative way. So that we're actually trying to work out how do we jointly solve this problem? We think this is one way to do it. So actually, what are the other ways we can do it? And what does that mean for each company? And what risk does that put us under, what costs that put us under, how does that impact our time frames? And actually jointly talking about that is the best practice way that we believe to come to a solution. That was a very long winded way of actually saying, yes, I see this a lot.
This might be an M and a science record. We got a second framework here emerging on Emma's approach to dispute resolution. I got the first figure out the why there's a reason why people think the way they do about something. And you dick into that first, then you get into what, which is basically like what's driving the difference of views here. And then you get super objective about resolving it.
I think that's a good summary. Absolutely. It's not as easy as I present it, obviously, because sometimes issues can be really emotive for people. They've had a bad experience or they believe passionately in something. And again, it can be difficult, difficult conversations. But I think if you can try and make it objective, if you try and problem solve these issues, then you end up in a better place with both parties invested in the outcome. Not always appropriate. Sometimes contractually, you have one party that is the overall decision maker and one party that isn't so it all comes down to sort of where your governance is and where your decision making sits. But I think it always works better if actually bring people along with you and you can make those decisions and have reasoning, you've worked through any issues and problems that arise.
The topic I had in mind was when you have the stakeholders that say they're going to do stuff, they don't do stuff. That situation, how do you handle that?
Stakeholder management again just help influence really and provide the information that's required to back up recommendations essentially and make sure that we provide the full picture behind a position. It can be tempting to present a one sided version, but again trying to keep objectivity and understanding why others have a different viewpoint to yourself, it comes into that influencing on what we might do. What are the recommendations to actually try?
The yes people, they just say yes to everything and then you don't get stuff done. So there's alignment thing which I feel like the dispute approach is similar to that. But then this one I had, I'm thinking a lot of projects of mind actually where this has actually happened. I don't know does that come up or are you working in just such a high accountable environment where you don't have to worry about that?
I'm struggling to think of an example where I've experienced that. I'm sure it comes up. I think that's probably when I haven't seen so much to be honest. Maybe I'm just fortunate we don't have.
To deal with this. The one thing that was interesting, a part of the kickoff play was understanding culture. So how do you communicate culture of your organization?
Describing a little bit how decisions are made and how the organization is set up. And I think that kind of plays a lot into the culture. You can probably see the influences at the strategy for the organization, how we describe ourselves that sort of sets the tone for our culture, how we like to see ourselves. But actually where decision making is taken, how that's taken, I think again that feeds a lot into the culture and that tends to be the pertinent point. When we talk about culture, quite often between businesses, we're talking about how easily our governance systems fit together and how easy it's going to be to take decisions together when actually we might have two different ways of going through governance in our own organisations or taking decisions in our own organizations. So I think a lot of it is about that internal governance and how you bring it together and then actually what do we need to do? And again it comes Back to the stakeholder updates. What are we going to do to actually meet the needs of the stakeholders and make sure that when we're taking decisions within our joint team that actually that gets communicated in the right way to the right parts of our organization? Or conversely, what are the decision making hurdles that have to be done in both organizations before we're at a point where we can decide in the joint.
Team meeting, the governance and the decisions are made are hand to hand. And then the way you describe yourself was interesting because that makes a lot of sense. Just how you generally talk about the company and then you expanded it with the way you communicate.
Yeah.
What are the common challenges you run across thinking of culture when you integrate companies?
Probably across a lot of layers of the organization. So I think people need to know their individual span and what is, you know, what's doable between the companies. I'm struggling a little to articulate this one.
I do a lot of these interviews and the one theme I've seen is you do an acquisition that's further away from your core, it just gets exponentially harder to integrate. I'm thinking of this from the people side. Like the further away your culture is away, it just exponentially gets harder to integrate. Yeah, because that a true thing. I just, my hypothesis I made up.
Right now that probably is true. I think it's the adjustment and I think it's helping people understand the fit the processes. It is also how do you fit into that governance? How are decisions made within that organization and what's my personal level of decision making power within that organization? Culturally you'll be used to as an individual, the decision making processes, the amount of empowerment you have individually to make those decisions. I think as you bring people in, you're coming into a different culture that has a different making, a different decision making process. And actually how does that work when you as an individual come in there, it's that clarity. Roles, responsibilities, the boundaries where the decisions are taken and helping to ensure that that's fairly clear on the onboarding as people come into the organization?
Yeah, you talked about it in my head, I was thinking about influence too. How are you sort of nurturing that between the companies? Because that is a big element of the culture and how you integrate it. You have no influence here at all. It's just too what you're told.
I hope we never say that to people.
So out of all of this, what's the hardest thing about communication for an.
Organization such as hours that's large. It's getting to the Correct people in the most timely way, making sure that you've got that correct reach, that you're communicating at the right time and that's being done consistently. And usually I think that's because you're reliant on a team of people for communication, not just one individual doing that communication. Consistent communication is key and that can be tricky if that's being disseminated second, third hand in order to get that. It's actually the frequent and consistent communication that helps make sure that we're giving a consistent message.
I agree this makes a lot of sense. That's the hard part in just any business. Emma, what's the craziest thing you've seen in M and A?
Trying to do kickoffs during a pandemic? A face to face meeting with no face to face has been a challenge. I think we've seen lots coming out of that. We've seen timelines with authorities that have just been unpredictable, which has made things very challenging. One of my biggest lessons learned was in a project as partners. We were talking together, we both called certain activities the same terminology. We called our teams by a very similar name. So the assumption that we'd made on both sides of the partnership was that we were talking about identical things because they were called the same things. And I think the learning, for me that came very quickly. We couldn't work out why we were not agreeing on a particular issue. There was a penny drop moment as someone said something that suddenly clarified that we were completely talking it cross purposes from each other. And the assumption that we'd all made in the room was because things had been called the same, they were the same in the two organisations. To me that was quite mind blowing that actually we just made that assumption before actually having doing what we preach all the time, which is understand each other, understand the processes. And that's probably why I'm an advocate for trying to understand those processes and each other because that was a lesson hard learned.
That was a pretty crazy moment but this has been great. I know you got crazier stories so I'm gonna have to make a point when I get out to the uk.
Maybe they're for aufair.
Invite you out for some gin and tonic.
Sounds fabulous.
It'll be off mic, no record. Chatham House rules what we do in our round tables. Hey Emma, thanks so much. I appreciate you taking the time. I learned so much.
Absolute pleasure, thank you for opportunity.
Here's to the deal. Thank you for taking the time to explore the world of M and A with our podcast we love hearing feedback. Tag us on a LinkedIn post. Add a review on Apple Podcasts. We'd love to hear from you. If you need help standing up an M and a function or optimizing one that you already have, we're here to help. And if we can't help you, we probably know someone that can. You can reach out to me by email Kisan K I S o n a science.com or you can text me directly at 312-857-3711. If you just want to keep learning at your own pace, visit mascience.com for a lot more content and resources. That's where you can also subscribe to our newsletter. Again, that's mascience.com here's to the deal. Views and opinions expressed on MNA 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.




