How to Evolve Your M&A Workflow Using Agile Principles

“It’s (adapting) never about age, it’s all about the mindset.”

The evolution of IBM's M&A process

On this episode of M&A Science, Kison interviews Gina Sandon, Director of Corporate Development, M&A, Synergy, and Integration at IBM, about how to evolve your M&A workflow using key Agile principles. The conversation revolves around IBM's M&A process and how it has evolved over the years by implementing Agile strategies. They also discuss the Agile Accelerate Model, how it differs from the traditional M&A approach, its origin, and why it works so well.

Kison and Gina then move on to talk about how playbooks work when using this model, how COVID-19 has impacted IBM's activity, and how you can drive change. Adapting to change, according to Gina, is more about a mindset rather than an age. By this standard, it's possible for anyone to adopt the Agile mindset and adopt these concepts to improve your M&A process. Finally, the two close out the interview with Gina's advice to practitioners and the craziest thing Gina has seen in M&A.

Text version of interview

If you don't mind kicking off with a brief description of your role and experience at IBM 

I came to IBM through acquisition of a company called Initiate Systems, Chicago based right there with Kison. I have been at IBM, a little over 10 years. And my career in IBM has been a winding and interesting career from leading a industry marketing function globally to working on a very large client team. 

So client facing, and then moving into a couple of entrepreneurial pilot kickoff programs in the IBM company where we tested some new adventures and transformation, and then working in M&A, and I found my way back to M&A.

Because of my passion for the acquired employee experience and the opportunity to help other acquired teams come into IBM, have a great experience and energize increase IBM's growth and market presence.  I have a passion for the people and I hopefully will share some of that with you as we talk through today.

I'm curious, what is it about integration that really draws you in? 

Well, let me start off and we'll talk about this a little bit more, but we actually are moving away from the term integration. Integration has this connotation of doing it to you, not doing it with you. 

What we've found over the years is that when you bring an acquisition into IBM, you really want to embrace all that's unique and special about that acquisition and co-create. With that acquisition’s, leadership and team members, the potential to bear the greatest value creation you can and integration doing it to them is not probably the right approach.

It's embracing that co-creation doing it with them. So we've moved to the term implementation. Implementation of the business as usual state, we are trying to achieve. And doing it together with the acquired team. 

How has IBM evolved since you started?

IBM has been on a transformational journey, both from a market perspective and our focus around hybrid multi-cloud and data and AI, which is what we are uniquely bringing to the market today.

So our focus has transformed, but also our internal organizations have transformed.  We have moved from hierarchical type approaches to things. Checklist driven, lots of individual silos to a much more forward-thinking approach on how we become business, outcome oriented, add agility. Agile transformation into our ways of working across the entire business.

What's been interesting is different areas of the IBM company have moved at different paces on this agile transformation journey. I feel very fortunate to be in our finance and operations organization under the leadership of Jim Kavanaugh, and he's really embraced, promoted and enabled individuals and teams to develop transforming our workflows and the way that we operate in agile ways. 

So it's been a great experience and we've taken that to the next level in corporate development to try to leverage the transformation in finance and operations, into our corporate development approaches as well. So it's changed. It's ongoing, it's iterative, all strong concepts of agile and agile ways of working.

And we continue that journey every single day. 

How have you seen agile principles improve workflow and the integration process of IBM‘s acquisitions?

So we embarked probably a little over a year and a half ago on something. We called Acquisition Agile Accelerate, and it really was to take our thinking from.

Checklist driven implementations to something that was more flexible that enabled us to move more quickly. That enabled us to innovate along the way. 

We start with what probably all corporate development and M&A team start with the strategy around the portfolios that they're looking at and how do they build inorganic growth into that, and then moving to the alignment and onto deal enablement and transition to operate. 

Really what we focused our Acquisition, Agile Accelerate work on is in this deal, enablement and transition to operate phase. We really looked hard at how are we going to think about the deal rationale.

Think about it in a different way. How are we going to develop due diligence?

In an approach that both gives flexibility, but also gets to the business value quickly. How are we going to then do the discovery of what it takes to establish an acquired organization into IBM's operating models and business as usual structures.

And each of these things are reliant on understanding what the post close operating model might be.

• Is it a tuck-in?
• Is it a hybrid model?
• Is it a standalone business potentially?
• Are there spinoffs and divestitures across this as well that we might look at? 

So this is the high level picture of what we focused on for Agile accelerate. And we  unpack each of these areas and built some workflows to go through. How do we work together? 

How do we bring teams and individuals functions into each of these stages in a way that really minimizes the resource use or the resource required when we're completely focused on what is the business outcome for that iteration?

We then looked at it in three areas of critical importance:

1. The offerings as you bring in an acquisition. 
2. The go-to market. So building synergies and the operating mode
3. We build the implementation plan according to that.

Now there was a lot of debate internally on when do you start building the implementation plan?

And it really does start early. It starts early with a smaller team it then adds subject matter experts across the workflow and ultimately builds to how do you get to an operational state. I would call out just a little bit here, the operational states and some of this we learned on the Red Hat acquisition, which was acquired and put in as a standalone business.

The first and foremost thing is to stabilize the business after close and make sure that we do no harm. And I think all of you probably have that same approach. Then we look for efficiencies. That doesn't mean reductions in force, that doesn't mean looking at how we reduce redundancies necessarily.

It means things like: How do we get procurement activities to the benefit of the acquired organization? How do we get things like travel policies with the large scale that we have in IBM, How do we get that benefit for this standalone unit or this business that we've acquired? 

And then finally, we look at how do we optimize the interactions and workflows all focused on value creation, all focused on the business case and meeting the business case. This is the core idea behind what we started to develop in agile accelerator. 

How would it be different to their current operating model?

Let me try to give a real life example using initiate systems as the acquisition, because I still remember being on that team of disclosed individuals as we were selling the company to IBM.

And the day the letter of intent was signed landed on my desk, 1600 due diligence questions, those 1600 for a smaller company was quite daunting because you have to keep your business running while you go through that process. 

We then proceeded through that process of 1600 questions and returning them in what seemed to me at the time, an unreasonable expectation of when we could populate the data room.

And today, if you think about just that piece, we have looked at how do you focus the diligence activities on truly the things that matter?

And all of those 1600 questions are important. Certainly, especially when you get to implementation planning, you really do have to understand the nuances. Understand the very detailed levels of things.But in the due diligence process, maybe there are only three questions that really matter:

1. Should we do this deal? And what do we need to know to do this deal?
2. Can we do this deal? There are any obstacles or barriers to getting this deal done and getting it to close. 
3. How would we do this deal? What are the things that we're going to need to do to realize the value creation or the business case in order to make it the right decision for the IBM company? or any company?

So I would encourage all of you  to think about it in that way. Should we do this deal first and separate that out? Into, can we do this deal? And then how do we do this deal and how do we do it to assure success and achievement of the business case? 

How'd you come up with this? 

Well, I will tell you a full disclosure to the folks listening.

This is not my creation. This is working in a co-creative way, across many different teams in IBM to think this through. It starts with our business unit leaders who are thinking about how do they grow their businesses.

And the business development teams that are looking at what areas do we want to enhance IBM's capability through inorganic growth strategies. All the way through to the functional areas that have to make compliance and tax and treasury and accounting and finance and channel ecosystem and customer support and all of those functions that have to be successful. 

We called on all of those different areas of the business to get feedback and input. There were a lot of brilliant minds that came together to think about this.

And frankly, a lot of lessons learned IBM has been doing acquisitions for a very long time. We at one point had 15 or 16 going on at the same time, we learned a lot. We may have done a lot of things really well. There was certainly a lot of room for improvement. We actually did some pretty significant data analysis on those prior acquisitions through a couple of focused projects and came up with this.

So it's a body of work that was a long time coming. To move from a checklist driven set of activities that really focuses on tasks instead of focuses on the business outcome that really spurred us to push our thinking. 

What was the ‘why’ that was really driving to make this kind of change. Are there enough deals that blew up?

Probably a combination of things coming to get other pushing from our executive leadership, all the way up to the CEO and CFO level of how do we continue to innovate in  IBM and innovate for growth that pushed us to think in new and different ways.

I think it wasn't deals that blew up. It was also resources. How do you best take advantage and the skills and resources that you have? How do you put it in a scalable model? Because there are different timing things. I'll also say that Red Hat, when you do a $34 billion acquisition, and you have to think about it at that level and scale, it really forced some new and different thinking.

How are we going to set this up as a standalone business with independence and neutrality in the market because of the way that the market is and the way that we needed to bring forward both IBM and Red Hat. You know, pushed our thinking and that spurred us to develop this. Now, I think it's a journey that we're still on.

We've still got room to iterate. Improve look at different ways of doing things, but we believe that this gives us a more flexible approach to acquisitions and also a more innovative approach to acquisitions. 

How does it actually come and play in the real world?  How does that end up moving through the stages of the deal?  I know you mentioned you're taking a more dynamic approach on who you get involved, how does that end up happening as well? 

We have put a significant focus on the deal rationale and thinking through the deal rationale in a number of different ways we have implemented a new role.

That is an engagement manager role to really tie together the investment thesis, the value drivers, the risks and activities, the business case modeling, looking at, go to market, route to market capabilities and offerings, and then tying that all together in a deal thesis. That helps all the members of the team that need to come in at various elements.

Look at this and say: “Okay, here's what we're trying to achieve. Here's where we think we need to focus our energies- the questions”. Then we start to look at each deal like that. And we pull in the resources, the skills, the experience sets. We think there are particular tax risks. They might be first to the table. 

If we think there are particular go to market challenges, we bring seasoned experts to the table for go to market. We partner and design each deal. And this engagement manager, along with the business development leader come together with a transaction specialist, so the negotiator, and we have what we call a core deal team.

And that core deal team is really made up of a handful of people. They work together to identify squads of people underneath them with the right kind of subject matter expertise that we need to take forward. Two of the roles that we newly defined. So we recently defined this engagement manager. We've always had a project manager.

I'm sure that everyone has had a project manager, but this engagement manager is really to look across the strategic pieces of it. We also have added into this early stage a go-to market leader from the M&A team with go to market experience in acquisitions. 

And we've added an offering slash technology leader to that core deal team, they will then identify the resources that are needed with the specialized subject matter expertise to bring forward that deal and take it through the process.

That doesn't mean that those are the only people involved by any means, but they help drive the strategy with the business unit in support of the deal thesis.

One thing I'd call out is in this new way of thinking and working. What we are calling discovery is taking, let's say in due diligence, you only answer 400 of the 1600 questions and you get to final approva because you've answered the, should we do this deal? Can we do this deal? Now? You get to: How will we do this deal? That's discovery. 

Then we have to start really going underneath the covers, understanding the rest of those questions in a thoughtful approach where we don't dump it on a target team, all in one shot. But we do it in a way that is digestible in a way that continues to be iterative and in a way that develops a go-to-market, route to market plan that can meet the business case.

So the discovery phase is frankly new to us because we previously did it with the 1600 due diligence questions. We're continuing to evolve how we do that. So I wouldn't say we have it all stitched together, but I will say we have a couple of good examples and we have some strong lessons learned and outcomes from the couple of examples where we really deployed this fully and are making progress on deals in the pipeline that we're applying this approach to it. 

So talk to me in a year from now, and we have a bit more data to be able to say, here's what worked. Here's what didn't. So far, we believe this more agile approach reduces the number of resources called upon upfront until you get to that point where you really know: how are we going to do this deal? Then you bring it more resources to bear and then more resources as the implementation planning goes further and you hit the stabilization efficiency and optimization phases. 

What happens to the playbooks in this new model? 

The playbooks are iterative in nature as well. They're not static documents. We do have an internal tool or an external tool that is used to manage audit trails and the project itself from a compliance perspective.

But we've also tuned that tool to be able to do it in a more agile approach with iterative milestones that are business outcome focused. 

Given the current environment where everything has gone virtual, how does that impact how you do things? 

It's clearly impacted a lot of things.

We like many companies out there and we've probably all been watching the deals that are going through during this COVID environment. Most of which are probably all working in virtual due diligence environments, virtual valuation environments, etc. I think if someone would have said in January before, we all knew what this year would look like, that we were going to do all our due diligence activity and all our implementation activity virtually, we probably collectively would have said, ah, I don't think that's possible. That'll never work. 

We have found that it can work and it does work. And in fact, from a capacity perspective, and I just mean moving multiple transactions through a process, it sure saves one heck of a lot of time when people aren't flying all over the place, spending hours of multiple days of the week on airplanes and in transit, you can actually get a lot more work done. 

Now, there are downsides to it, for sure. Downsides like building those interpersonal relationships with executive leadership, building the dynamic, the working dynamic, the ways of working. Culturally, how do we engage with individuals and teams across different time zones? Across different cultural barriers and norms?

You can't make up for that interpersonal dynamic that you get in a face-to-face environment where you're building the camaraderie, the momentum, the enthusiasm together for a deal and for the implementation. We have done a lot of things. Try new ways of engaging using mural and other web based tools rather than just straight Zoom, WebEx teams, whatever the tool of your choice is.

So we are trying to build in those types of collaboration environments and add some things to the sessions. I wouldn't say it's perfect, but all of us are learning to work in that new and different virtual way. 

I'm curious to hear about how the implementation and adoption of new practices has been received? 

So let me start at the individual level. I started my own Agile journey probably 15 years ago. I was almost by force. The development executive in Initiate Systems was driving to change initiates development from waterfall development to iterative releases that we all are becoming familiar with that happened over and over and over again.

In my world as a marketing executive, I was used to two releases a year. I could plan a launch around each of those releases. I could plan a sales enablement session around each of those releases and a whole bunch of other things. Promotional events, the whole nine yards suddenly I was faced with as a marketing leader, constant iterations and releases of new features, new functionality, new capabilities.

So I went to this executive and his name was Dave, and I said "Dave, you gotta help me here. You keep sending me, we got this new feature, we got this new functionality. How am I going to bring that to market? I can't, every two weeks I have a launch. It doesn't work". He gave me this book and it was The Agile Manifesto.

I started to think about that in terms of, ‘how would you actually twist a marketing function that is really focused on twice a year launches in all aspects to something that could be more dynamic and more engaging and ongoing? And I challenged the team to begin to think about it in that way.

And did we do it perfectly? And did we Institute scrums and stand-ups and iterations and showcases and retrospectives?

No, we did not. We tried, we waited our way into it as a marketing function to try to match our engineering organization. 

Fast forward 15 years, I've continued to study that and got lucky in IBM because we hired a tremendous marketing leader who also believed in this approach in this new way. And she drove change in the marketing function in IBM over the last several years. And other parts of IBM started to develop that including the finance and operations organization. So it's been a huge transformation for IBM. 

Everybody is able to absorb, adapt, adopt, and think about Agile and how it might apply to their way of working in a new and different way at a certain rate and pace that they're comfortable with.

One of the interesting phenomenons that we've been working through over the last probably 18 months is that just because corporate development is moving towards these Agile ways of working and these new workflows that enable these new team structures squads with iterations week daily stand ups, retrospective showcases. 

Does it mean our peers around the company are all where we are? And in fact, some of them are far ahead CIO, for example,  those teams have been working this way for a lot longer than corporate development. So we're all at a different stage.

I think methodology wise, we all believe, and we all think this is going to benefit our business. No question, but it is an interesting dynamic when one team is used to running daily, stand-ups with, cross-functional not who do they report to, but cross-functional diverse expertise in their squad. 

And another team is still silo oriented. I got my checklist. I got my team members. I go up, then I go over. Then I go down, it's been an interesting adventure and we continue to work through that, but individuals have their own rate and pace teams have their own rate and pace of understanding adoption. 

And I've observed, I wish I could put data to this, but one of the things I've anecdotally observed across many different teams that are trying to go this direction is that first project that you try to implement this new way of working on it goes like this: Jagged!

We think agile, then we slide back. Then we go forward. Then we slide back. Then we go forward and 

You have to just be willing to have that happen. You have to open your mind and have that growth mindset. 

The other thing that we've done and I think this is reasonably standard practice across many companies, as we put in these roles, agile coaches. So as we're going through these jagged fits and starts to really change the way that we're working, these agile coaches come to our rescue and sometimes they're psychologists.

Psycho analysts and they help the team figure out how to get through a particularly rough patch. And sometimes they just say, you got to just set that aside. This is the way we're going to do it. So come on, get on board. And these agile coaches have made a real difference. We pulled on them from other parts of the IBM business.

A lot of them have very strong design thinking backgrounds and have taught a number of us, how to think using design thinking practices, which facilitate agile ways of working. It's a journey. I can't say that enough. It's a journey and I too continue on it because I have personally implemented Trello as my agile tool of choice.

And so I run an individual Trello board. That has my working activities, my cards, my completions, my own retrospectives, my own pieces of work that I'm responsible for and accountable to the business that has helped me both institutionalized for me and for my teams, how to work in a new and different way.

It sounds a lot of that is experiments that you are trying different things and really seeing what works, what sticks and what doesn't, does that sound right?

Yeah, I would say that there is experimentation. Try it, fail fast and move on. I would say that's absolutely true. And it's not to say that everything is an experiment because we have a ton of experience. And so we have some very tried and true things that we know if you do this, this is the result. 

As the market changes, as the business dynamic changes, as things like global pandemics hit, you have to be able to build that in and experiment how you're going to do things differently to adjust for those dynamics. 

Have you seen age make an influence in terms of adoption rates and new practices and technology?

I don't think I would call it age. And in fact, I think I would label it mindset. 

The individuals that have the most success are those that have a natural intellectual curiosity that have established in their own persona, a growth mindset, a continuous learner mindset. 

Those are the individuals that have the highest propensity to look at this, think about it, internalize it, understand it, and start to see how it can really benefit them, their work and their contribution, frankly, to the business area that they're in.

And that is a statement that is probably much broader than corporate development and M&A that's a statement in general. So I don't think it's an age and I have great examples in my team.

It's a mindset.

Are there other traits that are required to adopt agile practices? 

I think open-mindedness is probably one which may be closely related to continuous learner. It is hard to adopt Agile practices. If something that worked for you 15 years ago is what you're still relying on.

The dynamic nature of this business is so different today than it was 15 years ago. Just a personal pet peeve of mine and my team would tell you, this is the first person that says to me, that's not my job. That's a pet peeve of mine. It's all of our job to make sure that we're contributing every day to our company's innovation growth and the initiatives our leadership has set out for us.

So I  look at that and when I start to hear or even sense that people are pushing back. I got my checklist and this is what I'm going to do and it's in this box. I start to try to coach and develop and bring out the benefits of thinking potentially outside of that box for individuals and teams.And that's part of agile transformation too. 

There's a lot of specialists in IBM that focus on that change management. I've been fortunate enough to work with some of those really talented change management people. I would highly recommend it for those people listening to this. If you haven't engaged change management specialists, as part of your M&A both process and transformation, they are critical to the success in that. 

Is there anything in particular they do that just works really well?

Those teams really demonstrated an incredible amount of empathy from the lens at which each individual or function comes at a particular issue, problem situation. They have the ability to bring out that lens, synthesize it, and bring people along on a timeline or on a thought process in a way that doesn't shut people down.

That's a really important piece because people will jump in. They'll buy in, they'll engage if you can bring them along. 

• What's in it for them? 
• What's in it for their annual review? 
• What's in it for their accomplishments? 
• What's in it for their career? 

All of those kinds of things. People have to really see it from their lens and why does this improve their ability to contribute their piece to what we all know is a very complex workflow with a lot of dynamic things going on. 

And every function has a role to play. Every function has a piece to contribute to the success of achieving that business case. If sales blows it at the number, but the backend’s fallen apart..it's not going to be successful. 

So those change management folks really help the co-creation with the acquired  team, the implementation team, bringing that together, helping to bring everybody along a path on a particular project or a particular deal. And they make a huge difference in employee engagement, regardless of whether you're an IBMer or an acquired IBMer or a target.  

Those engagement principles, frankly, they don't change. We all are humans in the end. 

I need some advice, give me some lessons learned that other practitioners would benefit to their own M&A practice. 

I would say, first of all, read Kison's book, I did that and found a tremendous amount of thoughtfulness in there.

Ground yourself in some design thinking, understanding, use that to help facilitate the conversations in your organizations to get to how might you move toward this and then just keep iterating, keep the momentum of the transformation. 

Use the showcases, leverage retrospectives to document the lessons learned and drive the improvements in the next sprint, the next project, the next piece of work that you're going to undertake.You should not skip the retrospectives. 

And sometimes it seems like you can just race past that onto the next thing, because we're all so busy, but there is such value in doing those, documenting those, sharing it broadly. 

Develop a culture of transparency.We all work in a space that is highly confidential in many ways. Non-disclosure agreements limited access to people on very, especially for publicly traded companies, very highly guarded growth initiatives, and you really need to build trust and transparency in those core teams. 

You need to think about how you manage the information flow in a way that is transparent, but still protects the disclosure requirements.But the more that you can enable the teams that are currently disclosed in a very transparent way, using collaboration tools. 

Using Box and Slack and Teams and all those kinds of tools. It makes it so much easier because when someone new comes into the team, and starts running the sprint. If all of that information is already set up in a transparent way, they can go through it quickly. If you have to rely on our old standby of sending in volumes of information via email? Wow, you're never going to be able to move as fast as you want to. 

So start to think about how you build that transparency early with the right permissions and controls around it. But enable it to think further down the road, because you're going to have to onboard subject matter experts, skills and talent along the implementation plan. 

If you start up front and you organize it in such a way, and you build the permissions and the role-based rules around that transparency, growing that to a wider and broader group fast can really help you move in a way that improves performance.

What's the craziest thing you've seen in M&A? 

I just tell you the craziest thing that I see in M&A right now, today are the valuations of companies given the environment, given the economy, given where we're at, that is the craziest thing that I see today in M&A, what's the craziest thing over working in MNA. 

The car that a founder buys on the day that you do a deal. That's the craziest.

Upwards of the, Bentley investment, one founder I saw by on the day of a deal and I use the term investment. I probably shouldn't, but those are pretty expensive cars and they've worked hard, but sometimes I think that might not send quite the right message. 

Ending Credits

Thank you for taking the time to explore the world of M&A with our podcast, please subscribe for more content conversations with industry leaders. 

If you like our podcast, please support us by leaving a five star review and sharing it. 

I enjoy hearing feedback and connecting with our listeners. You can reach me by my email.

M&A Science is sponsored by DealRoom, a project management solution for mergers and acquisitions. Additional educational content is available on deal room’s blog at dealroom.net/blog. Thank you again for listening to M&A science. See you next time.