Toyota’s Woven Business Unit
We are a fully owned subsidiary of Toyota, and our focus is to create innovative mobility products, technology, and services. One of the focuses is building autonomous driving for Toyota.
Our presence in North America is solely through acquisitions. We started with the acquisition of Level 5, which was a division of Lyft, and we did a few more acquisitions in the U.S. and in the U.K. The goal is to support Toyota to bring mobility solutions to the world.
The goal is mobility for all and safety for all. That is the motto we strive for at Toyota. We’re building an autonomous city outside of Tokyo. Woven City is one of our initiatives where we plan to demonstrate our technologies. This city is built at the base of Mount Fuji, which is like the North Star for all of us.
The ideal integration process
A lot of times you'll hear that integration is considered only after closing the deal. It is often treated as an afterthought, and this approach is where many deal failures stem from. I'm a strong advocate of bringing in the integration lead as early as possible in the deal lifecycle. Right when you are structuring the deal and building your deal strategy, that's the right time to bring in integration and start building your integration strategy in parallel.
As you are conducting your early or confirmatory due diligence, the integration process should start. You don't have to pull in the entire integration team, including all work streams or functions at that time. But depending on the type of the deal, you can involve the key workstream leads.
As you go through the due diligence process after you sign the LOI, that's the time to start pre-planning for your integration, building your integration roadmap. This is, of course, a very iterative process, but getting a good head start during the due diligence period is what will lead to a successful execution of the integration strategy.
Once you close the deal, you can enhance the integration plan you've put together. Then, increase the scope, bring in additional resources and functions into the mix, and execute on that integration strategy. The key is to have the integration process aligned with your deal lifecycle.
The importance of integration capabilities
They say that the majority, more than 70 percent of deals, fail. This high failure rate can be directly attributed to integration that is not planned correctly. It is very important to think about your integration, as I mentioned before, as early as possible during the deal life cycle.
At Woven, when we did our first acquisition, we didn't have any infrastructure in the US at that time. Our Japan team didn't have any prior experience with M&A. It was very important, and we learned it through a painful experience, but building your integration capabilities ahead of your deal is really critical.
You may not have the luxury to have dedicated integration resources at your disposal. So, you have to leverage the leads from different functions. They will have their day jobs to do, and this is going to be an additional responsibility for them. If you have the time to do that planning beforehand, try to engage the right leads from each of the functions and prep them for the integration.
If you have playbooks that you have built based on your prior experience, you can leverage that. This helps to build that muscle in the company and build a culture for M&A in the team. So, once you have the deal in front of you, you've done your background homework and you're ready to tackle that specific deal because every deal is unique.
However well you prepare, there are always going to be new situations, new problems to solve. But at least if you have the base aligned, then you can take on the complexities of a specific deal with a team that is already in place, now familiar with the base integration process and the capabilities required to execute that kind of deal.
Integration planning pre-LOI
Pre-LOI, you definitely have a lot of restrictions. But within these constraints, you can still bring in the right leads. You can leverage the NDA to maintain confidentiality and adhere to the restrictions.
It's really important to pull in the right leads. For example, if you're looking at an acqui-hire, you need to involve your HR leads upfront to plan how you're going to retain that talent. If you're acquiring new technology, it's crucial to bring in your product and technology leads, as well as your operations leads, so you can integrate and launch the new product as part of the integration.
Depending on the type of the deal, identify the critical work stream leads or functional leads that you need, and then once you sign the LOI, bring them into the discussions. Involve them in the due diligence and ensure you ask the right questions.
It's important to involve the right counterparts from the target, maintaining confidentiality with the NDA, but ensuring you have the right people involved to gather critical information for building your integration plan and strategy. Maintaining tight alignment with the deal strategy is key.
The bulk of your planning is going to happen during the LOI to close phase as you do the due diligence. Obviously, you can't involve every individual yet, as the deal hasn't closed. But by then, you should have your first versions of the integration strategy and plan developed, and even your work stream or functional plans, at least in draft form.
You should have a good idea about how your target operating model will look post-close. This gives you a good head start on those key deliverables by close. Then it becomes an iterative process. Once you do the detailed discovery after closing, you will make changes. Your plans will evolve, and your focus will shift from day one to day 90, day 100, day 300, depending on the type of the deal and the horizon you're looking at for integration completion. You can continue to enhance and iterate your planning after close.
Ensuring adequate resources and capabilities during M&A integrations
As I mentioned, at Woven, when we did our first acquisitions, we absolutely didn't have any resources or capabilities in place in North America. Many of you may not have the luxury to have dedicated integration resources or capabilities in place. The best thing to do is to use downtime effectively.
For instance, when you don't have any active deals going on or your deal pipeline is not very active, that time should be leveraged to build capabilities and identify resources in each of the functions like HR, finance, legal, etc. You can conduct workshops, train the resources, and if you have playbooks that you have built, leverage those to bring everyone up to speed.
Based on the lessons learned from past acquisitions, you can identify specific areas that need focus. You may already have expertise in certain areas, but for example, your IT could be an area where you need to build more capabilities. Identify those gaps or areas that need focus for your organization and start building that expertise. This ensures that when the next deal comes through, you have the right resources and capabilities to tackle that deal.
Avoiding early pitfalls for integration
It again depends on the maturity level of your organization for M&A. If you have done deals in some capacity in the past, then you are familiar with how the deal life cycle goes and the pitfalls of integration, and you can plan to avoid any burnout.
However, like at Woven, where we didn't have that past expertise in all of our other functional areas, it resulted in a huge burnout after the integration. Being proactive and planning ahead is key to avoiding that burnout.
Taking advantage of advisors and resources like M&A Science is a great way to prepare for upcoming transactions and raise the level of maturity for the organization. Using these resources and tools that we can leverage is beneficial.
Key integration milestones from LOI to close
As I said, we definitely want to bring in the integration as early as possible in the deal lifecycle. What I have seen, or my personal preference, is for the Integration Management Office (IMO) to lead the overall due diligence process. This is because it involves running tight governance around diligence.
Ensuring that the IMO has the right involvement and lead to oversee the diligence process after the LOI is one of the key steps to ensure we have the right integration plan and strategy.
In that sense, the first milestone would be to set up the right version or the first version of your IMO. As we discussed, you don't have to bring in all the functions and work streams into the mix, but depending on the type of the deal, bring in the key leads and start that IMO version right before you sign the LOI.
The second milestone would be to come up with your integration strategy, which should be very tightly aligned with the deal strategy. The next milestone is to build a high-level roadmap or plan for integration. It's going to be iterative and enhanced further, but having that starting version is really important.
The most important milestone is to socialize the integration strategy and plan with the key stakeholders, including your deal sponsor and all the functional executives. Getting their buy-in and commitment for the resources from respective functions is a key milestone. These are the things you should focus on from that phase, once you sign the LOI, before you close.
At this stage, because this is pre-close, you may not have much visibility. However, the 'two-in-the-box' approach is the right way to go. If you can get some kind of commitment from the target side, that's excellent.
It ensures that the target feels involved in the overall integration process, leading to more constructive response or participation from the target during the integration process. I would definitely recommend involving stakeholders on the target side as well.
Typically, when building your integration strategy and plan, it's the acquiring side that does the two-in-the-box. But if you really want things to work, it becomes instrumental to involve the target side.
So, 'two-in-the-box' means your IMO has a counterpart from the target side, and each work stream has a counterpart from the target side. You're putting the acquiring company and the target 'two-in-the-box' when you are building or designing your IMO.
Aligning the IMO and corporate development
As you said, there are different scenarios we can talk about. At Woven, integration is part of the CorpDev team. In my previous experience, there have been cases where integration is outside of the CorpDev team as well. But from a deals perspective, it is still one team.
In that sense, it becomes very efficient if the Integration Management Office (IMO) takes the lead in running the diligence process. Essentially, it is program management at that level, just running the governance for the overall diligence process. Even if your IMO sits outside of the CorpDev team, it works very closely with the deal leads who are involved in the diligence.
So, the IMO can still provide that governing or program management function for the overall due diligence cycle and involve the stakeholders, in this case, CorpDev being a significant stakeholder. Based on the deal, you would pull in respective functional leads.
Even if your IMO is structured outside of CorpDev, I don't see a problem with the IMO running the overall diligence process. Have you heard about any examples or issues where that has been a problem? In your experience working with different organizations or clients, have you come across situations where that hasn't worked?
For companies like us, which are essentially like a startup, it's a small team where everybody wears multiple hats. I haven't seen any cultural issues with this approach. Actually, the deal leads are happy if someone is taking the overhead of running the overall process for due diligence.
They can focus on the substance of the process and concentrate on the areas they need to go to for due diligence.The Integration Management Office (IMO) can take care of the overall program management or the governance aspect of the due diligence process.
Adapting mature M&A teams to change
In my previous experience working in big companies, you do see that it's a very well-oiled machine and the process is really well set. So, you tend to stay in your swim lane when it comes to the overall M&A integration process.
The problem with that is you don't have visibility over other areas, and then you miss out on anticipating some of the problems that might arise because you didn't have any exposure to those areas.
One way to overcome this, if you have dedicated teams and enough resources to run separate parts of the overall integration process, is making sure there is transparency between all the teams.
The way you manage information is crucial. Ensuring that your document repository is open to everyone so people can check the required details and go through the diligence findings for other functions, even if it may not directly impact them, would be a way to overcome this.
Having the Integration Management Office (IMO) take over the diligence process management piece is an option. You can still have the respective parts of your deal team run that process, but at the same time, opening up the information for everyone and ensuring access is important.
Setting up an early version of the IMO
In the beginning, before you have done the due diligence, you don't have your integration strategy in place. So, you're not sure what the scope is for each and every function or work stream. Setting up the Integration Management Office (IMO), which encompasses the entire integration, is going to be difficult.
It is important to identify the key work streams or key functions for the deal and then pick a lead for that. Setting up that starting version of the IMO becomes key. In the beginning, it could just be the IMO lead with the HR work stream lead and finance. Then, depending on the complexity, pull in people from product and technology, IT, sales, GTM, etc. So, it's just a mini version or a mini IMO, I would call it, based on the deal specifics.
Key people in forming an early IMO
You definitely would take their inputs to build your integration strategy and for their specific functions or work streams, you want to build the plan for that. This is where you start discovering what the dependencies are.
For example, for the sales team to build their plan, they need some inputs from the product team. The product team might say they need inputs from the infrastructure or IT team, like what infrastructure is needed to support the capabilities of the combined product.
So, you start building your functional plans along with the overall integration plan, with inputs from these leads. That is how you slowly expand the scope and bring in other leads into the overall process.
Detailing the integration strategy
The level of detail you need to include when you build your integration strategy should be enough for you to actually take the next step to build the plan, which you can execute. Just having one high-level sentence is not enough.
For example, if one of the deal drivers is to combine the product from the target and build it as part of your product portfolio to take to the market, then your integration strategy is going to be about building the combined product, ensuring you are ready to take it to the market, setting some timeline like 6 months or 1 year, and when you are able to offer that combined product to the market
That means you have to make sure it is aligned with your product development process, have the right pricing in place, and the right marketing in place. Building it to that level of detail should be covered as part of your integration strategy. Then you do that next double click to build the actual plans for individual functions or work streams to achieve that strategy.
And that's why it is really important to socialize that strategy and get the buy-ins because when you say that your strategy is to have that combined product out in the market in six months, you will definitely have some functional leads raising concerns that it might be impossible due to certain capabilities or other reasons.
Early socialization becomes key again to vet your strategy with the actual deals and to make sure that it is a strategy that you can execute on with the right drivers.
In terms of what it ultimately ends up being as a final product, whether it’s like a PowerPoint slide or a five-page document, that depends on your company. I don't think the format becomes that important. It could be a PowerPoint slide or a document.
The format only depends on what your company is used to, but having that clarity where your functional leads are actually able to take and build their own road maps and plans is what is important. How you want to build it is totally up to you.
We are a Google shop, so we use Google slides for everything. Our strategies are laid out in that format, but you could use documents, Smartsheets, or whatever format that works for the team.
Balancing team autonomy in integration planning
When you ask your individual work stream leads or functional leads to start building their plans, one of the important functions or responsibilities of the Integration Management Office (IMO) is to ensure you don't lose the overview.
You have to bring all the leads together regularly to go over the plans, discuss dependencies, and how one plan might change based on specific requirements from another work stream. Cross-communication is extremely important.
The IMO lead is best suited to bring all the work streams together and ensure that the plan is built. From my past experience, you can actually use your integration plan as a use case for your company to launch a new capability.
I'll give an example. A few years back, we acquired a company with a subscription product. At that time, we didn't have the capabilities to offer subscriptions internally. Our subscription billing platform was being built but wasn't ready.
So, I used this acquisition as a use case for that subscription billing platform. We put together the integration plan using some manual workarounds to ensure the new product was integrated with the existing portfolio, and we could offer that subscription. At the same time, I used this use case to provide requirements for the subscription billing platform.
Eventually, one of the deal drivers for that transaction was to get the combined product out within 9 months to a year. We achieved that, but it also helped us build our subscription billing platform.
It's really important to leverage your integration challenge or problem as a part of your overall company's development or targets for building new capabilities. It becomes a very interesting scenario where you can use your integration as a use case. I definitely enjoyed that process quite a lot.
Maintaining collaboration and progress in integration
Taking the example of Woven, we are a very small team. We don't have the luxury of having dedicated integration resources. Every functional lead has their day jobs.
One of the key features that the Integration Management Office (IMO) provides is simplifying the overall integration process for all the workstream leads and trying to minimize the overhead of integration as much as possible.
When it comes to templates, I am a strong advocate of using tools that the team is already familiar with. You don't want to introduce a new tool for the integration and then require updates on a regular or weekly basis. Workstream leads often raise concerns about not having the time to learn something new. Going with tools the team is familiar with works best.
For example, my product and technology or IT workstreams love Jira, so they build their integration plans in Jira. But if I ask my HR and finance team, they might not be comfortable with Jira, so we'll go with Google Sheets or Smartsheet. Being flexible to whatever tool or format works for the team is key to minimize the overhead on all the functional leads.
Maintaining a simple cadence for your IMO meetings where you can review these plans and make real-time changes is also crucial. You don't want to wait for a month before realizing there's a huge dependency and now you have to change your plan. Making sure you have the right collaborative tools in place is important.
We use Slack. Whatever tools work best for your team, leverage them so there is an open dialogue. People can continue to iterate their plans in real time. Having that transparency, like shared drives or folders where people can see other workstreams' plans, helps a lot too, to maintain the iterative nature of the plan development.
Managing cross-functional dependencies
For integration, managing cross-functional teams and dependencies is essential. I especially love the challenge of this because there's hardly anything in integration where you can say, "One workstream, go run with it."
Everything is cross-dependent and will involve at least two or more functions working together. You can't talk about integration without discussing cross-functional dependencies.
Tech stack diversity
If your functions are using different tools to map their plans, having a template from the Integration Management Office (IMO) to report or capture these cross-functional dependencies works well.
For example, my engineering or IT work streams use Jira, and some use Google Sheets for their plans. But for my status reporting, I use simple Google Slides. Every status update includes a key section on cross-functional dependency, making it visible to everyone.
However, you do have the additional responsibility to go back to your individual project plans and find a way to track those dependencies and hold each other accountable. It does become a little additional work, but you can use one format to provide visibility to those cross-functional dependencies. Then, whatever tool you use, you have to ensure that you can track and monitor those dependencies in those specific plans or tools.
M&A execution checkpoints
Yes, there are checkpoints, not just day one, but depending on your deal strategy and integration strategy. It could be day 90, day 100, or day 300, whatever the timeline you're looking for.
You build your individual milestones and have a cadence for your Integration Management Office (IMO) meetings. Initially, it could be weekly or bi-weekly, and then you might change to monthly, depending on where you are in the timeline.
Having those checkpoints is really important to ensure you're on track, make any necessary adjustments, and check progress. As you progress, certain workstreams will complete their integration milestones and drop off the integration process.
Typically, the long poles remaining would be your product and technology, IT, etc. Having regular checkpoints is key to monitor progress and determine what changes are needed for the upcoming milestones and plan.
Information gathering challenges pre-close
In the pre-close world, due to certain restrictions, you won't have access to all information. However, you can set up areas where specific audiences with the right clearance can access that information. Setting up these rooms is important to manage sensitive information correctly.
Depending on the criticality, if that information can be accessed post-close, you can follow up and do those double clicks after closing. Maintaining clean rooms before closing and ensuring the right people have access to the right information is the way to approach.
Managing vendor dependencies and ensuring transparency
Vendor management could be a workstream of its own, depending on your deal. During your diligence, you'll get an initial understanding of the scope, what vendors are used on both sides, and where there is overlap.
Your procurement workstream can take the lead on the initial plan for integrating all the vendors. Making sure the target is involved and figuring out the scope, overlaps, and coming up with a plan that doesn't disrupt existing contracts is key. Working with both sides to build that procurement plan or vendor management workstream plan is essential.
Balancing functional plans with the master integration strategy
There will be some Integration Management Office (IMO) level milestones that you want to track, and there will be a plan around that, covering specific periods like day one, day 90, day 100, day 300.
You could have a plan covering the IMO specific areas, and then you obviously have separate functional plans for each. Often, we use Google Sheets, typically one sheet with different tabs, and IMO would be one tab for the plan with high-level plans. You want to minimize any duplicate items.
As part of the IMO governance, you want to ensure that you don't have duplicate items in multiple workstream plans, even if there are cross dependencies. You have to find one workstream that will be accountable for that specific item. Others will be responsible, but accountability should lie with one workstream.
One of the key things I focus on is having the right RACI identified. You can have multiple functions or workstreams responsible, but at the end of the day, it's only one workstream or one function that is accountable. That's the single point of when things go wrong. Making sure there is no duplication or redundancy across individual plans is definitely key.
Remember the RACI acronym: Responsibility, Accountability, Consulted, and Informed. You'll have people responsible, accountable, consulted, and informed.
Securing stakeholder buy-in
If you have set up a central document repository accessible to everyone, everyone should be able to see every workstream plan, including the IMO plan. During your IMO checkpoints, you definitely go over individual plans.
You run your IMO plan with all the work streams and then focus on individual plans as and when required, depending on what phase you are at and what the upcoming milestones are.
For example, if you have a weekly cadence, you will look into things that are upcoming in the next week or two. Then you'll pull out respective areas from individual plans that you need to focus on and discuss during that checkpoint.
Risks of overlooking integration
One of the things to remember is that your deal success really depends on having the right integration strategy and plan in place. Without it, there's a high risk of failure.
Another area of concern is team burnout due to improper resource planning, which can lead to being overwhelmed by upcoming milestones.
You also have to be answerable to your deal sponsor, the board, and the steering committee. It can put you in a very tough situation if you don't have the right strategy and planning in place.
So, if you really want a smooth integration, making sure you have the right strategy and plan based on that strategy is key.
Aligning deal goals with integration strategy
Your integration strategy should be built around your deal goals. To meet your deal objectives and goals, you have to have an integration strategy that is tightly aligned with them. In a nutshell, make sure that your integration strategy follows your deal strategy. Building them in silos will not help.
One example from Woven is when we did our initial transactions, one of the deal strategies was focused on acquiring talent. So, the integration strategy was mainly focused on integrating the teams and building the right organization to support our long-term strategy and goals.
However, we did not include product integration as one of the deal drivers. Later on, since we didn't focus much on product and technology integration, building out the target operating model for the product and technology group was challenging.
Our engineering teams had to go through that process in a painful manner, especially as we kept acquiring and new teams were brought into the mix. It became very difficult to come up with a cohesive engineering infrastructure and development infrastructure.
We ended up with a lot of duplicate or overlapping teams. It is really important to identify the right deal drivers in the beginning and then build your integration strategy around that. Otherwise, the gaps become very painful to address down the line.
Identifying when an M&A integration is complete
I have seen many times integration just keeps going on forever, with people having backlogs years down the line after the acquisition is complete. We are like a startup, a very small team, so it's very important to make sure we identify the integration exit criteria upfront.
I encourage all my workstreams, right at the beginning when we kick off integration and think about the charter for each function or workstream, to consider what the exit criteria for their own function or workstream is. Make sure to socialize that exit criteria, get buy-ins, and approval from the steering committee and the leadership team.
What helps is once you have that exit criteria in front, you know for a specific function or workstream when you can exit integration and transition to business as usual mode. There will be some long pole items that you want to do, but you can work on or execute them as part of business as usual, and come out of the integration mode, ready to continue running the business as usual.
Identifying that exit criteria or exit strategy will have a different timeline for each workstream, and for the overall Integration Management Office (IMO), it could be a different timeline as well. Identifying it upfront so that you can release the resources back to the functions or workstreams in time becomes easy, and it becomes easy to monitor and track the progress as well.
Best practices for smooth post-close integrations
Going back to where we started, bring integration in as early as possible in the mix, right from your deal strategy or deal structuring phase.
Involve integration in the diligence process after your Letter of Intent (LOI) is signed. Start your integration planning in that pre-close phase itself, make it a repetitive process.
Make sure to involve the right functional leads or workstream leads to build your integration plan, and then continue to refine and execute on that plan post-close. That's, in a nutshell, what I would say about best practices.
.jpg)
