Navigating corporate transitions
For the first time in my career, I’m on the receiving end of M&A. It's really different in my current role. I have very little control over what happens. I want to add value. My experience is, and I've been in this chair, "I appreciate your input. I don't really want it." And that's hard for me. I have control issues like a lot of M&A people, and I kind of have to just sit there and go, "What else can I do for you?"
It's humbling, quite honestly, to go from the control position to not being passive because I'm really busy. I don't have control over the outcome. The outcome is being dictated now by the parent, in this case, Broadcom. And I am responsible for helping them execute their integration plan for VMware.
Now, to be clear, I am now part of an asset that's being carved out of VMware. Broadcom has just recently signed it to be acquired by KKR. So, I've gone from being acquired to helping them integrate. But wait, now you're going to spin out this other asset. I've been acquired basically twice in six months.
That makes my head spin. They knew they were going to spin out the end user computing division. They were communicating that, but it was more of a whisper.
But honestly, I think they just didn’t want to overly disrupt the customer base, partner ecosystem, and the employee base quite honestly because they didn’t have a buyer at that time. And as you can imagine, 95% of the work is integrating the primary assets out of VMware and this other asset so then you use a computing division.
The business unit is not insignificant. It's like 1.5 billion in revenue, 4,000 employees. So not insignificant. But that's a lot of moving parts. Big, heavy, moving parts.
On a good day, I convinced myself that all that was intellectually interesting. And as you know, I run a lot. So I think that's what keeps me sane. I've been doing this a long time and this is the hardest I've ever worked.
Every day is different. Every problem is different. Every input is different. Every reaction is different. The level of scrutiny on some things is overwhelming, and the level of just ignoring is overwhelming as well.
Right now the KKR deal has not closed, it was signed several weeks ago, and so we still have a lot of learnings that will be coming our way and a lot of requests. Right now we’re in that phase with regulatory, etc.
There’s only so much you can do and you can call it “it can only be planning.” Everybody knows who does this for a living so you don’t want to trip any regulatory issues.
Aligning the integration leader with the north star
My experience, which I learned at Microsoft—a challenging environment to work in, and I would imagine it hasn't changed much—is that it's imperative a senior member of the integration team, if not the lead or head, be involved as early in the process as possible.
This can be uncomfortable at times because deals are confidential until they're not. Just adding people to those meetings can be uncomfortable both for the target company or companies in the process and for the corporate development team and senior executives.
I was able to charm my way into many very early discussions with companies because, at the end of the day, the integration team is the one that has to create the value from the deal.
The corporate development team acquires value. The integration team generates and creates value. It makes a lot of sense to have someone from the integration team listening to those early conversations, even at the preliminary due diligence, even before you pick the target and sign the deal.
They are the voice of reason, saying whether something will be hard to integrate, how it could be integrated, the ease of integration, and the expected cost in the integration budget. These inputs early on are key to deal success.
How to work as an integration leader
The answer depends on the deal and the personalities involved. There have been many conversations where I've been very active, to the point where I was asked questions about how to operationalize the initiative, assuming a pretty open, comfortable rapport with the target.
For example, at Microsoft, I led the due diligence and integration planning for the Yahoo deal, which ultimately did not come to fruition. It was made very clear to me by the most senior executives that they would handle all the talking in those meetings.
We aimed for no disruptions in the meeting, respecting the potential $30-plus billion valuation, which later increased but did not close. Much of it depends on the working relationship with the deal lead, the business lead, the corporate development lead, etc., and whether they trust you.
A misplaced comment in one of those meetings could quickly jeopardize the deal. It's not a situation for junior team members, although it would be a great experience if they could just observe.
However, you can't always have passive observers—the role requires deciding whether to be passive, listen, and observe or to actively lean in and engage.
The role of an integration lead
Representing the functions involved with integrating the company is part of it. That's how I think about my involvement.
For me, I have a background in finance, so finance is comfortable with me being part of the meetings, representing finance. Many senior HR executives might get nervous with me representing HR, but they want to know my thoughts.
For example, one executive from the other side might spend all day on his phone, not engaged, while others are very engaged or just staring out the window. There's a lot of value in observing body language in those meetings, and over time, I've learned to form opinions based on these observations.
Because I don't know what they're thinking, I can represent many functions. I've never written a line of code in my life, so I wouldn't be the right person for R&D. However, I can handle IT and operations all day long.
Not everyone has been doing this for 40 years, so I'm probably not the prototypical M&A lead that someone would bring into these meetings.
What's important is the relationship from the acquirer, as seen in the call we were just on. How corporate development and integration teams are aligned is crucial. They're not the same team, and they have very different goals, although both aim to create value.
Corporate development is mostly done as soon as the ink on the paper is dry, while the integration team takes it over. You need to have a really solid executive-level presence and relationships. It comes down to relationships and communication.
If you establish trust early in the process, it provides a solid approach and platform to work from. Yes, a lot of people start their M&A integration careers that way, and it’s perfectly fine.
Not everyone was thrown into the deep end of the pool like I was, where I had to figure it out. My first integration, I was a finance guy, and my boss, the executive of the division, said, “Just don't mess it up.” It's like, "Alright, that's helpful."
Building an integration plan
The easy answer is you start with the strategy. Ensure that the integration plan is aligned with the value drivers supporting the strategic rationale.
Start doing this really early in the process. It’s one sheet of paper with a really big font on it. Strategic Rationale or the Deal Value Drivers: Revenue? Yes. No. Geographic Presence? Yes. No. Employee Retention? Yes. No. R&D Milestones? Product? Yes. No.
Here’s something to consider: You only have to get two things right in M&A integration—customer satisfaction and employee satisfaction. Most people might think you’re missing about 800 other things.
When you focus on customer satisfaction, you begin to address questions like whether you have the right field execs, the correct field and territory alignment, the appropriate commission structure to support this new business, and how to inform and engage partners to sell this new product or technology if that's one of the value drivers.
When you focus on employee satisfaction, if you acquire a company and the employees are not happy, nothing else matters. You’ll lose people left and right. You might incent the top 10 or 20 percent with something special, but remember, they're not doing all the work.
There might be leaders that the rest of the team will follow, which is great. However, it quickly becomes problematic when there is a significant disparity in rewards, like one person getting $5 million worth of RSUs and another getting a $100 bonus. Without employee satisfaction, you have little chance of success.
Again, this depends on the deal value drivers. If you’re focusing on an acqui-hire, it’s all about the employees. Retain employees, figure out what it will take to retain them. It’s binary.
Focus on revenue and integration
I mean, it's simple, and I always smirk when I say this because smart people want to complicate things. I've said this before in other podcasts, but you've got to keep it simple as long as possible. Simple is hard, but it will self-complicate over time. This is the theme of all of them: simple, simple, simple, and it will self-complicate.
In your deal, you want to drive the top line. You've got a set of numbers to support the valuation you're going to pay for the company. There are costs associated with it. You want to make sure your pro forma P&L is going to support it.
Your integration plan is whether to integrate the employees and what that looks like, and whether to integrate the technology or leave it all standalone.
And then, as Yogi Berra once said, "When you come to a fork in the road, take it." Because otherwise, it's easy to get paralyzed. You know this deal is a great deal. You do know what to do with it: sell more. Do you bundle it? Do you not bundle it? Do you acquire it and not charge any more for the capability it brings?
Knowing that you're going to combine the technology, you'll bundle them and just sell more of everything in general.
Then you give that to the finance team and say, "Model this way, model it that way, independent SKUs, bundled SKUs, not charging more for the functionality, charging more, offering discounts."
You've got dials you can turn, and that's what the finance team does in the pro forma deal model.
Pre-LOI integration planning
During pre LOI, acquirers are not given the names of the employees, only the roles. They don't want buyers poaching their key employees. But the roles get really overlooked very quickly. Role definition is different.
At a smaller company, sometimes titles are inflated because they're a smaller company. The company wants to woo them over, and you've got somebody doing general ledger entries called a Senior Vice President of Accounting.
I'm kidding, but it's not about titles. You have to get them to describe the roles and be like, "Okay, well, tell me about this person." "Well, they're a one to three year college degree, not an advanced degree. Good, steady contributor, engages." Okay, great.
And then you just kind of go through that with either the functional lead or whoever's involved at that point, early pre-LOI. You've probably got a CFO-level, senior finance person, maybe a product person, and then CEO or President might be that COO maybe.
Yeah, it depends on how they're structured. Right. And a lot of startups nowadays, everybody's got different titles; they're all head of this and head of that and head of everything.
But another thing too, in preliminary due diligence, at least my experience in it, is asking a CEO, "How do you manage your company?" And operationally, "How do you manage your company?" I don't mean how you transact through a system, whether something small like QuickBooks.
"How do you manage your company? How do you figure out whether I need three of these or four of those?" They tend to always go heavy on sales. So the after teams can be salespeople because they're trying to generate a top line. You've got a bunch of engineers.
Out of 20, you've probably got seven or eight salespeople, seven or eight R&D people, and a few administrative people. In some cases, they're wearing multiple hats. The R&D people are doing customer support at night, right?
So the preliminary plan is to translate what they do and how they do it into my company and not create any friction or as little friction as possible. There's always going to be friction.
The other thing that's overlooked is the acquirer. You have to think, "I've got two heads of sales. How do I do that?" And I don't know your head of sales, so that's true. What if the to-be-acquired head of sales is better than your incumbent head of sales?
You know what that decision's like and what the likely outcome is; you're going to lose somebody unless you incent them and say, "Look, this is a good thing and here's what this looks like." It kind of goes back to the customer or employee satisfaction. How am I going to manage this?
It's all about risk, understanding the risk, and their tolerance for risk. I've been in deals where the acquiring team is perfectly comfortable with losing some of their employees because they know who they're going to lose and they might be okay.
I don't have to pip them out. So this is a way to drive A-level set across my organization, and it's a call to the team. Like you better wake up and look around, get your head on a swivel because there's some really good talent out there and we're not going to be shy about acquiring them. I’m a big fan of transparency.
The thing you're trying to do also in that preliminary phase, as part of the integration lead, is justifying the valuation that you're going to put into the LOI. Like, that's not a 25 million dollar company. You can do all this.
It's so funny, I used to have a great working relationship with most of my counterparts at corporate development in Microsoft.
It wasn't a universal truth, but I was like, “it takes you guys like a month to build a valuation. Okay, next deal. I'm going to guess what you guys are going to value, do not tell me what you're thinking early on, and then you guys build your model. Let's see how far off we are.”
It's really not that hard. The work is hard, I get it, and you have to build the valuation model. There's no denying that, absolutely none. But it's not that hard to figure out what the valuation is going to be. I used to joke, which would upset a lot of the corporate development, “let's play this out. Here's my negotiation strategy on what we're going to offer for a company.”
“Buyer: How much do you want?
Seller: I want X.
Buyer: How about X minus five so we can at least say we negotiated.
End of valuation discussion. “
And it’s not that easy. I've been known to create some friction with corporate development for saying things that are usually top of mind for me. But again, you have to build the valuation model, you have to present it to the board, you have to present it to whoever needs to approve it in the company. I know it is hard work.
Part of this was you actually supporting the valuation or putting an opinion around it, because again, as the integration lead, assuming the deal closes, the integration team is the one that has to take those value drivers and create value from them. How do I make one plus one equal three?
And that's why I deserve an opinion on that. Now, to be fair, I don't really care what the valuation is. It doesn't change anything that I do. It doesn't change how I do it. But what I want to know is, what are the valuation drivers that support the strategic rationale that has some implied valuation in it?
M&A due diligence
When I drove a deal, our approach at Microsoft, which I also applied at VMware and PayPal, involved preliminary due diligence. This is really kind of arms-length, not sharing any trade secrets, really confidential stuff, because you're just under NDA at that point.
When you get to the phase between the LOI signing and pre-close, or you're in the pre-close phase and then you get to close, there's confirmatory due diligence.
This is where you address the big issues that could disrupt the valuation, such as toxic executive agreements, contracts or commercial agreements, or escrow agreements—big things that could literally change the valuation of the deal.
Legal has a big part in that, but then there's operational due diligence. Ideally, these are done concurrently, but they're not the same thing. Operational due diligence is really understanding how the company you're about to acquire works:
- How do you develop products?
- How do you sell?
- Who sells to whom?
- How do you manage your employee base?
- How do you compensate them?
- How does finance work?
- What systems run the company?
These are the nitty-gritty operational components of the company because that's really what you're looking to integrate for the most part.
Are we going to integrate or just transfer all the data from their systems to ours and then deprecate all their systems? That's the ideal state and really hard to do. Mapping data fields, and literally I've learned a lot over the last few months about data and its importance.
The good news is it's easier and harder now because almost everything's in the cloud, so you're not moving boxes around.
I literally have worked on deals where you take a terabyte drive, plug it in, download all the data, put it in the back of your car, try not to forget it or have it stolen because it's got about a billion dollars worth of data in it, and plug it into your new system and then upload everything.
Now, it's all in the cloud and you can migrate the data. It's not easy, but you can more simply map the fields and do all that stuff that data engineers and data ops people do. But, it's a much more efficient process than it was 20 years ago.
Employee integration and customer satisfaction
Another pillar to think about is employee integration. Customer satisfaction is also its own pillar.
Early in due diligence, you'll typically map the overlap of the customer base. How many of the same customers do we have? You might also discover customers in new regions where you don't currently have a legal entity, but you're about to acquire that legal entity.
There's a lot of mapping that has to go on and a lot of rationalization of whether we really want to be in that part of the world. What's the real return on that investment? Setting up a legal entity in a country you're not already in has a lot of strings attached to it, and that's really hard work, the whole legal entity thing.
So, you do have to think about what we are going to do with the customer base because that's where the revenue comes from. What do those customer contracts or agreements look like? Are they assignable?
A really simple question that sometimes has the answer of "well, it depends," because there might be some conflict with a customer who has a contract with one of your competitors.
Who has some first right of refusal over changes in control. I mean, it can get really fuzzy pretty quickly. So that's why you do the due diligence.
You have to look at the customer base, customer agreements, the field, the resources, the people doing the actual selling. Do you need two people from two different companies? It'll be one company selling to the same customer.
Connecting diligence with integration planning
Everybody does it differently. There are platforms that will guide you down the garden path of integration planning.
It'd be awesome to be able to ask GPT, for example, "20 million in revenue, global, deal value drivers are the following. What's my integration plan?"
Workflow is really important, and my approach historically has always been to start with a framework, not a checklist, but a framework. Okay. What are we integrating? People? Yes. No. Operations? IT? Yes. No. Employees? Operations? Finance? R&D, you know, you go down through several functions.
It’s knowledge transfer, whether from a document or talking to employees who might not be around long term.
I used to joke—it wasn't really a joke—that I would find out more about a company pre-close from talking to the IT team, the facilities folks, because they know the layout, they get the buzz, they know who's talking about what. They overhear stuff.
The IT team knows these guys just want the latest technology. And well, who are those prima donnas and why do they think they should have such great technology? The non-due diligence happens in a hallway. And there's a huge amount of value. But you've got to build some trust.
People wonder, "Why are you asking me these questions, am I going to be fired?" I'm just trying to understand how this place works. I don’t mean from an executive lens; I mean, how do you do your job? What makes your job easy here? What makes it hard? You'll learn more from those hallway conversations than from anybody else.
So, back to the framework. Having those discussions informs the framework. You take everything out of preliminary due diligence, confirmatory and operational due diligence.
So you build out a framework. It's usually a timeline by quarter, first quarter post-close, second quarter post-close, key functions, and then start focusing on those functions.
Then it starts to get really interesting. Okay, I've got this basically a matrix or a framework.
- What are the interdependencies?
- How much of the top line is generated from the next new release of product X?
- What are the new products in the pipeline?
- When are they going to be generally available and how does that impact the top line?
We've all heard the horror stories of salespeople suggesting they couldn't hit their numbers because they didn't have enough new stuff to sell and R&D people saying, "I don’t have enough runway to meet what they're asking me to do for their customer base. I don't have the resources, I can't do it in six days."
Now, you get into SaaS and subscription business models, which most are nowadays, and you're constantly releasing. Every week you've got a new revision of the technology and you've addressed six new bugs.
The iPhone's a great example. Every time you do an update, they're largely bug fixes, not feature enhancements, because customers want stable technology to run whatever they're running on it.
So as you build that and go from framework to focusing on details, building the timeline, tying the interdependencies together, then you know what to do next. But it all starts with what's my end state. How do I identify what my end state is?
And that's your executive team's vision, like "We want to spend 50 million on this business. What do you want it to look like two years out? Smooth. You never even reference the old company. It’s all blended, all integrated. You've lost all the branding. There's no residual anything hanging out there.
All the employees are like, 'This is pretty cool. I like working with these guys.' That’s the end state." Then you build this model, this integration plan to support that. So it's literally starting with whatever you determine—two years out, three years out, five years out, whatever it is—one year out, and then you start working backwards.
Absolutely, a lot of people do this end state view, but they don't realize they're actually doing it. I've always just been a big proponent of emphasizing the end state in every deal with the deal executive.
- What do you want the end state to look like?
- What do you mean by end state?
- What do you want this thing to look like some number of years out?
Those decisions are an outcome of that definition of the end state. If what I do tomorrow, which I believe is going to be the right thing, is not aligned to the end state, then it's problematic.
For example, if you start in San Francisco aiming for New York but are three degrees off, you end up in Wilmington, North Carolina. It's only three degrees off, but each day you're farther off, leading to a significant deviation over time. This is common in M&A where you suddenly realize, "This is not what we meant to do.”
Approach to team collaboration
When I was at Microsoft, I started out knowing what to do; I just wanted to be left alone to get on with it. However, that approach doesn’t scale. What you are likely referring to is the concept of whiteboarding.
You bring in all the functional leads and key contributors, ideally from both sides, such as FP&A leads, heads of HR, etc.
Back in the day before whiteboards, we used to hang butcher paper around a big conference room and write out the timeline by month or quarter, depending on what was needed. Then, we'd add the rows of workstreams like People, IT, Customer Success, Global Service, and so forth.
Start building out what needs to happen each month. But interestingly, you begin at the right end of the whiteboard and work backwards, although the natural inclination is to go left to right. That’s how we learn to write or type. Even text messaging is left to right.
The concept is to write the story from the finish to the start and then determine the key milestones.
- Where are the interdependencies?
- Where might things break down?
- Where is something likely to trip us up?
We didn’t account for that. The integration budget’s off. We didn't include the target sales force in our sales kickoff. Well, there's a 5 million dollar miss out of the gate. Things like that just become very apparent when you have them up in front of everybody and you can get the holistic view.
Synthesizing is something that just happens naturally for me. It's not about reading what's on the wall; it's about observing and looking around to identify where potential issues might arise. That's where we need to focus our attention.
I've been doing this for a long time, and there are others who possess this capability early in their careers. This approach isn't limited to M&A; it applies to many different functions.
But again, we start at the right and work to the left, a process we call 'walk the wall.' People use Post-it notes to note down items like GL Close, comparing what they do versus what we do, and deciding whose process is better and thus will be kept.
For example, you might put a Post-it note that says 'acquired business GL close process.' This might seem like a strange example, but it's representative of the kinds of considerations we need to make, such as whether the fiscal periods align—are they 13 weeks, 12 weeks, calendar, or fiscal?
Then there are the accounting issues regarding how and when to align these fiscal periods. Will it be done immediately, or will we wait? Who will be responsible for it? This method helps us effectively plan and execute the integration.
The details of integration plan
I'm a big fan of the Big Order Bets, Boulder, Rock, Pebble approach. This is easier to manage with a seasoned set of functional M&A leads, like an M&A lead from finance who has been doing this for a while, say five years, with several deals under their belt. The same goes for people leads in HR.
I let them delve deeper. You just have to align with this; how you want to get there is up to you, which brings us back to the framework approach. I struggle with people who need to follow a checklist because it suggests they are followers rather than problem solvers.
The best M&A integration professionals are problem solvers and critical thinkers, not just going through the motions of what we did at point A, then point A.1, then point A.2. They don't stop at not knowing what point B is but work to figure it out.
It's not about knowing everything but knowing the next step. As long as you know the end state, you have a good idea of what to do next. Not everyone is wired this way, which can sometimes be challenging.
With a solid integration lead and a couple of reasonably seasoned functional leads, you can manage the deal effectively. They can guide those who are new to this, who might say, "I've never done this before."
Complexities of M&A integration planning
A lot of it involves due diligence, then it transitions to less about the diligence and more about engaging with someone at the company. For instance, you might ask how something noted in the due diligence responses translates into actual activities.
Integration planning, in its simplest form, is a sequence of activities, one after the other, across multiple rows, running concurrently. Some tasks move faster, some end sooner, but you must ensure no activity is left behind to avoid the "Oh, we forgot that" moments.
Regular weekly check-ins are beneficial. You ask if anyone has questions, where they are in their process this week, and maintain ongoing dialogue. This ties back to the 'walk the wall' concept, which is really the start of the integration plan.
The plan involves a big framework with a lot of information—some structured, but mostly unstructured. It's not like robotics, where everything is pre-canned and predetermined; you just push a button, and everything happens.
M&A integration is like the wild, wild West. While many believe they have a very crisp and clean process, there's a lot going on behind the scenes—flailing, chaos, and ambiguity abound. Yet, from the outside, it might appear straightforward, but in reality, it's quite challenging.
Aligning with the target company
The ideal state is that they're involved as soon as possible. A lot of companies are different. I've been around projects where the approach was, "We acquired you, just do what I tell you to do." That doesn't work well with many people.
It feels like, "You're trying to integrate me and sell me on why it's a good idea to be here, but that's not the vibe I'm getting. I'm just here to serve you in your role." It goes back to the idea that M&A is largely about relationships. Friction-filled relationships out of the gate lead to friction-filled outcomes.
I did a deal in Madison, Wisconsin when I was with Microsoft. The company was largely being sold by the board, but their executive operational leadership team was not enthused about selling. They wanted to keep running their company their way.
It was in the online shopping space, and I remember having some really hard discussions with the leadership team. I asked them, "What's this going to look like for you? How long do you want to hang around?" which usually suggests some sort of holdback.
Their response was, "I'd really just like to get my money and leave." I understood that, but it wasn't our intent. One leader very specifically told me, "Jim, if I wanted to work for Microsoft, I would have applied for a job there. I have no vote in what's happening right now."
You have to help people work through that. It's like, now I know what that feels like, and it's not that this is a great deal for many reasons. The current deal I'm in has nothing but upside, but nobody came and asked me what I thought. "Would you like to go work for a new company?" I wasn't planning on it.
Early engagement with the target company
It often comes down to a lot of patience and tolerance from the team to be acquired. From the highest level on down, they might say, "I have a day job. I've got a big product release coming up. I'm not interested in sitting through your integration planning meeting." Yet, others are very interested in it.
M&A is hard. Integration is really hard, and most people recognize that, either explicitly or implicitly. When you invite them to participate, they might decline, saying, "No, thank you," despite the value their involvement could bring.
In past experiences, especially post-LOI when you have more access to people, I've encouraged their involvement. "I want your DNA in this integration plan. This will go a lot smoother, and your colleagues will follow your lead. If you're invested, they're invested; if you're not, they won't be either.
Who do I need to talk to free you up from your current tasks? I want you to help us build this plan." Some people are thrilled by the opportunity, while others say, "I wasn't planning on sticking around."
Transparency and collaboration are crucial. Early in my career, I wanted to control everything and didn't want others involved. I've learned that this approach can work to a degree but doesn't scale and often upsets people.
If they feel you aren't interested in their input or even in giving them a chance to contribute, it doesn't work out well in the long run.
Defining 'done' in M&A integration
One of my managers at Microsoft, a great M&A leader who came from a functional background rather than M&A, used to ask my colleagues and me, the integration leads, "What does done look like?"
It's a challenging question. The straightforward answer is that you're done when you hit the end state. But consider defining the end state; let's say it's two years out. What does that look like? There are significant, broad objectives you aim to achieve, so it's not overly detailed.
For example, full integration of the employees, achieving certain retention rates, having one Salesforce instead of a disjointed sales approach, or having the development teams properly organized—these are indicators of the end state. However, the end state can change over time.
Two years ago, did we know we'd be having this meeting now? The same unpredictability applies to M&A. Two years later, the economy changes, interest rates fluctuate, it becomes harder to borrow money, or new needs arise like installing superchargers because everyone is driving Teslas.
You don't foresee these changes two years earlier, and then you arrive at that point and the whole world has shifted in many ways.
You have to be agile and nimble.
Here's my mantra for my current project, and it's become my new kind of catchphrase—though it's not exactly a phrase: Simple, streamlined, nimble, agile, productive, efficient. I tell everyone I work with and all the workstreams I'm leading that everything they do must align with one or more of these six principles.
Are we being simple? It doesn’t look simple. Are we being agile? If you're still doing things the same way as a month ago, then no. It’s really easy to critique, but that's my focus now. The overlay is that all this happens typically in an environment filled with chaos and ambiguity. So, the floor is constantly moving.
Integration teams leading due diligence
At Microsoft, from 2005 to 2010, which was the time I was there, the integration team led confirmatory due diligence. We led technical due diligence.
We had an incredible technical lead, and I learned more about technology from that process than I ever did, including open source and other aspects that can create challenges in overall integration. Having the integration team involved directly was massively helpful. It removed one handoff from the process.
You know, I often say that electricity diminishes over time and distance, so it needs to be rebooted. It's similar in due diligence. If only a few people are conducting the diligence and then later there's a handoff, "Here's what we found, here's what we learned," it's never 100% of what they experienced.
Yes, you can give everyone the readouts and documents, which is very helpful. However, much of due diligence involves sitting down, examining something, and then having conversations with the responsible person at the target company, like the chief legal officer or head of product.
Unless you record those meetings, there's more learned in that dialogue back and forth than anything that could be written down. You simply cannot write down 100% of what is said. Even if you have a stenographer or use a transcription tool, you still have to listen to all of it.
Leveraging diligence data for effective planning
You would need to inform the platform of what your target end state looks like, and then it can begin to filter in details like, "This is what was said, this is what was written, this is what was drafted." From there, it connects the dots to what the end state looks like.
This approach would take massive cycles out of the process. Even when you conduct due diligence, you encounter modules like HR due diligence and R&D due diligence. This highlights my point about the value of integration leads who can synthesize how all that connects.
However, there's no obvious way to do it. Utilizing AI, like ChatGPT, could facilitate this process, but most people just stick to their expertise: "I'm the HR expert, I'm the R&D expert, I'm the IT expert." Yet, most HR functions run on a platform. So, if you guys communicated—do you understand how that works? Do you know what you found?
For example, if you populate a bunch of records out of Workday, are those the same records that HR has in the payroll file? They should match one-to-one to ensure everyone gets paid correctly.
While this may seem like low-hanging fruit, as issues become more abstract, someone needs to be able to identify, "That connects to that." We need to figure that out.
Advice for M&A practitioners
When I did my first deal ever, I asked my boss what he wanted me to do. He was about to leave for a three-week trip to Australia for big game fishing, with no cell service, and his parting advice was simply, "Just don't screw it up." He used a different language, but it was essentially that—not very helpful.
However, in hindsight, I learned the importance of asking a lot of questions. He did tell me what he wanted it to look like, though he didn't use terms like 'deal value drivers' or 'end state.' I constantly referred back to that vision, ensuring my actions aligned with those goals. I just knew intuitively that was what I was supposed to do.
The company we acquired had a huge team of brilliant math PhDs from Russian science institutes. I didn’t speak Russian, didn’t write code, and could barely spell PhD, which made me feel quite useless initially.
But I started figuring out the right questions to ask them, like how they planned to apply their work to the next technology release in ways I could understand. Whenever they delved too deep into the code, I’d have to stop them because that wasn't my area.
My focus was on practical outcomes: "When will you be done? Can I inform the sales team? When can they start selling it?" This tied into coordinating with QA engineers and the build process.
It was intuitive, but it was about asking questions, sometimes even ones that seemed very basic, but were crucial. For someone new to this, it’s all about problem-solving and critical thinking.
Sometimes you have to go slow to go fast, and ask like "What does that mean?" Especially when talking to engineers, you might find yourself puzzled, asking "You do what? When? On what?"
I was comfortable with operations and finance, and HR was straightforward in its own way: "What are we doing with the employee base? Are we keeping everyone?" That was simple until retention issues arose, then it became "Why are you leaving?" "It's cold here. I want to go somewhere warm."
Ultimately, it’s about being humble and asking questions to navigate through M&A processes effectively. At all levels, I think senior execs down to probably the most junior person, it should be the same approach. The questions are just different.
.jpg)
