How to Build and Grow an IMO Function

When to start an IMO Function

Companies that expect to do more than a couple of deals a year need an IMO to be continuously improving processes around M&A to de-risk enough deals that you get your value for having someone dedicated to doing it.

It's better to start sooner rather than later once you know that's part of your strategy to get someone in place to start the practice, share expectations, and build thinking around what an IMO should look like for that particular company.

"If you want to de-risk new deals, it behooves you to have someone in seat, on the team who understands the overall business, has relationships with key functional leaders, and can help connect all the dots." - Joshua Zatkin-Steres.

It's important they see what's coming down the pipeline, understand the overall business strategy, and can help connect all the dots. 

An ounce of prevention is worth a pound of cure. If you have all that thinking up front, you have alignment early in the deal process. 

On the back end, you're much more likely to hit your strategic rationale on the execution side. You're much less likely to disrupt the existing business or the business you're acquiring and achieve those synergy targets that we all like to think are accessible. 

Key Responsibilities of an IMO

Go-to-market integration. I think about performance metrics set for the deal and for individuals' participation in the deal. Sometimes a lot of that can be unspoken, or if it's understood, it's only part of the leadership team or part of the overall business. 

Communicating the strategic rationale to everyone who's involved in the process. The more that you can communicate the core philosophies and objectives of the overall project to the people who have to make day-to-day execution-level decisions, the more equipped they're going to be successful. 

Setting clear expectations with the acquired leadership about what their future role will be, what their possibilities are for advancement in the organization, and how their teams will be affected.

Now, all that stuff may happen on its own without a dedicated integration leader. But an integration leader should be the person thinking about these problems every single day. They nudge people in the right direction, grabbing someone in a hallway conversation over a quick chat to ensure everyone is on the same page about the importance of these things, which individually may not make the difference, but in aggregate or critical.

Setting more realistic expectations. By having an IMO, which brings all the right voices to a conversation in diligence and in planning, you get more clarity around what is achievable and when, and you can de-risk things that might obstruct value creation. 

So it's both setting targets that are more achievable and more correct. Orienting on maybe what the strategy should be if the original hypothesis is not correct. And then pulling obstacles out of the way so that you get to where you think you're going. 

(Who I report to) depends on the seniority of the person in that seat and the company's size. So for a larger company, your head of Corp Dev will probably be more senior, and the head of the integration team to report to them as well.

Integration hires versus the deal side hires

It goes to what you are trying to do with your pipeline. If you feel like you need more leverage on the deal side of the team, you're going to want to bring another analyst in as the incremental hire. 

But if you want to build a function that will improve over time, there's a solid rationale to bring on at least one integration leader starting the IMO office. 

Every time I've come into an organization that didn't have an IMO before, there have been closed deals that had issues post-close, but every deal has issues post-closing. 

Most likely, they would've been mitigated if there had been an IMO on the front end. 

Building the IMO 

Tools and templates are always helpful. Because we're talking about understanding the business, understanding the strategy, and having a voice in those conversations is critical to the value that IMO can and should bring. 

Bringing someone on board, in-house or from outside the company, is right. If you're going to get from someone from the outside, ideally, it is somebody with an M&A background. So they can start to share some of this institutional knowledge that you just don't have organically.

I wouldn't just bring in an outside company to drop a bundle of tools, I would make sure there's someone who's going to own this going forward. That's the benefit of starting to understand the process so you can improve on it and relationships so you can grow them.

Much of it is learning through doing, which is how I did it. I'll plug some of the materials that you guys put out. To give you some high-level places to dig deeper or provoke thoughts.

I would strongly encourage folks to connect with people. To me, experience is the greatest teacher, so I also benefit from other people's experiences.

Before asking someone else exactly how they're doing, what they're doing, and what they find to be successful or problematic, I would try to understand the context in which they're operating.

• What kind of company is it? 
• What is their leadership structure?
• What kind of deals are they doing? 
• How experienced are their functional leaders?
• How close are those relationships? 

Because without that context, all the lessons may not be directly applicable. But if you have the context, you can target, interpret, and translate the input to your situation.

The steps of standing up the function

Understanding the people

This is foundational for any leadership role, talking to everyone on the team, and people adjacent across the way. I tend to go pretty broad. 

From an IMO perspective, I set a goal to understand the organization better than anyone else at the company. I will talk to every leader in every function, because every function's potentially implicated in M&A to some degree. Understanding their perspective on their scope, who their key leaders may be for M&A, and their expectations for their participation in M&A gets you off to a running start.

Honestly, you can get a lot of goodwill from those teams who, maybe on prior deals were left out or left behind or felt like their input wasn't listened to. Now, I'm coming to them from an attitude of wanting to learn, wanting to engage, and it pays off.

So building relationships is key. I tend to spend the first three to six months heavily focused on that alongside either working on deals, to the extent that there are active deals, or more focused on 

Building playbooks

If an existing Corp dev playbook exists, review it and build it out for the integration side. If there are not, help the deal team put something together. We can do a workshop, take a road show around the company, and build relationships.

I like to have functional-level playbooks. Playbooks for finance, or even within that accounting, FP&A treasury, playbooks for IT, for HR that should contain:

• What their role is 
• Who on their team should be involved 
• What are the expectations from each people involved
• What they should be working on 
• How to approach integrations 
• What are the critical dependencies of their workstream

Getting those embedded into a functional level playbook across what I'll call the core teams are super helpful. Because now, the next time you do a deal, the idea is you share those across all different functions as well. So you set those expectations for the whole team.

Everyone now gets a better understanding of what their counterparts are doing and what their counterparts are expecting from them, and I find that it really smooths things out . 

Pre-planning 

I do have a checklist for me, which is all the possible things that may come up that I either should be aware of or participate in, but that's for me. I don't have a checklist because there isn't necessarily a checklist.

I do have a certain set of slides that I want to make sure I at least consider putting in the deck for approval. And make sure that I'm aligned with the management team on what they expect to see at that step. I do find that having that kind of level of detail is helpful. 

I like to align everyone to an integrated approach at a very high level. I'll have examples of what that looks like, but because deal to deal is typically very different, investing up front in a template or standard example is not necessarily worth the time. 

Unless you're doing a dozen plus deals a year, and you can segment them and categorize them into buckets for which you have different plays, that's a certain level of maturity most places are not reaching when they're just standing up their IMO. 

I do have a template M&A milestone plan that just has most of the things I would expect to see based on the company I work for. But I build that, customize that, and take input over time with my functional leads at that company. And we collaborate on it together to arrive at something that's pretty custom, pretty tailored for our particular setup.

It can be helpful to get tools and templates from a third party when you're standing things up, but always look at them critically and think about how much of this does apply to my case or my team's case.

Integration Charter

The larger your teams are and the larger the deal is, you get more bang for your buck on an integration charter. 

Who's on the team. What's the goal of that particular team? I do it by workstream if I'm going to do it. What high-level outcomes are the team expected to accomplish and by when?

Preserving the deal rationale 

There are advantages in having a kickoff discussion with your workstream leaders, their managers, and critical team members from their organizations.

I set the expectation with all of them to hold a kickoff, similarly for their broader teams. And I always offer to be on those calls to ensure they feel like they benefit from having someone there to repeat the key strategy information or walk through expectations. 

If they haven't done deals before especially, I'm happy to be there or all will encourage them to include me. 

Kickoff Call Outline

• Confidential expectations upfront
• Background on the target
• The strategy for the deal
• Why we're doing the deal
• All the basics around their location, their product, the basic finances, and our objective coming from the strategy
• What would we do with our product or what adjacencies is open up for us
• What is the overall timeline for integration? 

Typically I would do this in concert with the deal team. And so, they'd first talk about the timeline for diligence. And once we talked through those expectations for diligence expected outcomes, in terms of findings, I'd talk about the timeline for integration, going into hypotheses, and what we want to test as part of diligence. 

From there, just really clear expectations around what are the templates they're going to be filling out, what are the due dates for their homework  and making sure they understand how we're going to engage with the target in terms of getting information out the data room. 

What are questions not necessarily answered by what's provided in the data room? Ultimately, I do like to explain how the information they're providing will be used. 

Governance

For smaller companies, which is to say are serial acquirers that are still doing a couple a year that aren't doing lots of billion-dollar deals. Typically, it's the management team or some subset of it that ends up being at the top of that governance structure. 

I like to set the expectation that a management steering committee meets on some regular cadence or only as needed. The model that's worked for me in the past is the deal lead is running a weekly diligence-focused conversation pre-close.

Then we'll hand off into a weekly integration-focused conversation that I lead with the functional or workstream leaders driving each of those processes, typically the same population, very similar from diligence to integration. 

And then the cadence for integration starts to decrease as people finish their milestones, as we get out of the first 30 - 90 days. And eventually, going mostly offline or completely offline for long tail integration items. 

That provides enough visibility for my partners to escalate risk or issues as they arise or address them with those quick calls.

Decision Making

Understanding that yes, there are the reporting relationships we have in our HR management system. And we know who is technically a supervisor to whom, but having conversations with the individuals involved to understand who's the technical expert in a particular area, and who has political capital over a particular project or decision. That's granular tactile information you can't buy. 

So for me, who gets to make the decision or how the decision gets made is informed by that understanding.

For me, just knowing the people involved, their personalities and their perspectives, and their priorities is one of the things I make sure to ask when I'm getting to know them. Stay up to date as we continue to build that relationship; that's how I help enable decision-making.

One of the things that most surprised me about being in this role early on even from a much more junior place in my career was how often it felt like I, as the integration lead was really influencing or guiding that answer to that question, how a decision gets made.

Often, it was just a matter of exercising business judgment based on an understanding of the deal and the overall strategy and goals for the company. 

People allocation

When I'm talking to the function lead in that first instance, building relationships, I understand who on our teams is theoretically available for M&A. Is anyone assigned?

So I have a sense of what percentage of their week is there a time I could draw on? Or is it even possible to pull them away full-time to work on a project?

Do they have backfill available? And if not, then I start offering potential alternatives, exploring whether those are realistic to bring on consulting support, to help with performing day-to-day operational duties so we could free up one or two people to dive in on diligence and planning.

If that's not possible, we bring in someone from outside to help with the diligence and integration planning, which is not my preference. But that's a conversation I like to have with the leaders involved, my partners, to ensure they're comfortable and we're all marching in the same direction. It's not going to be workable typically to impose a solution on anyone without consulting them first. 

Working with Corp Dev

Thankfully, the rationale for having an IMO is typically been made by the time that they're looking for someone so I don't often have to sell the big picture. But there are places where I do reinforce some of the values.

One is always making sure the IMO is involved pre-LOI to understand the pipeline. I make sure I negotiate if it isn't already understood. I'll even have that conversation in interviews just to ensure that is at least open to that being the working mode. In terms of participation in diligence, making sure there's alignment there.

Putting a bee in people's ears is a tactic I use for all kinds of things. But talking through in the context of challenges that your company is facing, how they might be alleviated by changing the process to give you more visibility, if that's what you need, or to have a venue for decision making, where in your input is naturally appropriate.

That creates a low pressure that draws you into the process to participate because you need input to prepare those things. So if they're expecting to see specific outputs from you then naturally, you have an obligation then to ask for whatever it is you need to prepare a realistic or accurate set of assumptions to generate those materials.

And similarly, if you're looking at approval to sign, refining those things and having some kind of summary integration plan is natural, a view on what the org structure is. That's something I like to bring into the conversation early so that you can have a point of view that you're actually testing in diligence as opposed to expecting it to somehow arise out of conversations without having a starting point, a frame of reference that everyone's looking at on the same page. 

From PMO to IMO

Transitioning a PMO to also owning IMO responsibilities or having a person on that team or becoming an IMO overall question is just from a starting point. What is the IMO's capability set like today or a particular person's skill set today? Do they understand how the company's operations connect?

Part of the benefit the value that the IMO function provides is looking critically at the business case and contributing to it either by asking insightful questions or asking to test certain assumptions and hypotheses, asking for the data, and questioning the data that justifies the financial model.

For example, most PMOs may not be doing that today. And if that's not the case, then that's an opportunity for coaching growth and development, but also potentially outside support to assist in that process. There's a need for political capital and I'll call institutional respect to influence leadership and guide the overall team.

If the PMO function to date has mostly the tactical role of making sure that people are executing, agreeing to particular milestones, and then executing on those milestones on a cadence, they're also going to need this ability to whisper in the ears of the people who make decisions at the company and coach and lead without authority. 

Integration productivity hacks

Leveraging your partners. If I'm doing the work of multiple functional teams or sitting in the seat of multiple other people on a particular deal, then I'm probably failing at my job.

Part of the role is to ensure you have the right people in every area to cover those areas. If there aren't the right teams engaged and now I have to reach in and start operating the levers of that team myself, then there's a problem needs to be addressed. 

Also, upfront communication and a clear set of expectations help with all of that. I have an automatic task manager, so when I set myself reminders to do things, I can set priority, and if they don't get done, if they're a lower priority, they'll automatically get rescheduled for a later time.

So I spend much less time managing my personal tasks and agenda for work around meetings than I used to from using that kind of tool, that's been a little bit of help. 

Managing Delays

Step one is a conversation with the leader of that team to understand why. My first impulse is often to see how I can help. Is it pulling in other team members if that's what's needed.

Is there a misunderstanding of what the task is and that's why they're behind or what their focus should be? Can I help them reprioritize? And last line of resistance is for me to jump in and help myself. But again, that should be the worst case. 

‍