Improving IMO For Efficiency

Ensuring IMO efficiency

Every acquisition is very different. For me, having a very high-performing team that was executing already, the next layer is about:

• How do I get a structure?
• How do I get repeatability? 
• How do I make sure that we can improve as we move forward? 
• What's our definition of done?
• How do we make that something that helps us down the road, so we're not creating the wheel every time? 

We started talking more about playbooks. We're really being more Agile ourselves, using our tools, being able to look at every acquisition and start with some starting point. As we know, every acquisition will have its own nuance and its difference.

• How do we implement that? 
• How do we look at that change?
• How do we make sure that we can maybe see it in the future and handle it later? 

Those are some things that I've worked on with my team over the last year.

The challenge of new technology

Today, we're changing the way that we're looking at our rosters in more of our organizations and what that looks like. That means that I will have to change the playbook that we have. 

We're not normally involved with the day-to-day business as usual from an engineering perspective. But for us, we just heard about this, so it's about getting to know and understanding what's happening and what does that mean for us? 

That means we also have to change and that our playbooks are living documents that will have to adjust to that, and we will have to work with our supporting teams to talk a little bit more about what that's going to look like in the future.

Also, we will have to look at when that will happen. Because that could also impact our timeline for our integrations, for acquisitions that we have, and things that are in flight versus things that may be new and start from the beginning. 

What might happen in the interim if I've already started down a path that will change somewhere between, before we can finish an integration? I need to know what that is and what our plan needs to be going forward.

• Do we let them finish? 
• Do we pause and reset for the new technology? Or do we just wait?

Those are some of the things that we get thrown at as well. Sometimes you can't predict things like security or all the things that will fall out. And though we don't own security, we work closely with our security partners and basically they're leading that, but we're driving to say: 

• Is this done as one of our checklist items from a technology and product perspective?
• Did security get all their vulnerabilities done? 
• Did security get checks and things that they needed to get done?

We want to make sure that those things are also happening and that we are included on the plan and the decision-making that goes with it.

Definition of done

Every acquisition should have the same definition of done. There may be bits and pieces that don't apply. And suppose I could look at every acquisition side by side, check off the ones that are applicable, and be able to say how well or not we're doing and when this will probably happen. In that case, that becomes the timeline of figuring out when to talk to stakeholders, leaders, and the decision-makers.

Then, you can decide; if they can't make this change right now, we will have to alter the product schedule or do some other things according to the ideal world and ideal state. It all comes down to getting everybody aligned and ensuring they're all in the know. 

We produce reports on a monthly basis for all of our active acquisitions that are in integration. And we also produce the report out to our board on a quarterly basis. Those have to be very consistent and we have to have very consistent and the same methodology side by side for each of the acquisitions. 

Again, some things may not be applicable in that definition of done. Those can come into play, and we just say N/A or not applicable. These are the things that we're working on. Maybe you don't need services. Maybe we don't need to do a DNS change. Some of those things may not need to happen. 

Those things automatically come out. We discuss upfront what are the things that are coming up, the milestones and what it looks like, and what's left now to make this done.

Updating the definition of done in the playbooks

We don't want to make it an administrative nightmare, but what we do is, after every integration, we already have checkpoints along the way. But once we're done and we feel like we got the definition of done and we've done what we call a handoff between us and a supporting team that's going to support that going forward, the acquired team and us basically will then look at that and discuss some lessons learned, getting together as a group and talk about:

• What are the ways that we could've done things better
• What things can we innovate?
• Which things do we have to optimize or we just didn't know about?
• What things did we do badly?

From there, we can take that information as our knowledge base. And then, we go back and make those adjustments to our playbooks and publish them. 

So we publish our playbooks to all of our stakeholders internally and our leadership so that at any point in time, they can look at that and know our roles and responsibilities, and who's our driver, who's accountable, who's informed, who's contributing, and give them that opportunity to see it as well and add input.

Instantiation of done

Our handoff means we're no longer doing anything. But in terms of going backwards, let's say we meet with my business technology team who says that they're not really comfortable with the application monitoring piece right now, and think we need to do a couple more things. We may have to go back and fix that. After that is our "lessons learned". 

Actually just having conversations today with some of my leadership, we want to go back and revisit some of the past ones and talk a bit more about how things have been going from a year ago to now and look at things we could improve and what we could've done better. We're going to actually go back again and pull the past acquisitions that we've closed out or completed and get some more information on how they're doing today.

To add to that, you need to consider two soft skills. One is culture and the other is having empathy. When you realize that these are individuals who are now new employees of your company, it will take them a minute to adjust.

Remove their cheese, they're doing something different, they're being told new things they have to do going forward, so working with them and coming up with a combined plan is super important. 

Being able to connect with them, meet with them, and talk about the why's of what we're going to do from an integration perspective. Get their feedback because maybe they do something better. Get input and so that is a team effort. Be more empathetic and think about how that fits within their culture and how that will fit with ours.

In terms of being able to work with the acquired team and their technology teams, we could be a little egotistical because when we are really good at technology, you would think that everything you do is great. Sometimes you have to be open to look at innovation and how things are being done differently. 

When you acquire a team, just be a little human and empathize. We do have a job to do, but let's do it together. 

Transitioning from RACI to DACI

More recently, we had a healthy debate about RACI versus DACI. Again, because of the seat that we're in, we work with a lot of our M&A partner teams. So whether that's legal or employer services, or our HR, supplier, or procurement area, or security—all of those areas that we don't own, but we need to drive and have those things done.

Employer services are doing cultural surveys, so we ensure that we understand where they're coming from, where they're at, and what they're feeling.

Whether that is a supplier team or procurement team, we make sure their suppliers become our suppliers and or adjust to whatever supplier that we have for that services licensing or what have you. 

Whether that's security and then doing their part. So that's why the D became more important to us, because we're driving it, and we're not really responsible for it. So they still have their job to do. They're still an M&A team associated with that integration. But for us, we're the ones that are reporting.  

We're the ones that are responsible for putting it all together and saying we're done and handing that off. So that's why we went down the DACI path. But there was a very healthy debate along the lines and some of it was just about terminology, what people know, and understand what that looks like. 

In every one of our playbooks, we have a DACI for each area, and we talk about who's responsible, who the players are, what the outcomes are, and the steps to get to being done for a certain piece of work. 

What makes our playbooks great is we have that, and I can hand that to any executive and let them know how we see things. Some of them are easy. Some of it can be hard, depending on the maturity of the acquired company. But for the most part, we have those down and work with them. We keep close ties with them and work through our checklist or our definition of done.

So far, it's been great and that we are maturing, depending on the size of the acquisition and the complications that go with it. Those things are what we're perfecting and trying to get better at. 

The timelines are important. We could be from 9 months for something that's small or tuck-in type or 2-3 years based on some of the larger acquisitions. That also helps determine what this looks like and allows us to show the acquiring company what the scope of work looks like, who's responsible, and how we will work together. Then we go from there.

We then come back and do the "lessons learned" and compare how we started versus how we ended and what changed in between.

Governing changes on playbook updates

I don't want to have an administrative nightmare. I want them to focus on integration so we need to keep track of it as we are providing status. We have monthly updates so all our data is in one place. 

Having that, we can go back and see what happened along the way and at least have that historical record. We also have to go back at the end and have those "lessons learned" because I don't want them to get into that cycle of asking for status and updating playbooks. I want them to focus and think more about it. 

But then we work with our partners who may need to be informed, who are contributing, and who are potentially responsible. And we work with them to assess if this initiative is solid and if it makes sense. We actually have sessions with them, and we walk through the documents. It becomes collaborative. We share our ideas with them our documents, they can write and add comments on their part. 

The playbooks were like in-flight over the last couple of years and people had bits and pieces that they added to it. But over the last year, we really solidified and published. But we work on it with our partners for them to contribute. It's an open doc for all internal partners and we share also to someone we may have worked with in an acquisition and give them an opportunity to see and look at it as well.

We own it, we publish it, but we make it collaborative with all those that we work with so that it is not just a view from M&A integration, but whether that's Corp Dev, security, and any of the other teams that we work with, and they contribute as well. So that becomes our cycle of collaborative improvements, making the next version, and publishing that again. But it's always a living document that they can all get to at any time.

Taking things out of the playbook

Two things come to my mind: one is the fact that if they laid out this whole playbook, like our whole definition of "done", and all those things, that can be very overwhelming for a new acquisition. 

The other piece is that, typically, when you have an acquisition, let's say you probably have a few people that do this tech job, or you may have multiple salesforce teams vying for their time. Then, we need to be able to think through that in terms of how we impact and hit them. 

So second is showing them what that looks like and trying to talk through what that means for them. It all comes down to talking back to our "why". We can start with why we need to do these things? Then maybe there are certain things we don't have to worry about or do, or if it's something they're already doing, so then we can pull that out.

So that we won't get caught up in the process, let's be logical about things and look at what we shouldn't be doing. That also points back to my example of timing. If you've got an acquired company that has commitments to their customers, you have to think about that too and factor that into not causing change or chaos in the middle of that. 

Unless that product strategy is different, we must make sure that we stick with that and help them get to that place. So we're not going to do that right now, we will pause that and that may not happen until we take that on after integration.

Your supporting team is going to own that going forward, and we'll make sure that we got all the right people that made the decision, call that out as it is, and report it as such, and then we decide whether we do that piece or not so we can pull that out. So that's the way we subtract.

We'll go that route and so there is more decision-making on what's the right thing to do for the business, and then it is just logical about the timing and what happens.

On the dashboard that we report out, there are pieces that we have that are just not applicable. We just pull those out and look side by side on all the limits. If things are not applicable, we just pull those out automatically so that it's not so overwhelming and we don't expect them to do more things.

Some plans are not applicable because it doesn't make sense to you. This means we should have a combined effort on what the plan looks like and what's sensible. We must be logical and sensible.

I'm all about that, and I'm all about brevity. If you can get things done faster, if I can have a meeting faster, and we can quickly get that done, and if you concentrate on your work and on the things that you're good at, I would want to keep you out of meetings. My mindset is, be brief, be bright, and be gone.

I just want to make things happen. The faster you do it, the faster you do integrations, the more money you save. You're better off doing the best you can to speed up most of the stuff, and that's something else that we're working towards. 

As we look at scale, we're also going to look at speed and we're going to try to get things, and we must be able to show some improvement over time and not be stuck in the same thing you've been doing for the last 10 years.

The idea of scale and its challenges

I have a set number of people on my team and a set of things that different people do. For me, one of the things that I thought was a challenge was capacity and the number of deals we might have, the types of deals we may have, the number of people it may take to do some of these things, and how that looks.

One of the first things I did with my team was create our own combined board with limits. So I can say in due diligence:

• How many tuck-ins can I have going at the same time?
• How many adjacencies can I have at the same time? 
• How many new cloud items can I have at the same time?

But be logical with how many people can do due diligence in your team. You can go to Corp Dev and say it's going to be hard for you to scale without staffing up your team. 

It doesn't make sense to have that many people staffed. Let's be focused. If there's an opportunity for me to bring in an incremental, I would rather the incremental be arms and legs–being people who can do more work there. 

But I let my subject matter experts be on the front and then I can talk about how I can scale. If I get to a place where that M&A engine just cranks up and starts moving really fast, that's where I want to be.

I want to be able to scale my team that way versus overworking. We're definitely all about balance. I always want to ensure that my team is taken care of and that we're doing the right thing with the right focus. 

So for me, to scale means more about what does my team look like as we get bigger deals? What does that ebb and flow look like? We basically go back and try to be more realistic around the timeline. If you think about agile and how long it might take, I want to present my team, our limits, our velocity, and what we can get done.

Let's be logical about it. If I can forecast how many acquisitions may be coming our way, and I know I'm not going to get that much time, that would be the happy path if I can get that. I can then stack up as I need to, but I prefer to do it incrementally and make more sense about it so that we can support the business because that's how we grow. Another part of how we grow our business is through acquisition.

Hiring for Integration

I didn't grow up in M&A, but I came to it later. I haven't had a long history of a big four consulting type role. But I'm a studious person, and learning is one of my other superpowers. I'm competitive, and I like to learn. 

Many of the folks on my team have that kind of expertise. And I think when I need that on the front end, that's where I'm going to go. Alternatively, I have been looking at opportunities as I'd love to have my team having a little bit more stagger, a bit more steps of opportunities into M&A.

So people don't get introduced to M&A most of the time. When I was in meetings, I never saw many people that looked like me. For me it's like, why don't we start with some interns, let's do some coordinators, let's do some project coordinator types–and that would give people at least an idea or an opportunity to learn it and understand it earlier on and grow into it. 

I would love to have some opportunity to have people grow into M&A leadership-type roles and educate yourself get to where they need to be. You can drive and get to that place, but it takes some work, especially learning more about valuations, due diligence, etc. 

When you think about an acquisition, the front or backend, whether that's on the due diligence side or the integration side, understand it holistically. That will help you grow. For me, it also well-rounds my team so that we're not all at the very same level. 

We have people whom we give opportunities to grow as leaders as well and that's where I want to take my team to. My future hopes and dreams are to stagger my team a bit more in terms of experience and levels.

But when I need the core lead person who needs to understand it, can drive and help me as well, that's where I'm going to go for the most part. 

Many people don't understand what it takes to integrate an acquisition, so I'm evangelizing as much as possible, internally and externally. If it's a two-person company that you just bought, we still have to go through some of the checks and balances for a two-person team versus a 600 person team. And you still have security. Some of those things may even be worse because you only got two people.

They may be even worse because they do the bill paying and all the bills are on their corporate card or licenses and such. People will think that it should be quick, but you have to tell people that it still takes a little time to do these things. It may be a little bit faster because it's two people, but there are a lot of things when it comes to systems, tools, Cloud or on-prem, or what have you that we need to think through. If you can acquire that technology, make sure it's on your platforms.