Secrets to Building an M&A Function

Hello Ma friends. Anyone that charges you per page for a virtual data room is not your friend. It made sense 20 years ago when people would show up to your office to scan documents, but with today's cost of cloud storage, it's a dirty scam. That's why I'm here to tell you about Firmroom.com's new data plan that includes 50 gigs of data storage for only $800 per month. And that would be over $300,000 in.

The per page pricing world.

Don't take my word for it. Check it out for yourself by starting your own free trial@firmroom.com check it out firmroom.com.

I'm Kisan Patel and you're listening.

To M and A Science, where we.

Talk with deal professionals and learn valuable.

Lessons from their experience.

This podcast focuses on stories, strategies and what actually happened during M and A deals.

Welcome to M and A Science, where leading M and A practitioners share lessons.

Learned from their experience.

If you're interested in keeping up with the latest and greatest from M and a science, visit mascience.com and subscribe to our free newsletter. Every Monday we share highlights from our interviews and invitations to events as we build the greatest community of forward thinking M and A practitioners. Again, that's mascience.com I'm your host Kisam Patel, CEO and founder of M and A Science. This episode is from our last M and A Science Spring Summit. In this interview I met with Botany Betty, svp, Head of Corporate Development, Strategy and Monetization at Smartsheet. Smartsheet provides collaboration and work management software trades on NYSE under S M A R. This interview we'll walk through Bonnie's secrets to building an M and A function.

Bonnie, can we kick things off with a little bit about your background?

My background and my career has been fairly non traditional I'd say. I started out in banking, then moved to the buy side and then moved to build an investment firm where I stayed for ideas and then kind of pivoted from a banking investing career into Corp dev and I've been doing that now since 2015. So always been a finance person, a strategy person and a little bit of a deal making professional.

You've done it all banking, the deal side, worked at corporate M and A and now you're at a point where you're helping to build out the M and A function.

That's right.

How many M and A teams have you built out in your career?

Not just building out an M and A team building, but really building out a team of any sort. And so I've been lucky to be part of three team building exercises over the course of my career. The first one was building out investment team when I was at Catamaran, this was almost 15 years ago. And then the second stint was when I was at Amazon and I was a member of the team, a senior member, and helped build out the team. I think the third one is now when I'm at Smartsheet and I'm leading multiple teams and helping build some of them from scratch.

All right, you have relevant experience, let's get into it. What are the actual steps of building out an M and A function?

It starts with the why. That's the first question to answer. Why are we building out an M and A function? What are the kinds of things we hope to achieve with this function? Answering that question first. And then the second piece would be working with the management team to ensure that we're all on the same page from a strategic perspective. Once you've got those two things done, like you answered the why, and you've worked with the management team to ensure alignment from there, it's following a playbook that starts with hiring a team, building processes, systems maturing existing processes, and then of course, building a strategy around why we're doing corp dev, why we're doing M and A.

We got a lot to talk about here. I want to learn all this stuff. When you say the why, walk me through the thinking of that. Because I think of strategy right away, but it sounds like there's even before that, why build M and A function? What are some of those considerations? How do they unfold?

It's really important to get the why. And M and A is not just particularly when you're in house. If you're a banker, it's different. But when you're an in house corporate development function, it's not just M and A, it's also investments. It could be joint ventures, it could be business development deals. And I think it's really important to answer why are we trying to do M and A? Or why are we trying to build a corporate function? What are we hoping to achieve that's different from the organic business? Where the organic business has its own path and trajectory and requirements. What's the goal of the inorganic side? And it could be anything from, hey, we want to make our current product better and there's these holes that we think it's going to take too long for us to build, so we'd love to acquire companies that could fill those holes. It could be we want to enter an adjacency and that's only going to happen via M and A. It could be international expansion in general. I found the corporate development function is best used to help an existing management team look around corners and answer all of those things that I just mentioned. Look around corners, pay attention to what's happening outside the company, be the eyes and ears, and then help take a business from where it is today to potentially somewhere different over a three year period. And not every company thinks about M and A with that lens. So I think answering the why and flushing that out make it much easier to then build the function.

Got it. That's really the purpose. You want to define the purpose of building out this function. Do you move into strategy from there or do you start looking at hiring before the strategy, what order stuff come together?

Number one is answering the why and aligning with the management team of the company on what we hope to achieve. From there, I'd look at building a team because then you're coming to what I describe as strategy for what the function does. What kinds of targets are we looking at? What kinds of deals do we want to do? What spaces do we want to go into? That's an iterative process that takes a few months to work through and get alignment on and it changes based on what's happening in the macro environment. Look at where we are now. Six months ago, the world looked different. I'd go from after you've got your why, build a team, at least a couple people and then work on the strategy together.

When you're building out that strategy for the function you mentioned working with the management team, who's involved?

Everyone should be involved if you're doing it right. The whole C suite, certainly some players are more important than others when it comes to corporate development. But I'd say pretty much the CEO, the cfo, the chief product officer, the person leading engineering, all of those, the person leading sales, everyone should be involved to ensure we're on the right page.

Okay. And that's, hey, this is what the goal is of building this function out. And then it's iterative in terms of your M and A strategy. But at this point you're already starting to build your team out and hire people.

Yeah. And I will say, Kisan, it depends from company to company. Right. At certain companies you might have a CEO who's got a very strong and overpowering even vision who says this is what I want to do and that's what you're going to do. At other Places that might be the product person, somewhere else that might be the sales leader, and a third place, it might be more collaborative. So it really depends on what's the voice inside that management team that you need to be aligned with as you build the function and then execute transactions.

How do you get a sense of that?

I think it comes from spending time with the leadership team and understanding the business in a lot of detail, understanding the market segment they're in and the industry there in some amount of detail. And then lots of conversations to get a sense of that.

Do you keep it all formal or do you have some of these sort of informal, let's go meet up for a drink. And then you kind of get a better sense of where the control is and who you should be working with for what.

It's a combination of the two. It's not so much where the control is, but it's like flushing out the vision. What's your vision for where we should be in three to five years? How do you see the M and a muscle or the corp dev muscle as a part of that? I think it's like flushing those things out, which happens over suddenly more than two or three conversations, some of them formal, some of them one on one, some of them in group settings.

This is a pretty high frequency of conversations that you're having with this management team. Especially early on. Start getting a sense of the priorities and what needs to get done. How do you approach. Is it just a lot of one on ones? Do you do a mix between some group meetings and I think it is.

A mix and I think it depends on whether you're building a function from scratch or you're inheriting an existing team and an existing function as a new leader. That I'd say if you're inheriting something that has been built, it's a machine that's working really well and you're being hired to run it. Your approach there may be slightly different than, hey, we've never really hired a senior person to do this before. This is the first time we're building things out from scratch. Your approach there might be more iterative and might take longer, but it's a mix of one on ones and group meetings over a period of time, just a couple of weeks, maybe a month or two to get alignment.

Who's your first hire?

Your first hire is always an athlete. At least that's how I would approach it. It's always an athlete. There's two paths you could go down. You could hire a senior person who's an athlete who can serve as your right hand person. Or you could hire someone earlier in their career who's going to be able to build models, do research, help you prepare materials, but really high intellectual horsepower who can go across sectors and pick up things quickly. So I think you either experienced right hand person or you go high horsepower hungry early in career person.

It's interesting, you're a little versatile there, but at the end of the day you want to hire someone intelligent.

Yeah, you want to hire someone intelligent and someone who's either been there, done that, seen the function before, or someone really hungry who can run with you while you build a team. And this is just the first hire, not the whole team. Personally, I went with hiring an experienced person who could serve as my right hand who had seen cycles before.

How does it evolve from there? You got this first hire in and it seems like you get different directions and it goes back to variables involved with what you're trying to achieve here.

How does that evolve?

How does that shape? Here's what hire one would look like. And then when do you start thinking of hiring dedicated resources for doing integration management and things like that? Like how does that thinking of all.

In the corp dev function there is the thesis building part of the job, the deal, sourcing, execution and then integration. Building integration I think is perhaps one of the last things you do. And you do that only when you're really a serial acquirer with the need for a dedicated integration function while you get there. You might hire just one person to do integration or your company might have a PMO and they might take care of integration work for you. It certainly is different than being a front end deal professional. It is a different skill set and I think it's important to recognize that it's a different skill set that needs to be invested in either with a direct hire or support from a pmo.

That makes sense. When you're doing the hiring, it sounds like you can just do this. As you progress, you start making maybe one or two key hires and then you're starting to focus on other areas, your origination model and building out their process. I want to dive into the origination process. I want to get a sense of how you're working with the CEO throughout this and maybe even think through how that strategy again gets flushed out. Specifically for the M and A strategy that allows you to really prep for origination.

Yeah, I think building out an M and A strategy after you've answered the why is building out a market map. And that is again an ITERATIVE process. It'll vary from company to company depending on the surface area of the organic business and to a certain extent, the size of the balance sheet. I'd recommend starting with what's our core product, what does it do? Who does it serve? And then build a market map of adjacencies that are sensible for the company to potentially expand into. And then have a conversation around, hey, we've got this dozen to even maybe two dozen areas we could expand into. Which of these make the most sense and filter down from there. What I found is doing M and A for your existing product is a little bit easier because there's a product, it has a roadmap, what holes to fill, it's got custom customers thinking about, hey, here's where I could go to M and A for the existing product. It's probably a handful of areas. Again, it depends on the business, but it's handful of areas. When you're getting into adjacencies, that could be a really wide surface area and you want to make sure you're not spending your time spinning wheels in things that don't make any sense or that are not likely to get support from your board, from your management team. So you narrow those down into digestible four to six areas that you can spend time in and be really thoughtful about what may make sense there.

Who do you want involved with the market map?

Your management team. But even the next layer down, I'd say the people running the business and the people running product, the people building, the people selling the product. And I think you have to have a sense of the external environment and where the world is headed for that particular segment. So, for example, if you're doing something in robotics or AI, you might want to have a sense of, okay, where is this market headed? What does the world look like three years out, depending on how cutting edge the business is. If you're really the frontier of innovation, I think having a pulse on the external market is important and that comes from having relationships with people outside the company. So the investment banking community, the venture capital and private equity ecosystem, other founders, I think that'll help shape the market map.

Yeah, absolutely. You're bringing in this additional feedback or input to expand on it. That lends to a challenge. I personally have. I don't like to leave any stone unturned. So if I have to build a target list, it's going to be extremely comprehensive. How do you go about prioritizing it? Because that's the thing you're not going to send. Here's a list of 500 companies and send that along for the board to look at. You have a theme of simplicity I'm already picking up on. How do you go approach prioritization?

I'll speak, Kisan from the lens of being in the technology industry because things might be different if you're in manufacturing or retail or something else. But I've built my entire career working in tech. And so for Internet, software or other tech businesses, it always starts with the product or with the tech. If you use that lens, I think it becomes easy to filter, especially coupled with the view of where's the world headed and what has tailwinds behind it. So if you've got your list of a few hundred companies, I take a step back from there and say it's not just about doing M and A, it's also about potentially making investments. It's about potentially doing a partnership. Sometimes they, you may start out thinking, hey, I'm going to do M and A. And you might end up just doing a commercial deal. We serve your customers or you serve ours or there's a reason for a joint go to market. There might be a business development transaction that makes the most sense. You got to be open to all of those things. And when you have your swim lanes, your four to six areas that you think, hey, these are the areas that make sense. Within those, particularly in tech, I think you prioritize companies that are innovating, that have built good businesses that have tailwinds behind them, and you get to know those companies again over a period of time, see what might make sense.

Is it that qualitative thinking or do you actually build out a whole scoring model and start building an algorithm to go with it?

It depends on who you are. Several years ago, Salesforce market map and target list was leaked.

Oh yeah, the good old Colin Powell email hack. I remember that.

Yeah. So you can see what they did in their slides and so on and so forth. So I think it just depends on who you are. If you are a very large platform, things might look different. If you're a small, a smaller company, things might look a little bit different. And yes, some of the quantitative, some of the scoring, all of that you can do. I think ultimately it comes down to really, in my opinion, successful M and A or any kind of partnership. It really just comes down to relationships and having a joint vision for the future. What's the philosophy behind your company? What's the philosophy behind my company? Do we have a joint vision for the future to make this work? At the end of the day, that's the only thing that works.

But when you have so many, how do you keep tabs? Isn't there at least like an Amazon rating somewhere?

An Amazon rating? 4 stars, 4 out of 5. Yes. You can do all of that and you should certainly you have to think about things like the size of the business, the financial metrics, the efficiency with which the business is being run, margins, cash burn, the quality of the team, particularly the product and engineering team that's building the product. How much investor capital maybe has been raised that you in a transaction would have to justify paying for. You have to do all of those things.

Yeah, I get it. One of the things when we look at moving past this, we got our assessment, we're starting to narrow down targets. Walk me through how do you approach the actual origination model? I think you've seen it in quite varying ways. How do you get that shaping? How do you get it started and start building pipeline?

I think it starts by building relationships both with the people in the ecosystem, so bankers and investors and then with companies. It's a long term game. You got to know people, you got to know what they're doing. You have your list of 20 to 30 names that are interesting to you for a variety of reasons. And I'd say this name of get a handful, 20 to 30 are companies perhaps that an acquisition might make sense, perhaps you might want to invest in them and help them build, or you might want to do a partnership of some kind. I don't think it always starts with M and A. I think it just starts with you're doing something interesting, we're doing something interesting, let's get to know each other and then it goes from there. And many times I think more often than not there may not be a joint vision for the future. So you may get to know a company over a period of time and you just stay friends and there's no transaction at the end of it.

I like that term, joint vision. So even starting out, get the network feel, get to know the bankers out there, get to know just the market of those providers. I'm curious about internal because especially for tech companies, a lot of time it's the product managers that have some interesting insights. I guess you would have them involved with building that market map. Is there that conversation relationship with them in terms of origination? Part of it as well, I guess going to the 20, 30 companies. There's stuff that'll come to you through the bank processes. But it sounds like a big element of this is being Proactive, reaching out to those companies directly. Want to get a sense of how do you work through that? Is it with internal relationships first or is it, I'm just reaching out, I got my corp dev title and people should take my phone call. How does that work?

I think it's a little bit more of an art than a total science. But yes, it's internal relationships that your management team probably has bunch of relationships. You might have relationships yourself, having been in the industry. Your people on your product team or your sales team might have relationships. So I think it starts with that warm intro from someone who perhaps knows the company, or even a warm intro from an ecosystem player like a banker or an investor. It might. It's not always a banker, like selling a deal, but it's a banker saying, hey, you guys are operating in this space. You might enjoy getting a coffee together and catching up. I think it starts with that. And that's how you build relationships to potentially then originate deals. Sometimes if you can't find a channel for a warm intro, it might be a cold outreach. It might be like, hey, we think you're doing something really interesting. Would you like to catch up? And I think the best founders are always open to building their own network, particularly with people in their industry or adjacent industries and just comparing notes.

Do you do that often? Reach out cold to the CEO and saying, hey, we should grab a conversation, get to know each other.

I've done it plenty of times.

What does that look like? Like how. What does that messaging look like? When you reach out to people like.

That, it's often literally what you just said. It's, hey, I think you're doing something interesting. You're building an interesting business and Obviously you have LinkedIn and things like that. So people know exactly where you're coming from and what your platform is. I find more times than not, people are open to say, hey, let's do 30 minutes. Especially in the post pandemic world, when it's 30 minutes over Zoom, it's fairly easy to squeeze in.

You get that meeting booked. How do you frame that first conversation? Because it doesn't sound like it's straight to M and A. You even mentioned doing investments, partnerships and things like that. What's your structure? After the small talk and framing that.

First meeting, it's just getting to know them and getting to know their business and sharing your business with them. Sometimes again, depending on the platform that you're at, people may already know your company. Suddenly, if you're at a big company, they're like, oh, we know exactly who you are. At other times they're like, hey, I know who you are, but help me understand what it is that you do. So it's just saying, hey, here's what I am, here's who we are, here's what we do. You're doing this. That looks interesting. You share your business, they share theirs. We talk a little bit about if it's a smaller company you're talking to or a startup where they're trying to go. People might say, hey, here's where I am today. This is what I'm struggling with, that's what I'm trying to do. And then we talk about, maybe is there a way we can help with that? Maybe vice versa is my mind. We say, hey, we are struggling with X, Y and Z and maybe you can help with that. So I think it just starts off with that kind of a conversation.

Yeah, pretty casual, pretty transparent. Sounds like you're pretty upfront about what your role is, how you're trying to grow the company, opportunities you're seeing in the market. Now with this origination process, we're building pipeline. At this point we're doing both. We're looking at some of the deals different banks may be managing out there. We're doing proactive outreach as well. We build this pipeline, it's moving along like any key metrics or things. I'm thinking of accountability on the M and A function. And what does that look like, reporting that up? Is it specifically to the C suite? Does the board need an update on what the pipeline looks like? What are you really tracking there?

I think it depends from company to company. In my experience at most companies, including the ones that I've been fortunate to be a part of, the management team is certainly involved and the board is involved. And so it is. Here's our market map, here's our pipeline and how that funnels down into the 20 to 30 names, who you've engaged with, what may have come out of it. You do provide those kind of updates. I think it's important to recognize that differently from say banking or a more transactional world. The in house corp dev function. It's hard to measure success. It's not as simple as saying, hey, in 2023, you got three deals done. That's a win because you got the deals done because all those deals could fail and then it's not a win. Or hey, you got no deals done and that's your terrible outcome. Measuring success often comes from what's the impact you've had on the business both in terms of potentially doing a deal, but also in elevating people's thinkings, influencing the direction of the build process, perhaps doing a partnership somewhere. So it is a little bit more of a high judgment exercise to decide if the function is successful or not. It's not purely metrics based.

That's interesting. There's the pipeline part of hey, do we have an active pipeline? What they look like, but it sounds like the emphasis there is on the details about why these things are in the pipeline. What does that mean? That's what your sounds like. You're focused on communicating and then maybe just pick a deal as an example. But when you progress that and we start thinking about those success metrics as you move forward through the deal process, how does that shape and then what are you ultimately measured on for a.

Success For a deal process? Let's talk about a specific transaction. Company A has decided to acquire Company B. Both parties want to do this acquisition and signed a term sheet. At that point, intent is very clear. You've already established a shared vision for the future and you're working through the mechanics which can be complex. Right? What's the purchase price, what's the retention pool, who are the key employees, etc. All of the nuanced details of actually making that acquisition happen. Those things then at that point become easy to measure because you're dedicated in investing the cycles to figure all of this out and you're having these conversations, hey, this company has 100 employees. We want to retain at least 90 of them with this. Okay, we can't get to 90, we've only got 87. Does that work? Those are all metrics based conversations. Or this company has 100 million in revenue, they're break even and we've got to invest X million to get them to profitability. Certainly having all of those conversations for a specific transaction look backs are a good idea, especially when you're serious about the function and you're getting to be more of a serial acquirer rather than a one off here and there. You should be looking back a year after the deal, two years after the deal. Did the thesis play out? Did the team stay? Did we get the growth that we wanted or the synergy that we wanted? And you're educating yourself over time as a company. Here's what we thought we'd do, here's what actually happened, here's what we learned from that process. So I think you do those things. That's how you measure success is the capital. Corporate development is not an Inexpensive effort. Right. You're spending a lot of capital to acquire companies. Is the capital being used? Well, are they having the impact that you think they can have? Is the team that you've built high judgment and doing the right thing for the company, or is it just a bunch of deal junkies who just want to get deals done? Those are all the things that you would look at.

Are you accountable on those success metrics up until close and then it gets handed off and the use problem, or are there things in there that hold you accountable post close as well?

Everyone does that a little bit differently. I've seen models where the corporate development team is accountable for everything until deal close and then it's here pushing the binder over to integration and they take it on from there. And at some point integration says hey, pushing the binder over to business unit and then it's the business units problem. I've seen those models. I've seen models where the core dev team is involved for a lot longer in the process to integration and potentially even a little bit after. I think ultimately it's recognizing that your corp dev team is not running the business you do need. If you're acquiring sales, a large company with a sophisticated management team that's going to act as a subsidiary, it's that management team that's accountable for the business that they're running. If you're buying something that you're integrating pretty tightly a year or two down the line, it is the responsibility of the business unit and the acquired management team to run their business.

Which model you think works the best?

What are the two that you're contrasting? The subsidiary model and the integration model.

Yeah, the pure handoff versus tacking on some ownership or essentially having integration integrated into your corp device.

The corp dev team needs to have some accountability. I think it's very easy to be like, hey, I got the deal paperwork done and here's push the binder over. In my opinion, I don't think it's that simple. I think you need to have some accountability into. Did you set things up the right way? Did you do your retention pool the right way? Did you hire the right people? Did you level them the right way? Did you get them the right resources to be up and running on day one? That's where the integration function is so critical, whether it's a part of co op dev directly or dotted line or whatever. But like thinking through those pieces are really important to getting an acquisition to work.

When you mentioned using a look back as a tool, is that something that you just do as more of internal within the M and A function or does it go broader with that to your management team, the board? What does that look like? And then how do you turn that into a continuous improvement model?

It should go broader. Whether it goes all the way to the board or not can be debated, but I certainly think it should be an exercise with the management team. And over a few cycles you then educate yourself on what's worked, what's not worked. Because every company at the end of the day is different, culture is different, the business is different, the personalities of the people are different, and every target is also different. So I feel like every company has to develop their own model for corp dev.

Makes total sense. We covered a lot of the origination, even building out success metrics. We talked earlier about building out your process and I'm curious because every corp dev function has to leverage a lot of other resources internal. And it seems like you're getting as much fractional time from different leaders in the company. How do you go about, especially when you're in this early stage of building out an M and A function to build that it's two parts. You have to build the muscle out for doing diligence and then you got to build a muscle out for integration within your functions. How do you do that?

Hire the right people. You have a strategy for what success looks like and then you execute to a high bar. And I think that is perhaps over simplistic.

Let's say it's you're with a company that hasn't done an acquisition before. So now you've got functional leads that they kind of know of diligence. But how do you really get them on the same page? That and getting the emphasis of how do you prioritize your time with M and A? Because if they really don't know first time doing M and A. Okay, I'll add that on my to do list.

There's a lot of education involved, especially if you're with a team that's never done it before. There's a lot of education involved on what M and A is, how does it work, what diligence means, what are you doing, what's preliminary diligence, what might be confirmatory diligence, what you do, when, how deep you go, a lot of education involved. And so usually it starts out with a preliminary list of questions. If the answers to any of these is a no, we're probably not going to want to do this acquisition, you work through those, you pull those together with the team and you work through those and then you get to know I or a term sheet. And then you move into confirmatory diligence, which is much more encompassing. When you work with a business unit repeatedly for a period of time, I found that you do build that muscle. And then it's like this. Because they're like, okay, we've looked at four or five companies. When you do the fifth or sixth one, if we know exactly the questions to ask, we know exactly what to do. And so the corp dev team, then you're done with the education piece. You're still working together, but it's not like the first time someone's doing an acquisition. So I found that as I've worked with business units repeatedly, it does get easier because you've helped them understand the process.

Is there anything you do to get those functional leads up to speed faster? And I'm trying to think of when we looking at standing up an M and A function, there's a lot of processes and absolutely right that. Here's some core stuff. And it becomes just repetitive and you'll build it. But is there any documentation that you create that really outlines the operating model of the M and A function? And thinking even down the road, you bring in somebody new and this is the first time working with the company and the M and A with others have done it. How do you get that person up to speed?

I think there are playbooks that you have that you share. I've been in environments where we would have a presentation and say, this is what corporate development does. This is what the function looks like. This is the best way to use us. This is what an M and A process looks like. And every six months or every year, you spend an hour or two giving that presentation to management team or business unit leaders so that education is fresh and any new people who've come in know it. You start out with that. And then I like to create documents or presentations that explain what a process looks like. You can just pull off the shelf and say, okay, this is what the process looks like. Here's where we are. This is what we're doing now, this is what we're doing later. So that the education element then just becomes easier and you have standard materials that you can refer to.

So playbook definition for you. Because when I say it, I think of just checklists, purely, here's my playbook for HR diligence and it's a checklist, but this is broader. Let's explain what M and A looks like in our organization here. Let me get too familiar with the stages and the life cycle. Is there any other details around that in terms of expectations around diligence, how meetings are done, information shared, things like that?

Take half a step back and you start with these broader playbooks. Then it becomes easier when you get to that nitty gritty of like HR diligence and your 15 point checklist when you're that down in the weeds, you're often signing, perhaps having signed a term sheet and really into the weeds of diligence where you're like checking off some specific thing for one function. So at that point people have been working on this deal for a month, two months, three months maybe, and your business counterparts are in the weeds with you and have built that muscle as well to help navigate this process.

I like how you keep it simple in that regard when you go through this. I guess I'm getting a sense of when do you know on the integration side and building that out. When do you know you need an IMO and actually stand up a dedicated team for that? What does that look like? Are you doing these initial deals and just purely working with the business for integration? And then eventually I hit a certain threshold and I've seen this before. How does that evolve?

Yeah, I've seen companies do it all sorts of ways to be honest. I've seen like a sophisticated serial acquirer has a dedicated integration function with dozen or more people on it whose full time job is to do integration all the way to a younger tech company that has a five person corp dev team, but they're soup to nuts sourcing through to integration. So everyone does it differently. When you get to a point where you're doing a deal a year or two deals a year, you fall into this bucket of being serial acquire. Your deal sizes might be different than the large companies of the world. And at that point I think it makes sense to invest in an integration function, whether that is one or two people or larger from there. And oftentimes lots of companies use a pmo, right? So not an imo, but a PMO where you're doing integration but you're also responsible for other things that look like the functional jobs similar to integration. So international expansion, for example, your PMO might handle international expansion which also cross functionally touches the same things. You're touching hr, you're touching legal, you're touching pinops, you're touching all of the same things to set up a new office in Europe or Latin America or something. They might take care of process management on a strategy side for Example, we have our OKRs for the year. How are we tracking to our goals? Your PMO might help with that. M and A integration can have ebbs and flows. So if you marry it with another function that has ebbs and flows or where it can take a step back, if a deal comes in, then you're using your resources.

Well, integration is tough, especially from these recent conversations. The go to market part is extremely tough to get right and where a lot of the value gets created or totally missed. As a corporate development leader, what can you do to assure success in integration?

I think it is iterating and reiterating and emphasizing how important the integration function is that it is a high judgment activity. It's not a nights and weekends job of people who already have day jobs. Hey, I'm busy doing this, okay? We decided to do an acquisition stack on integration to the already full workload and that's not the best use. It is investing in that function the right way, building out a playbook. I've worked with external consultants who are experienced practitioners that I brought on to say, hey, help us build out a playbook. Let's invest the cycles now when we're not doing a deal so that we're ready when we are doing the deal. Large companies come in and help you with the integration, right? A big four or otherwise saying, hey, we'll come in and we'll do your integration for you because you haven't built that function out or your function is at capacity or whatever. So I've seen all of those models to make sure that the integration is done the right way. It is as important as doing the deal the right way because like you said, there can be go to market challenges, there can be all sorts of other issues where you don't capture the value that you intended to.

Sounds like the big part is making sure you got the right resources to assure things get planned and executed.

Well, yeah, you have an integration plan of intent that you ideally discuss and you sign before the deal closes, that you work on. Say here's my integration plan of intent. Here's what I want to do with this company. Here's how I'm going to staff resources against that plan to ensure things stay on track and then you have weekly check ins like how are things going? Function by function to ensure you stay on track with your integration plan of intent.

It sounds like on some of these first ones, when you really don't have that mature muscle built out, you would use a third party resource to help out.

You could use a third Party resource? Yes.

Do you?

Do I? I have, yes.

I'm always curious because I feel like the companies have their own culture where they become heavily reliant on using third party resources or they just want to, as early as possible, build it all in house. That's what I'm curious.

My instinct and direction is to do it in house because it's then a repeatable function. You've trained a team, you've trained a broader team, but you don't always have that luxury. You might do an acquisition and your in house team might be busy with integrating that one and something else might come along that's really attractive and you're going to do it. And so I at that point used a third party because my internal team doesn't have the bandwidth. So I brought on a third party there. I think it makes sense to invest in bringing on a third party when you're early and maybe doing this for the first time or the second time just to educate yourself. Obviously using a third party is not inexpensive, but I think it's a worthwhile.

Investment when it comes to maturing the process. Any tips and tricks on enabling that continuous improvement, the knowledge transfer, the center of excellence type of model, Anything there that you found really helpful?

I think it's really helpful to capture these playbooks in materials so it's not just knowledge that sits in someone's head and then if you lose that person, they take the knowledge with them. So you build your integration playbook, your corp dev introduction materials, your diligence lists, your look back docs, you codify that knowledge so that you have access to it for the next deal or third one. Hey, what did we do for this company a year ago? So I think it's helpful to just be really disciplined about putting things down on paper and then referring back to them when you need to.

And it sounds like you do those periodic presentations or reviews that you can resurface some lessons learned and things of that sort of.

Yes, we have monthly business reviews, quarterly business reviews, presentations to the board. Very disciplined in how you're building the function, where you're spending time, what are the learnings, etc.

When you talk through strategy and I like your thinking about offense versus defense and maybe talk us through that. How do you kind of think of that in shaping strategy?

Well, it's offense versus defense or proactive versus reactive. Really good corp dev teams have a point of view, have a plan, have an agenda for their own function. And so yes, you have your banker inbounds or other kinds of inbounds coming your way and you say okay, here are my four or five priorities and I want to filter my inbounds and engage with those that match. That's what I describe as your defensive function or your reactive M and a muscle. What I would say is your offensive function or your proactive muscle is when you say, yeah, I've got my four or five priorities now. How can I network in the ecosystem to find that dozen or two dozen companies that match that priorities and how can I build relationships with those people over a period of time so that two years from now maybe there's a, there's a transaction. So it's been very deliberate about sourcing and building relationships with the right kind of companies where one plus one equals three.

Thinking of the reactive deal opportunities you have that and then the cliche deal fever, I'm sure you've seen it. I'm curious to know what are mechanisms to keep that in check.

It is very easy to get carried away with deal fever at all stages. Oh, we got to talk shit out, we got to close, we've got to sign it. Oh, we are 45 days into an exclusivity period. This is going to happen. The way you prevent against that is by ensuring your core dev team is not measured by getting deals done, but is rather measured by the impact they're having on the business. And it is better 100% to walk away from a bad deal than to do it and think you'll fix it later or whatever. And this is why I don't think you can build a team only with deal junkies like I just need to get deals done, deals done. That's a very transactional model. A successful corporate development model is much more relationship heavy. It is much more long term focused. Then there might be a year in which you don't do any M and A. But you've had tremendous impact on the business in other ways by influencing a build, by doing a partnership, by staying away from bad deals. So how you measure the success of your corp dev team is really important.

It's almost like you're considering it success to walk away from the bad deals.

Yes, it really is. Because you do a bad deal isan and it can not only have you used hundreds of millions of capital and sunk it into a bad deal, you wasted cycles and time and energy of 50 people within the company who invested in that bad deal and a year or two has gone by. That's how long it takes to recover from a bad deal. It's a can be a giant distraction and the time and energy you're spending on that, you're not spending on building or doing something else that is useful.

I totally agree. I got just a handful of questions that popped in. Maybe we can try to run through these. Boy, this is a good tough one to answer here, Josh. We're going to try our best. How do you leverage smartsheet internally for your function? Do you include throughout your life cycle target assessment, pre deal evaluation, pre close planning, integration? Obviously difficult to share the details, but we'd love to hear your perspective thoughts.

And we use our own product internally. In fact, the smartsheet product is used by lots of M and A teams around the world to manage diligence. It's a great tool for that and so we use it to have a list of companies that we're interested in. We manage our pipeline using the product. We manage diligence using the product. We use our own product a lot.

What do you do with the counterparty when you're going through diligence and you're sharing information with the counterparty? I'm curious. I worked with a lot of clients and they use smartsheet for integration components. But when you're going back and forth with the counterparty and there's sort of internal comments versus the comments, you'd want them to look at workflow for diligence requests and things of that sort. And is that something you still use through smartsheets or what does that look like?

We've used a smartsheet with external counterparties where they can edit things, they can just view them, they can just comment on them. When you get to a point where redlining a contract, then you know, you switch to a different format because the sheet may not be the most effective effective tool for that. But we absolutely have used it with external counterparties.

Cool. This one might be too specific, but does M and A integration typically sit within the Corp dev team? For context, I lead M and A integration, but I'm in finance operations and I find there is sometimes a disconnect.

In most companies that are serial acquirers, particularly in technology. Integration is a part of the COP dev team. However, I have also seen it be a part of PMO that is sitting adjacent to but not reporting in to the Corp dev team. I've not really seen it be a part of finops. That seems unusual.

Last question. What's the craziest thing you've seen in M and A?

I'll tell you, I've seen a lot of crazy, which is Why I like what I do. I think one of the craziest things I've seen is deal. This was six or seven years ago, so a long time ago in international location, small deal, some hundred million, where it was two family members who had founded a company and built an interesting piece of technology that had absolutely no revenue. So they hadn't monetized it and they'd been working on it five, six years. And we were like, okay, technology is really compelling. You're not quite to a product yet. You have maybe an mvp. And so this could be an interesting thing for a larger company to bring in house and then build a product around it and monetize it. And they were an international location. Myself and the team flew out there, built a relationship, signed a term sheet, spent a bunch of time doing diligence, and we were probably 10 days away from final contract. And then through the diligence process, we uncovered various family members were on the books and so on. So we're like, okay, you've got to. They're not really part of the company. So we. But clean that up. And the team came back a week before signing and saying, hey, we want to renegotiate the purchase price. And they wanted a lot more. And I've seen that kind of retrading all the time and say, hey, we're not in a position to give you as much as you want more. We can move up a little bit. And they said, okay, we're just going to walk away and hold the company. Where the company was running out of cash. So this management team chose to walk away from a deal that would have given them money, that would have returned capital to their investors. It was a very lucrative exit to instead shut the company down and not return. Like investors lost money and they walked away from proceeds. I'd say that's one of the most unusual decisions I have ever seen. That didn't seem rational at all.

Yeah. What, like, what drives that? Because that's always interesting to think of M and A deals and the egos that come in play. Because it's so true. We just. I've seen it. I've seen it. You've seen it. In that case, what's going on there? What's going through the person's head, Especially at that stage where you've already gone through this and made the commitment and then to break it and walk away.

Yeah. And you invested like three or four months of all your time and diligence. For a minute, we thought they must have another offer. They decided to go in a different direction. No, it was literally, for whatever reason, we're just shutting our business down, losing money, losing our investors money. It was quite surprising, which is why I that's one of the craziest things I've seen in M and A because I've never seen that before or since.

There's no logic. That makes no logic sense. It's just got to be someone with a lot of pride. Yeah, that, hey, I had this move I wanted to do. It didn't work out well. We're just going to deal with it.

Yeah. Sometimes, especially with founders, their company can be like their baby. So emotion can be high, as you've seen. No doubt.

Bonnie, I've enjoyed this conversation. Thank you so much for taking the time to walk me through how to stand up an M and A function. Hope you do it again sometimes.

Yeah, I would love to do it again. Thank you for reaching out to me. I've really enjoyed this conversation as well.

My pleasure. Here's to the deal.

Thank you for taking the time to explore the world of M and A with our podcast. We love hearing feedback. Tag us on a LinkedIn post, add a review on Apple Podcast.

We'd love to hear from you.

If you need help standing up an M and A function, or optimizing one that you already have, we're here to help.

And if we can't help you, we.

Probably know someone that can. You can reach out to me by email Kisan K I S o n a science.com or you can text me directly at 312-857-3711. If you just want to keep learning at your own pace, visit. Visit mascience.com for a lot more content and resources. That's where you can also subscribe to our newsletter. Again, that's mascience.com here's to the deal. Views and opinions expressed on M and A Science reflect only those individuals and do not reflect the views of any company or entity mentioned or affiliated with any individual. This podcast is purely educational and is not intended to serve as a basis for any investment or financial decisions.