Architecting Communications for Successful Integration

‍Areas to focus on during integration

You need to make sure that you communicate as well as possible. It often gets missed because there are 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. 

You need to keep those communications with your internal teams well and ensure everyone has the latest information as you move through those. 

Also, speaking to the target company you're working with is crucial. They are your partners, and you need to have structured communication with them so you know where your touchpoints are, who you can contact when you have questions, and make sure that information is cascading correctly across the organization.

I's also vital that it's well documented and that it's clear that you have regular touch points in various forms of communication built into the plan.

Building relationships

Building relationships is key. If you communicate with clarity, then that's going to help you to build trust. You want to form a working partnership with the people that you are working within your integration. 

It's helpful to make those interactions across all the teams happen frequently and in the appropriate form of communication. In this day of electronics, it's very easy to rely on an email because it's quick and easy. But we should be reaching out and having much more meaningful interactions with our partners and team members.

We all say face-to-face is the gold standard when you want to get to know someone and build trust. That's not always possible, but we have all these lovely formats like zoom calls. So it's much easier to build those relationships even at a distance. 

Key People to Build Relationships With

My role is to coordinate across functions and the various departments within our organization and ensure that we provide aligned messages and move integration forward. 

Internally from my perspective, relationships involves close contact with a representative from each of the key functions depending on what we're integrating and that can come at different stages and different places into our organization.

So, for example, we have the head of M&A of IT. That team's role is to support all the information technology aspects of moving assets in be that company level, product level, or somewhere in between. 

The stakeholders then tend to be either our project sponsors, the people we're delivering for, or also the stakeholders to manage are those heads of departments that you mentioned, but that's where we use our technical leads and use their expertise to influence their stakeholders.

So we tend to have quite a large stakeholder pool and a diverse group of individuals tasked with managing the integration. 

Alignment on Communication

It depends on the need of the project. The frequency of updates tends to vary because you always go through periods of intense activity where things are moving very quickly, and there's probably a need to update stakeholders and teams in communicating much more frequently.

Then as you go through to a steady state, you tend to get to a regular cadence of those updates. And, 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 more tailoring and checking in with the teams to make sure that 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, 

Getting Feedback

I like to ask for it face to face and see what happens, but if you're managing very big teams, some tools and platforms can help you, like the big surveys. It all comes down to what's appropriate at that time. 

Of course face to face is better, but surveys can help you identify patterns if certain areas are not performing as well. The danger of talking to one or two people is that it tends to get personal rather than a general trend.

Surveys can be a powerful tool that can help you flush out the challenges and uncover things that are not so obvious by asking.

When do you start thinking about communication? 

As early as possible, We tend to work very closely with the actual deal team and the transactors. And as we are doing that communication, it's obviously thought about throughout.

• How is that going to be messaged?
• How do you, most efficiently, get to the people who need to know what's taking place? 
• What does that deal mean for them? 
• 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 while the transaction is taking place.

And then of course, you need to make sure that you are following through on those plans and those communications continue. So I think very quickly, we are thinking about setting up the teams we need to execute on some of these decisions. 

And part of the kickoff meeting we hold with those teams is really to engage ways of working to make sure that we are thinking about:

• How we're going to be engaging
• How frequently we'd like to speak to each other
• How frequently we need to update stakeholders
• 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 team structure.

So it's ensuring you understand the other company's touch points. And you are bringing the right individuals together at the right time points. So that communication is optimized and you keep that going. 

One of the things we do in the key account meeting is really to try and set out those rules of engagement:

• How frequently we expect to meet. 
• What the content and the purpose of those meetings are likely to be? 

Kickoff Meeting

There's an element of understanding the deal. In our organization, the people supporting the transaction are not the same people supporting the post deal management in the integration and the movement of the assets. 

So it's helping them understand the vision for the deal. What is the purpose, and why is it important to the organization and to the other partner company. 

We also need to understand a little bit about our partner in terms of:

• Who are they?
• What's their size?
• Where are their focuses? 
• What are their priorities?

Because there are all sorts of layers within an organization, and the chances are at every layer of that organization, there'll be different priorities, strategic pressures, and appetites to risk or challenge.

And that feeds into the culture. So actually trying to understand a little bit about each other, start with just in terms of scale, size, setup, and decision-makers. That can help you make sure you are getting the right touch points across that organization.

The communication 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 will be done and timeframes that are going to be progressed to. 

I think the kickoff meeting is all about building relationships, and we want to ensure that there's always a social element built into that because we will be working with our partners for a long time. And 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 make sure that everyone involved in that team is comfortable working with their counterparts.

The most significant risk in any post-deal management situation is the people involved. Often relationships have not been established properly or we don't understand the differences in the drivers for why there are differences between the two organizations.

We need to make sure that people build relationships with their counterparts as quickly and strongly as possible. We must understand each other's constraints and pressures, and challenges.

There are always differences. And you could probably spend two days just talking about those if you wanted to. It's important to have an early heads up of:

• How we work as an organization
• How the other party works as an organization
• What are the key challenges? 
• What do we think the key challenges are likely to be?
• What do we need to think about when we're looking at how we will work together?

We want to make sure that we're documenting those touch points and when will be the next meeting, what the expectation is not just for the people in the room, but actually, the teams that they represent.

Obviously, one size doesn't fit all. Some of the partners we work with they're a very different size from us. So spending all your time in meetings is not going to be a great use of time. So we need to tailor how and the frequency of communication. So we can make sure that actually we are using our time optimally and not creating a pressure through trying to overcommunicate.

If independently we've done our internal kickoff meetings correctly, there shouldn't be many discrepancies. So we always hope that we have a nice, clear contract that it's agreed upon and documented and there aren't any gray areas and areas that are too open for interpretation.

So just starting with the fundamentals and understanding:

• What's in scope? 
• What are we trying to achieve? 
• Do we have any timeframes that we need to meet? 
• Is there anything particularly sensitive to time that we need to be aware of. 

All of these things can influence our plans for actually integrating into the business and how we might or might not do that.

Addressing employee experience

One of the things we do is make sure we give away beforehand a written form of the joint kickoff meeting. It gives a comprehensive view of the key values around the meetings, a joint vision for the team, why is the deal important, and a little bit about the target company and our company. 

It's great if we can have a joint kickoff onboarding deck that we use with anyone joining the team. One of the measures of success is if we are struggling to tell which company each partner works for, and that means they are working together as a team if you can't tell them apart.

Obviously, I can't do that for all the teams, to support all the teams, but indeed my touch points and contacts, 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. 

If there are 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 know.

Pre-reads

It's a more comprehensive pack. Some of our smaller deals tend to be focused around the assets, and 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 the processes around the tools that we use, any particular templates for activity that we use would have more detail. 

On bigger projects where we may have a much longer term collaboration, I think we'd even add things such as great hotels to stay near my partner. We go down to that level of detail. We want to make it as easy for people to interact as possible. 

Sometimes we have examples of how decisions are made. 

• 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?

So we have that flow of information and the gatekeeper in there. If it's particularly a 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 charters for each individual project grouping. So that's obvious as well.

It's always a balance between providing sufficient information and not so 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, and the scale of the project, but trying to give a good flavor and a good level of detail.

So it's not just a welcoming introduction pack. It is also a little bit of a reference sheet as well, and it helps people if they don't quite know how to do something. 

And there are always going to be challenges and differences of opinion. You want people to know that it's okay to have differences. And what we need to do is jointly resolve the difference and work out how we will move forward. So giving people some guidance on how to do that, is really useful as well. 

And in the escalation point, it's more about issue resolution. Frequently, people ask for clarity on the contract and what the scope is and that kind of thing, and it's gray areas that are not covered in the contract. 

So you need a more formal process for escalation. You want to document that you need to be abiding by the terms of the contract.  

• Have you spoken to your other party? 
• Have you talked through what the issues are?
• If this is a decision you don't feel you can make and needs to be escalated through the system, can you set out what each party's position is? 
• Why do they think that way? 
• What are the other options that you've explored? 
• How can you do that and what are the risks and benefits for each side?

Because ultimately, what you want to do is find a resolution that is optimal for both parties. Putting it down in a template helps the decision maker and the next level up in the escalation process, and it also helps keep your focus and have those conversations to fill out the template.

Handling disputes

In any post-deal management situation, there will be differences in views about how things are get done, which can come from a number of things. So there might be a different interpretation of the contract, and there may be a different interpretation of legislation. I've seen that quite a lot. 

On the one hand, you have one partner with a different risk tolerance to another organization. And actually, that can cause difficulties when you are interpreting law, and there can be a very conservative interpretation of that law versus a less conservative interpretation.

And 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 are always a lot of disputes, and the aim is to stop those becoming disputes. 

The best way to do that is to explore why people have taken the position or drawn conclusions versus what should be done. And if you can understand that, I think that helps you understand what the particular points you're trying to meet are.

Is it a matter of comfort about what is allowable and what's not. And if that's the case:

• Do either side have a precedent that backs up their position? 
• Have they got experience of where this has been an issue? 
• Or have they got to experience where we've actually carried out this process several times, and this hasn't been an issue?

So we believe it's permissible, and we've not been called up on it. So 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, if you can look at those and find that, you can start thinking about ways to overcome that.

So the objective is always to problem solve collaboratively. It is not as easy as I present it, because sometimes issues can be really emotive for people, and they've had a bad experience, or they believe passionately in something. 

And again, it can be difficult conversations, but I think if you can try and make it objective, if you try and perhaps problem solve these issues, then you end up in a better place with both parties invested in the outcome.

Communicating Culture

You can see the culture in:

• How decisions are made 
• How the organization is set up.
• The strategy for the organization 
• How we describe ourselves 
• Where decision-making is taken

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. A lot of it is about internal governance and how you bring it together. 

Challenges during Integration

It's helping people understand the fit, the processes, the governance, and what's my personal level of decision-making power within that organization.

As you bring people in, you come into a different culture with a different decision-making process. And how does that work when you as an individual, come in there? I think, again, it's that clarity, roles, responsibilities, the boundaries, where the decisions are taken and helping to ensure that's fairly clear on the onboarding as people come into the organization. 

What's the hardest thing about communication? 

Doing it. For a large organization, it's getting to the correct people in the most timely way. Making sure that you've got that correct reach, that you are communicating at the right time and that's being done consistently.

And that can be tricky if that's being disseminated second to third hand. So I think, probably, to mitigate that, it's actually the frequent and consistent communication that helps ensure that you are giving a consistent message. 

‍