Thomas Squeo, Senior Vice President for Digital Transformation and Digital Architecture at West, breaks down what to consider in the midst of an acquisition process
There are many potential benefits of an acquisition. An acquisition can be a quick way to enter a new market or plug a hole in your product portfolio. However, buyer beware. In order to ensure the long term success of an acquisition, there are a number of steps the acquiring company needs to take soon after the transaction is completed. These steps are especially important for companies who are undergoing digital transformation and whose competitive differentiation depends on software.
As Senior Vice President for Digital Transformation and Digital Architecture at West, a company that has and continues to grow by acquisition and is in the midst of its own cloud-native journey, I have seen first-hand the importance of acting quickly after an acquisition to integrate the acquired company’s IT, developers and business owners with our business and software development processes and culture. Here are some best practices we have learned over the years. They may not all apply to your business, but those that do will hopefully make the next acquisition your company makes a successful one.
Integrate Quickly
The number one piece of advice I can offer is to integrate an acquisition — it’s tech and people — fast. If you delay the integration, the acquired entity, which is typically prepared and willing to accept a significant amount of change in the early days after an acquisition, can grow anxious due to the uncertainties. To make this transition as seamless as possible, you need to understand the reasons you’re acquiring the company, whether its to acquire the company’s customer, their talent, or for specific products and technology.
Communicate, Communicate, Communicate
It should go without saying that communicating the executives’ motives is critical to making the transition of an acquisition seamless. If a decision is believed to be capricious or arbitrary, you can expect your staff to view the acquisition negatively.
The biggest cause of internal tension amongst teams when integrating new people and technology, more often than not, is anxiety. Moving from the status quo is difficult. People become comfortable with the familiar, and skeptical and defensive when it’s threatened. Tight-knit teams build a lot of tribal identity based on what they’ve built, and it’s difficult when an outsider comes in and pokes holes in existing products or processes. To help alleviate these anxieties, changes during integration need to be addressed at the executive level. If you’re acquiring a company for its customers, make it a point to convey just that, so account managers understand how it impacts their pipeline. Or, if the acquisition is for technical software, let your engineering team know what software integrations need to be prioritized.
When our organization is communicating an acquisition, we try to make three things clear:
1. What factors we considered;
2. How the analysis was done;
3. Why we made these decisions.
Transparency for transparency’s sake isn’t going to solve any problems or alleviate uncertainty, which is why the how the analysis was done is so critical. Providing your reasoning can make your existing teams feel valued, included in decisions, and empowered to help guide the integration.
Team Changes Happen — They Know it Too
When reorganizations do happen, keep in mind that bad news doesn’t get better with age. If people understand the criteria and reasoning for a team change from the outset, they’re going to be much more supportive. They might not like the outcome, but they will understand why you made the decision the way you did.
Typically, we look for ways to move people from the legacy team over onto the new team. In the instance when a system needs to be completely retired, that needs to happen quickly. Give people the opportunity to understand the change from leadership’s perspective.
Study Your New Tech
We have found applying the same diligence process we use to evaluate our own platform also helps us evaluate other software. At West Corp., we have eight maturity models that we run against potential software targets, depending on the transparency the target acquisition is willing to provide. If they want to keep it quiet and exclude their organization, forcing us to run analysis of its software after the acquisition — this is a red flag. [1] [2]
When we’re using our models, we look at everything from the target’s culture, team maturity, space configuration, processes in and around the SDLC, PDLC, quality, configuration & deployment to DevOps and CI/CD. When looking at quality and instrumentation, if the teams have a longitudinal data set, we can actually model what its performance over time will look like. We look at things like how fast can teams incorporate new infrastructure into it environments, whether or not they improve or degrade their builds, or whether infrastructure is able to expand or contract depending on the state of our business’ needs. West’s Pivotal investment can add value to all of these dimensions.
Not What You Know, But What You’re Willing to Learn
When integrating new developer talent, we’ve found that it isn’t as important what programming languages teams and developers use as long as the languages don’t totally diverge from general standards. One team might build with Python and Go, while another might use a combination of Java, C# and PHP. Regardless, all that matters for the customer are outcomes. One of the reasons we decided to use Pivotal is because it allows developers to use different languages on the same platform.
Instead focusing on what languages teams use, I’d suggest prioritizing a new team’s demonstrated ability to learn. In the case of different programming methodologies, say agile development versus a waterfall approach, we’ll actually embed agile coaches and agile technologies within a prospective team to evaluate its ability and willingness to adapt.
Typically, we have teams begin by conducting retrospectives. This gives them an opportunity to identify change that would be valuable from within. The approach gives us insights into whether the team is a cultural fit — while also providing them the program we expect to use to communicate, so that later they can operate autonomously and we don’t undermine the decisions being made by their leads.
From there we can move onto learning agile frameworks.
Hopefully, these tips help you in your considerations of acquiring a company. Feel free to comment with questions, and I’ll try my best to answer. Click the link to learn more about West Corp.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.
Acquisitions — What to Consider was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
